Levels of Email Authentication Maturity | DMARC Defender
*:not(.docs-content-wide)]:mx-auto [&>*:not(.docs-content-wide)]:w-full [&>*:not(.docs-content-wide)]:max-w-4xl">Levels of Email Authentication Maturity<br>Domains start out with no protections. The process of enforcing email authentication is gradual. It starts by publishing a safe DMARC record, collect reports, identifying legitimate senders, fixing SPF and DKIM, and then move toward enforcement.<br>This page gives a simple maturity model for that rollout. For background on the core protocols, start with DMARC explained, SPF explained, and DKIM explained.<br>You can check the status of your email using the Domain Check Tool.<br>Level 0: No DMARC, SPF, or DKIM<br>At this level, the domain has no meaningful email authentication records. Mail can still be sent, but it's possible it'll be blocked bybulk sender requirements. Without enforcement, attackers can easily spoof emails allowing for easy impersonation attacks.<br>Deliverability
Domain spoofing protection
Bulk sender requirements
TLS and MX protections
Observability
Level 1: DMARC Without Reporting<br>The simplest DMARC record uses a p=none policy. This tells receivers to evaluate DMARC but do nothing with the result. If you already have an SPF policy/DKIM keys, it's possible it'll "fulfill" the Bulk Sender Requirements. But chances are high legitamte email will still be unauthenticated, and it still allows attackers to impersonate the domain.<br>v=DMARC1; p=none
A monitoring-only DMARC policy without an aggregate reporting address.<br>Deliverability
Domain spoofing protection
Bulk sender requirements
TLS and MX protections
Observability
Level 2: DMARC Reporting<br>DMARC reporting gives domain owners observability into the status of their email authentication. Email receivers (Microsoft/Google/Yahoo/etc) collect statistics about who is sending email and from what domain, and then send a report every 24 hours to the email listed in the DMARC "rua" tag.<br>The report contains lots of useful information, including which emails are passing SPF / DKIM / Alignment (example report). Using this information we can identify which tools/services are missing proper SPF/DKIM setup.<br>To get started with reporting, just put an email address in the "rua" field of the DMARC policy.<br>If you don't want to parse the XML yourself you can use tools such as dmarcdefender.io. We collect the reports for you and let you know when you need to update your policy.<br>v=DMARC1; p=none; rua=mailto:abc123@dmarcdefender.io
A DMARC policy with reporting<br>Deliverability
Domain spoofing protection
Bulk sender requirements
TLS and MX protections
Observability
Level 3: SPF and DKIM Setup<br>Using the reports from the previous step, domain owners can configure SPF/DKIM for their domain ensuring all emails being sent from a domain are properly authenticated.<br>SPF and DKIM should be configured through each sending provider's setup instructions. For common senders, see the provider setup guides for Google Workspace, Microsoft 365, Klaviyo, and HubSpot.<br>v=spf1 include:_spf.google.com include:spf.protection.outlook.com ~all
v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9.......
Example SPF and DKIM records for authorized mail sources.<br>Deliverability
Domain spoofing protection
Bulk sender requirements
TLS and MX protections
Observability
Level 4: DMARC Enforcement<br>Once all the services are properly authenticated, domain owners can switch to DMARC enforcement p=rejector p=quarantine. quarantine will send failing emails to spam, while reject will block failing emails.<br>Once this step is complete, your email is successfully authenticated and enforced! It's important to monitor the reports periodically to ensure new services are properly configured with SPF/DKIM.<br>v=DMARC1; p=reject; rua=mailto:abc123@dmarcdefender.io
A strict DMARC policy for domains whose legitimate senders are already authenticated.<br>Deliverability
Domain spoofing protection
Bulk sender requirements
TLS and MX protections
Observability
Level 5: (Optional) Additional Protections<br>After DMARC is complete, domain owners can look at some of the other email security protocols and BIMI. These are separate from DMARC, but they build on a mature email authentication foundation.<br>TLS-RPT<br>TLS-RPT sends you reports when your email isn't being sent over TLS.<br>v=TLSRPTv1; rua=https://dmarcdefender.io/api/v1/tlsrpt/abc123
MTA-STS<br>MTA-STS tells senders to require TLS and deliver only to approved MX hosts. It requires hosting a policy file on a web server.<br>v=STSv1; id=20260624T000000
BIMI<br>BIMI can show your brand logo in supporting inboxes. See BIMI explained for the full setup path.<br>v=BIMI1; l=https://example.com/bimi.svg; a=https://example.com/vmc.pem
Deliverability
Domain spoofing protection
Bulk sender requirements
TLS and MX protections
Observability