Final quiz — DMARC Enforcement for MSPs

DMARC records don't support p=reject directlyYou typically find out what legitimate sender you missed from a support call, not from a report, with no visibility step in betweenp=reject is not a valid DMARC policy valueIt requires a separate DNS record from p=quarantine

What percentage of the domain's total mail volume DMARC checks at allWhat percentage of failing mail the current policy (quarantine/reject) applies to – useful for a gradual rolloutThe percentage discount for SPF include lookupsHow often aggregate reports are sent

A fixed 30-day calendar timer, regardless of report contentZero unexplained failures from legitimate sources across a sustained window of aggregate reportsThe DNS record has propagatedThe client asks to move faster

DKIM doesn't require any DNS records at allSPF includes count against the 10-DNS-lookup limit; DKIM alignment doesn't have that ceilingDKIM is easier to spoof, so it's less risky to rely onSPF includes are deprecated

DMARC ignores SPF results entirelyForwarding breaks SPF alignment at the relay hop, but DMARC only requires SPF OR DKIM to align – a surviving DKIM signature can still passForwarded mail is always exempt from DMARCSPF and DKIM always produce identical results

Header From: spoofingAn on-path attacker stripping STARTTLS to force a plaintext (downgraded) connectionSPF permerror from too many DNS lookupsDKIM key compromise

The same authentication failures DMARC already reportsTLS negotiation failures – connections that couldn't establish the expected encrypted sessionSPF lookup countsDKIM key rotation history

It replaces the need for SPF and DKIM entirelyIt cryptographically signs DNS responses, so a forged SPF/DMARC/MTA-STS record can be detected – every other check is only as trustworthy as the DNS it's read fromIt only affects DANE, not SPF/DKIM/DMARCIt's required before publishing any DNS TXT record

TLSA records are always validated automatically by every resolverAn unsigned (non-DNSSEC-validated) TLSA record can be forged by the same attacker who could forge any other unsigned DNS recordTLSA records expire after 24 hoursTLSA only works for SPF, not DANE

Immediately switch the policy back to p=noneRead the aggregate reports first – the specific failing sources are usually already visible thereRe-publish the DNS record with a new random tokenContact every vendor the client has ever used, regardless of whether they send email