Email Authentication: SPF, DKIM, and DMARC Explained

Why email needs authentication in the first place

The Simple Mail Transfer Protocol (SMTP) was specified in RFC 5321 (and its predecessors going back to 1982) with no built-in identity verification. A mail server connecting to port 25 can announce any domain name in the EHLO/HELO handshake and any From: address in the message headers. The receiving side has no standard way to check whether the sender is who they claim to be. This design is a feature for interoperability. It is also a massive vulnerability.

Without authentication, anyone can forge mail from your domain. This is called email spoofing. A spammer or phisher sets the From: header to security@yourcompany.com, sends the message through an open relay or compromised server, and the recipient sees a legitimate-looking email. Standard SMTP does not reject it. The message lands in the inbox unless the recipient's mail provider applies heuristic filtering. Heuristics catch some forgeries but miss others, and they cause false positives that block real messages.

The consequences of spoofing extend beyond annoying spam. Attackers use spoofed emails for business email compromise (BEC) attacks, targeting employees, vendors, or customers to request wire transfers or steal credentials. According to the FBI's Internet Crime Complaint Center (IC3), BEC losses exceeded $2.9 billion in 2023 alone. Spoofing also erodes trust in your brand. When customers receive fake invoices or password-reset messages that look like yours, they stop trusting real messages from your domain.

Email authentication mechanisms solve a specific problem: they let a receiving mail server verify that a message claiming to come from yourdomain.com was either sent from an IP address you authorized or bears a cryptographic signature that matches your domain's public key. SPF (Sender Policy Framework, RFC 7208) does the first. DKIM (DomainKeys Identified Mail, RFC 6376) does the second. DMARC (Domain-based Message Authentication, Reporting, and Conformance, RFC 7489) ties them together and tells receivers what to do if both checks fail.

None of these protocols encrypt the message or prevent a misconfigured relay from relaying mail. They only provide evidence of authorization at the domain level. Without this evidence, modern large mailbox providers like Gmail, Outlook.com, and Yahoo Mail treat unauthenticated mail with extreme suspicion. Starting in February 2024, Google and Yahoo began enforcing a bulk-sender requirement that all senders sending more than 5,000 messages per day to their domains must have valid SPF, DKIM, and DMARC in place. Non-compliant senders see messages rejected or routed to spam.

Email authentication is not a luxury. It is a baseline requirement for reliable delivery and brand protection. The rest of this guide walks through each protocol, explains how to set them up safely, and shows how to interpret the reports they generate.

SPF: declaring which IPs can send for your domain

SPF (Sender Policy Framework) solves a simple problem: anyone can claim to be sending from yourcompany.com. Without SPF, a receiving server has no way to check whether the sending server is authorized. SPF lets you publish a DNS record that lists every IP address or range that is allowed to send mail for your domain. If mail arrives from an IP not on that list, the receiver can reject it or flag it.

The mechanism is defined in RFC 7208 (which obsoleted RFC 4408). It works by the receiving mail server doing a DNS lookup on the domain in the MAIL FROM (envelope sender) address, not the header From address. That distinction matters, but we will cover it in the alignment section.

Anatomy of an SPF record

An SPF record is a TXT record in DNS. It always starts with v=spf1. After that you list mechanisms, and optionally a qualifier (default is +, or pass). The most common mechanisms are:

• ip4 : allow a specific IPv4 address or CIDR range. Example: ip4:203.0.113.5 or ip4:203.0.113.0/24
• ip6 : same for IPv6. Example: ip6:2001:db8::/32
• include : delegate authorization to another domain. Example: include:_spf.google.com
• a : allow the IPs that the domain resolves to via its A or AAAA records
• mx : allow the IPs listed in the domain's MX records
• exists : a more advanced check (rarely needed)
• all : the catch-all mechanism at the end of the record

A qualifier before a mechanism changes the result: + (pass, default), - (fail, hard reject), ~ (softfail, usually marks as spam), ? (neutral).

Here is a real-world example for a domain that uses Google Workspace and has one office mail server:

v=spf1 ip4:198.51.100.27 include:_spf.google.com ~all

This says: allow 198.51.100.27, allow whatever Google's SPF record says, and mark everything else as softfail.

DNS lookups and the 10 limit

RFC 7208 mandates a maximum of 10 DNS lookups during SPF evaluation. Each include counts as one lookup. Each a or mx mechanism also counts (one for A, one for AAAA). If the record triggers more than 10 lookups, the receiver returns a permerror. This is the single most common deployment mistake. You must keep that count under 10. Use nested includes sparingly. If you use a third-party sender like SendGrid, Marketo, or Salesforce, you need to include their SPF include, not copy their IP list into your record.

What about multiple TXT records?

You can only have one SPF record per domain. If you publish two TXT records that start with v=spf1, receivers will almost always return permerror. Use a single record and combine all mechanisms into it. A domain with multiple senders might look like this:

v=spf1 include:_spf.google.com include:spf.sendgrid.net include:spf.marketo.com ~all

Check the lookup count: that record uses three includes, plus the implicit MX and A checks from Google? No, Google's include might itself contain multiple lookups. Test with a tool like dig txt yourdomain.com +short and use an SPF validator to count.

Where to start if you have no SPF

Gather all your outgoing mail sources. This includes your own mail server IPs, any SaaS platforms you use to send email (marketing, transactional, support), and any third-party services that send on your behalf. Create a TXT record that lists them and ends in ~all (softfail). Never start with -all unless you are certain you have not missed any senders. A hard reject from a missing IP will cause silent delivery failures. After you have tested for a few weeks, change ~all to -all.

DKIM: cryptographically signing your messages

DKIM, defined in RFC 6376, lets you attach a cryptographic signature to each outgoing email. That signature proves the message wasn't altered in transit and is tied to a domain you control. Unlike SPF, which only checks which IPs are allowed to send, DKIM verifies content integrity. A DKIM signature survives forwarding, because it's part of the message headers, not dependent on the envelope sender.

To set up DKIM, you generate a public-private key pair. The private key stays on your outbound mail server. The public key is published as a DNS TXT record under a subdomain like selector._domainkey.example.com. The selector is an arbitrary label you choose, e.g. s1 or google. Each selector can point to a different key, letting you rotate keys without breaking validation for old messages.

DKIM signature header

When a mail is sent, the server takes selected headers (like From, Subject, Date, Message-ID), plus the body, and signs them with the private key. The signature is inserted as a DKIM-Signature header. A typical signature looks like:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=example.com; s=s1; h=from:subject:date:message-id;
 bh=2jUSOH9NhtVGCQWNr9BrIAPsKZbGpU0Jc1w=;
 b=AuUoFEfD5YKFk5Uf5Yj+3i4nq1vWZRr9jL8=

The d= tag is the signing domain, s= is the selector, h= lists signed headers, bh= is the body hash, and b= is the digital signature. For exact tag semantics, see RFC 6376 Section 3.5.

Publishing the public key

You create a DNS TXT record at s1._domainkey.example.com containing:

v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC...==

The p= tag holds the base64-encoded public key. You can use 1024 or 2048 bit RSA keys. Ed25519 (RFC 8463) is also supported by some providers.

How receivers verify

When a receiving mail server gets a signed message, it reads the d= and s= tags, constructs the selector DNS name, fetches the TXT record, extracts the public key, recomputes the hash of the specified headers and body, and checks the signature. If it matches, the message passes DKIM verification. The result is stored as an Authentication-Results header, e.g. dkim=pass.

Key management

Rotate your DKIM keys regularly. Many email services (Google Workspace, Microsoft 365) let you generate keys through their admin consoles. Keep the private key secure. If compromised, an attacker can sign mail as your domain. Revoke a key by removing its DNS record or by publishing a new key under a different selector and retiring the old one.

DKIM alone doesn't prevent a domain from being impersonated. An attacker can still send unsigned mail from a different IP and claim your domain in the From header. That's why you need DMARC to tie SPF and DKIM together with a policy.

DMARC: tying SPF and DKIM together with policy

SPF and DKIM each solve a specific problem. SPF says which servers are allowed to send mail for your domain. DKIM attaches a cryptographic signature that proves the message wasn't tampered with after it left your server. But neither, on its own, tells a receiving server what to do when a message fails authentication. A phisher can send mail from an IP not in your SPF record. The receiving server sees the SPF fail, then what? It may accept the mail anyway. DMARC fills that gap.

DMARC stands for Domain-based Message Authentication, Reporting, and Conformance, defined in RFC 7489 (March 2015). It adds a DNS record, typically at _dmarc.yourdomain.com, that publishes a policy. The policy tells receivers what to do with messages that fail both SPF and DKIM checks: do nothing (p=none), quarantine them (p=quarantine, often sending to spam), or reject them outright (p=reject).

A basic DMARC record looks like this:

_dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; ruf=mailto:forensics@example.com; pct=100; adkim=r; aspf=r"

Key tags in that record:

v (version)

Must be v=DMARC1. Only version defined so far.

p (policy)

The core instruction: p=none, p=quarantine, or p=reject. Start with p=none when deploying. It lets you collect data without affecting delivery. Only move to p=reject after you have confirmed all legitimate mail passes authentication.

rua and ruf

rua specifies where aggregate reports go. ruf specifies where forensic (failure) reports go. These are mailto: URIs. Aggregate reports are XML files summarizing authentication results per sender IP per day. Forensic reports contain copies of messages that failed. Some receivers limit forensic reports to a small subset of messages to protect sender privacy.

pct (percentage)

Default is 100. Set it lower during rollout to apply the policy to only a fraction of messages. For example, pct=10 applies the quarantine or reject action to 10% of non-conforming mail. Not widely implemented by all receivers, but useful in early stages.

adkim and aspf (alignment mode)

adkim controls DKIM identifier alignment. r (relaxed) means the domain in the d= tag of the DKIM signature can be a subdomain of the From address domain. s (strict) requires an exact match. aspf does the same for SPF. Defaults are relaxed for both. Misalignment causes a DMARC fail even if SPF or DKIM pass individually.

The receiver checks SPF and DKIM first. If at least one passes AND the domain in the pass aligns with the From domain, DMARC passes. If neither passes, or if one passes but fails alignment, DMARC fails. Then the receiver applies the policy from p.

DMARC does not define its own authentication. It relies entirely on SPF and DKIM. That is why alignment matters. You can have valid SPF for the envelope domain but ship mail with a different From domain. DMARC sees a misalignment and may quarantine or reject the message. Getting this right is the hardest part of DMARC deployment, covered next in the alignment section.

How alignment between SPF, DKIM, and DMARC actually works

DMARC does not just check whether SPF passes or DKIM validates. It checks whether the domain used in those checks matches the domain the user sees in the From header. That is the concept of alignment. Without alignment, a passing SPF check or a valid DKIM signature can still fail DMARC.

Take a typical example. Your domain is example.com. You hire a marketing platform that sends on your behalf using its own IPs and its own signing domain. If the platform's Return-Path header uses mailer.platform.net and its DKIM signature uses d=platform.net, SPF and DKIM both pass individually. But the From header still shows @example.com. DMARC compares the domain in the From header against each authenticated domain. If neither matches, alignment fails. DMARC sees the message as unauthenticated for your domain.

Alignment is defined in RFC 7489, Section 3.1. SPF alignment is strict by default. The domain in the Return-Path header must match the domain in the From header exactly. Subdomain matches do not count unless you set sp= in your DMARC policy. DKIM alignment can be either strict or relaxed. Under relaxed alignment, the d= domain in the DKIM signature can be an organizational domain of the From domain. For example, a DKIM signature with d=mail.example.com aligns with a From address of @example.com under relaxed rules. Under strict, it must match exactly.

You set alignment in your DMARC DNS record with two tags. aspf=r or aspf=s controls SPF alignment. adkim=r or adkim=s controls DKIM alignment. The default for both is relaxed. Most deployments use relaxed alignment because strict alignment breaks many legitimate third-party senders.

Here is the critical sequence. A receiver gets a message. It performs SPF check against the Return-Path domain and DKIM verification against the d= domain. At least one of those checks must pass and that passed check's domain must align with the From domain. If both pass but only one aligns, DMARC passes. That is the pass condition: SPF aligned and passes, or DKIM aligned and passes, or both. If neither passes, or if the passing check does not align, DMARC fails and the policy action (none, quarantine, or reject) applies.

The concept trips up many sysadmins. You can have a perfect SPF record and a valid DKIM signature, but if the signing domains do not match the From domain, your DMARC evaluation returns a failure. This is why you often see DKIM signing with d=yourdomain.com even when using a third-party ESP. The ESP signs with a domain you own, not their own, to satisfy alignment.

example.com TXT "v=DMARC1; p=reject; adkim=r; aspf=r; rua=mailto:reports@example.com"

The record above uses relaxed alignment for both SPF and DKIM. That is the safe default for most domains. Change to aspf=s only after you confirm every legitimate sender uses a Return-Path matching your From domain exactly.

Reading DMARC aggregate (RUA) and forensic (RUF) reports

Once you publish a DMARC record with the rua=mailto: or ruf=mailto: tags, receiving mail servers send reports back to your configured mailbox. These reports are the only way to see how other providers view your mail. Without them, you are flying blind.

Aggregate reports (RUA)

Aggregate reports are XML documents, usually gzip compressed, that contain summaries of message evaluations over a time period. Each report covers a specific receiver (for example, Google or Microsoft) and lists the total number of messages that passed or failed SPF, DKIM, and DMARC checks. The report also includes the sending IP address, the number of messages from that IP, and the DMARC disposition applied (none, quarantine, reject).

A typical report is around 10-100 KB. The XML schema is defined in RFC 7489. A simplified snippet looks like this:

<feedback>
 <report_metadata>
 <org_name>google.com</org_name>
 <email>noreply@dmarc.google.com</email>
 <begin_range>1609459200</begin_range>
 <end_range>1609545599</end_range>
 </report_metadata>
 <record>
 <row>
 <source_ip>192.0.2.1</source_ip>
 <count>150</count>
 <policy_evaluated>
 <disposition>none</disposition>
 <dkim>pass</dkim>
 <spf>pass</spf>
 </policy_evaluated>
 </row>
 <identifiers>
 <header_from>example.com</header_from>
 </identifiers>
 <auth_results>
 <dkim><domain>example.com</domain><result>pass</result></dkim>
 <spf><domain>example.com</domain><result>pass</result></spf>
 </auth_results>
 </record>
</feedback>

The <row> element contains the important bits: the sending IP, the number of emails, and the alignment result. The <identifiers> block shows the domain in the From header. The <auth_results> block shows what SPF and DKIM actually verified on the receiving end. Cross-referencing these helps you find unauthorized senders or misconfigured third-party services.

Forensic reports (RUF)

Forensic reports are different. They contain copies of individual messages that failed DMARC authentication. The format varies: some receivers send the full email as an attachment (RFC 6590), others send headers only. Because forensic reports carry actual message content, they raise privacy and data volume concerns. A single spam campaign can dump thousands of reports into your inbox.

Many providers limit RUF reports. Google, for instance, sends RUF reports only for messages that are explicitly rejected or quarantined, and they redact the message body. In practice, RUA reports give you the data you need for diagnostics. RUF reports are useful mainly for investigating targeted attacks or phishing against your domain.

Processing reports at scale

You should not try to read the raw XML manually. Several free and paid parsers exist. parsedmarc (open source) can download reports from IMAP, parse the XML, and send the results into Elasticsearch or a CSV file. Postmark's DMARC tool and dmarcian provide hosted dashboards that visualize the data. Most enterprise email security gateways include built-in DMARC report processing.

Key statistics to look for:

• Total pass rate: the percentage of messages that passed both SPF and DKIM alignment.
• Top failing IPs: IP addresses that sent mail failing DMARC. These could be compromised servers, forwarding services, or misconfigured third-party senders.
• Disposition breakdown: how many messages each receiver applied reject, quarantine, or none to.
• Domain mismatch: messages where the SPF or DKIM domain does not match the Header From domain.

Monitor these reports daily when moving from p=none to p=quarantine or p=reject. Once you are confident that 100% of your legitimate mail passes, you can safely tighten the policy.

BIMI: getting your logo next to authenticated mail

BIMI (Brand Indicators for Message Identification, RFC 9371) lets you display your company logo next to emails in participating mail providers. Gmail and Apple Mail both show the logo in the avatar slot when BIMI is configured correctly. The logo provides a visual signal that the message passed DMARC authentication and comes from a legitimate sender.

BIMI requires three things to work. First, you need a DMARC policy of p=quarantine or p=reject on your domain. Second, you publish a BIMI DNS record that points to your logo. Third, most providers require a verified mark certificate (VMC) from a CA like DigiCert or Entrust. The VMC proves you own the trademark to the logo. Without it, Gmail will not show your logo.

The BIMI DNS record lives under default._bimi.<domain> as a TXT record. A typical record looks like this:

default._bimi.example.com. TXT "v=BIMI1; l=https://images.example.com/logo.svg; a=https://images.example.com/logocard.pem"

The l tag points to the SVG logo. The a tag points to the VMC file if you have one. The SVG must be a square, single-color vector graphic. Gzip is not allowed. The file must be served over HTTPS from a server that returns the correct MIME type. Apple Mail may show the logo without a VMC, but Gmail will not.

MTA-STS and TLS-RPT for transport security

SPF, DKIM, and DMARC protect the envelope and signing of a message, but they do not encrypt or verify the path between two mail servers. A message authenticated with a valid DMARC pass can still be intercepted or downgraded to plaintext during SMTP transit. This is where SMTP MTA Strict Transport Security (MTA-STS) and TLS Reporting (TLS-RPT) come in. They were standardized in RFC 8461 and RFC 8460 respectively, both published in September 2018.

MTA-STS lets a domain declare that connecting MTAs must use TLS when delivering mail to it, and that they must verify the certificate presented by the receiving server. Without MTA-STS, fallback to plain SMTP on port 25 is always possible. An attacker who can strip the STARTTLS negotiation (a classic STRIPTLS attack) sees the message in the clear. MTA-STS prevents that by requiring a valid certificate matching the MX hostname and rejecting delivery if TLS cannot be established.

How to publish MTA-STS

You need two things: a DNS TXT record and a policy file served over HTTPS. The DNS record goes at _mta-sts.yourdomain.com and tells senders where to fetch the policy. It looks like this:

_mta-sts.yourdomain.com. TXT "v=STSv1; id=20250301;"

The id= value is a version string. When you update the policy, increment this id. Senders cache the policy for up to the max_age you specify, so changing the id forces them to re-fetch.

The policy file lives at https://mta-sts.yourdomain.com/.well-known/mta-sts.txt. It must be served over HTTPS with a valid certificate. A minimal policy:

version: STSv1
mode: enforce
mx: mail.yourdomain.com
mx: backup-mail.yourdomain.com
max_age: 86400

The mode can be enforce, testing, or none. Start with testing and monitor reports before moving to enforce.

TLS-RPT: getting reports

TLS-RPT tells senders where to send delivery failure reports when TLS negotiation fails (or succeeds). It is a separate DNS TXT record at _smtp._tls.yourdomain.com:

_smtp._tls.yourdomain.com. TXT "v=TLSRPTv1; rua=mailto:tls-reports@yourdomain.com"

The rua= URI is the same syntax DMARC uses. Reports are sent as gzip-compressed JSON (similar to DMARC aggregate reports). They tell you which sending providers saw TLS failures, what the certificate error was, and which MX was targeted.

Google and Microsoft both send TLS-RPT reports. If you see failures in testing mode, you can fix certificate problems or MX misconfigurations before switching to enforce mode.

Important limitations

MTA-STS only works if the sending MTA supports it. As of mid-2024, Google (Gmail), Microsoft (Outlook.com, Office 365), Yahoo, and Fastmail all enforce MTA-STS for inbound mail. Smaller providers may still ignore the policy. Also, the policy cache is protected only by DNS and HTTPS. If an attacker can block the HTTPS fetch and the sending MTA has never seen the policy, it may fall back to opportunistic TLS. DNSSEC helps mitigate this by authenticating the DNS record, but MTA-STS was designed as a lighter alternative to DANE (RFC 6698) which requires DNSSEC everywhere.

Common mistakes that break legitimate mail

Even after you have set up SPF, DKIM, and DMARC, a single config error can cause your own outbound messages to fail authentication. These mistakes are frustrating because they happen slowly. A change you make today might not trigger a visible failure until tomorrow, when a recipient's DMARC policy shifts from p=none to p=quarantine. Here are the most frequent traps and how to avoid them.

SPF "all" mechanism too restrictive

The most common blunder is using -all (hard fail) on an SPF record before you have listed every legitimate sender. You might include your main mail server at mail.example.com but forget a third-party service like Salesforce or Marketo that sends on your behalf. That third party's IP will fail SPF. If your DMARC policy is p=reject, those messages never reach the inbox. Always audit your sending sources before switching from ~all (soft fail) to -all. Use DMARC aggregate reports to see which IPs are passing and failing before you tighten the policy.

SPF lookup limit exceeded (10 DNS lookups)

SPF records have a hard limit of 10 DNS lookups per the original specification (RFC 7208). If your record uses include statements for multiple ESPs, each includecounts as a lookup. Nesting also counts. When the limit is exceeded, a receiving server returns a permanent error (permerror), which DMARC treats as SPF fail. This is silent to you. You only see it in DMARC failure reports or when partners complain your mail is missing. Use a service like spftool or online SPF validators to count your lookups. If you are close to 10, move to IP-level listing or a single include for a consolidated mail provider.

DKIM selector mismatch after provider change

Every DKIM key lives at a DNS name like selector1._domainkey.example.com. Email services (Google, Microsoft, SendGrid) tell you exactly which selector and public key to publish. If you switch providers or add a second sending platform, that platform may use a different selector. If your DNS only has the old selector, the new platform's mail will lack a valid DKIM signature. You must add the new selector as a separate DNS record. Do not remove the old one until all legacy traffic from the previous provider has stopped flowing.

DMARC reports sent to unmonored mailboxes

It is alarmingly common to set rua=mailto:dmarc@example.com but forget to check that mailbox regularly. Or the mailbox itself is not set up to receive mail (no SPF/DKIM for the domain, or a policy that blocks the reports). You get no visibility into authentication failure patterns. Dedicate a mailbox that you actually monitor, and set up an automated parser or a service like DMARCian or URIports to aggregate the XML reports into readable dashboards.

Using different DKIM signatures inside the same message stream

Some bulk mailers sign their messages with multiple DKIM selectors (e.g., one for the ESP and one for the brand domain). That is fine. The problem is when two different DKIM signatures on the same message use the same selector but different keys. DMARC only requires one valid signature that passes alignment. But if both are present and one is invalid, some strict receivers may reject the message. Keep your selectors unique and rotate keys methodically.

Forgetting to align the Domain in the DKIM signature (adkim)

DKIM alignment can be strict (s) or relaxed (r). If your DMARC policy requires strict alignment (adkim=s), the domain in the DKIM d= tag must exactly match the From: header. Many organizations use a subdomain for sending, like mail.example.com. If the DKIM signature says d=send.example.com but the From: is @example.com, strict alignment fails. Set adkim=r during initial deployment to allow subdomain variance.

Changing DMARC from p=none to p=reject too quickly

This is less a configuration mistake and more a process mistake. If you move from p=none to p=reject after only one day of DMARC data, you will likely block legitimate mail. Wait at least one week (longer for low-volume senders). Analyze aggregate reports to confirm that more than 99.5% of your mail passes both SPF and DKIM with alignment. A phased approach: p=quarantine with a small percentage (pct=20) first.

Deploying SPF, DKIM, DMARC from p=none to p=reject safely

The most common disaster in DMARC adoption is publishing p=reject too early. You quarantine or delete mail that you actually want. The safe path is a gradual rollout across three policy levels: p=none, p=quarantine, and finally p=reject. Each step gives you data to confirm you haven't broken anything.

Step 1: Start with p=none and monitor reports

Publish a DMARC record with p=none and an rua address that points to a mailbox you control. For example:

_dmarc.yourdomain.com. TXT "v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; pct=100;"

This record tells receivers to deliver everything normally but send you daily aggregate reports. Let this run for at least 30 days. Use a report parser (many are free, like dmarcian or Postmark's DMARC tooling) to see which sources are passing and failing SPF/DKIM alignment. You are looking for services you forgot: a marketing platform, a support desk, a third-party transactional email provider.

Step 2: Fix all failing sources

Each failing source is a misconfiguration. For an SPF failure, add the sender's IP or include mechanism to your SPF record. For a DKIM failure, get the sender's public key and selector added to your DNS, then have them sign mail for your domain. Keep checking reports until your pass rate is consistently above 99%.

Step 3: Move to p=quarantine

Change your DMARC record to p=quarantine. This tells receivers to send failing mail to the spam folder instead of deleting it. Monitor reports for another 30 days. Watch for complaints from users who say legitimate messages disappeared. If you see new failures, fix them. Quarantine is safer than reject because users can still rescue false positives from spam folders.

Step 4: Move to p=reject

Once you have at least 60 days of clean data (no unexplained failures over 1 to 2 percent of volume), publish:

_dmarc.yourdomain.com. TXT "v=DMARC1; p=reject; rua=mailto:dmarc@yourdomain.com; ruf=mailto:forensic@yourdomain.com; pct=100;"

With p=reject, receivers that honor DMARC will not deliver messages that fail both SPF and DKIM alignment. Continue monitoring the rua reports indefinitely. If you add a new mail service later, repeat the monitoring cycle for that sender before expecting it to pass.

The pct tag: rolling out gradually

Even within a policy level, you can use the pct tag to apply the policy to only a fraction of your email. For example, p=quarantine; pct=25 applies quarantine to one in four failing messages. This is useful for very large senders who want to test impact before a full rollout. Increase in 25% increments as your confidence grows.