Setting up DMARC, SPF and DKIM means publishing statements in DNS (the internet's phone book, which holds the records for an organization's web and email names) about which systems may send email in the organization's name and what receivers should do with mail that fails the checks. The system has three parts: SPF (a list of systems allowed to send), DKIM (a digital signature on the message) and DMARC (a rule that combines the results of the first two and tells the receiver what to do). A wrong order can get genuine mail refused, so this article explains each part in plain terms and then gives a safe rollout order: monitor first, then enforce.

What a receiving mail server checks

An email is like a letter in an envelope. The envelope carries the sender address that mail systems use to pass the message between servers, called the envelope sender, or MAIL FROM. The letter inside carries the sender name the user sees in the From field. A domain is the part of an email address after the @ sign, such as example.com. The address on the envelope and the address in the From field can have different domains. SPF and DKIM do not check the From field directly, so an attacker can forge the name in it. DMARC was created to tie the results of the first two to the From field.

  • SPF: checks the "envelope". The receiver looks at the domain on the envelope, then asks that domain's DNS for the list of IP addresses allowed to send. If the sending machine's IP is on the list, the result is a pass
  • DKIM: checks the "seal on the letter". The sender signs the message with a secret key, and the receiver checks the signature with a key published in DNS. If the content was altered in transit, the signature fails
  • DMARC: checks that the name in the From field matches a domain that passed SPF or DKIM (called alignment), then follows the policy the domain published and sends reports back to the domain owner

DMARC passes when at least one of SPF or DKIM passes and the domain that passed matches the domain in the From field. The reason is that anyone can publish an SPF record for their own domain and pass, so the match with the From field is what counts. RFC 9989 recommends making both match if you can.

INFOGRAPHIC
How a receiver judges one message
01
Message arrives
From: example.com
02
Check SPF
is the IP on the list
03
Check DKIM
is the signature valid
04
Check DMARC
passed and matches From
05
Apply the policy
allow, quarantine, reject

SPF: declare who may send for the domain

SPF is a list of IP addresses (numbers that identify machines on a network) and systems allowed to send mail in the domain's name. It is stored as a TXT record (a text record) in that domain's DNS. The following example uses the placeholder domain example.com.

example.com.  IN  TXT  "v=spf1 ip4:203.0.113.10 include:_spf.mailprovider.example -all"

v=spf1 says this is an SPF record. ip4:203.0.113.10 is the IP of the organization's own mail server. include: pulls in the list of an external sending provider. The last term says what to do when nothing matches: -all means every other IP is not authorized (fail), while ~all means probably not authorized, a weaker statement (softfail).

  • Only one record per domain: if more than one SPF record is found, the result is permerror (a permanent error, the check cannot be completed). Merge them into a single record
  • At most 10 DNS lookups: include, a, mx, ptr, exists and redirect count together, and more than 10 gives permerror. ip4, ip6 and all do not count. When you use several external providers, count before adding a new entry
  • Avoid ptr: RFC 7208 says this mechanism should not be published
  • Forwarding can make SPF fail: the forwarding server has a different IP from the ones the domain published. RFC 9989 therefore requires a domain that publishes reject to also apply DKIM, and not rely on SPF alone

DKIM: a digital signature on the message

DKIM uses a matched pair of keys. The private key is secret, sits on the server that sends the mail and signs each message. The public key can be shared, and the sender publishes it in DNS so that receivers can check that a signature really came from the matching private key. If the content is altered afterwards, the signature no longer matches and the check fails.

The record name gives the location of the public key, in the form selector._domainkey followed by the domain name. The selector is a label that tells keys apart, so one domain can hold several keys, for example one per provider.

selector1._domainkey.example.com.  IN  TXT  "v=DKIM1; k=rsa; p=BASE64_PUBLIC_KEY"

On the sending side, the mail system adds a DKIM-Signature header. The shortened example below has d=, the signing domain, and s=, the selector. The receiver combines these two values into the record name above. The d= value must match the domain in the From field under the matching rules above for the DKIM pass to count toward DMARC.

DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=selector1; h=from:to:subject:date; bh=BODY_HASH; b=SIGNATURE
  • Use rsa-sha256: RFC 8301 says rsa-sha1 must not be used to sign mail
  • RSA keys of at least 1024 bits, 2048 bits or more recommended: RFC 8301 sets this, and Google states that sending to personal Gmail accounts requires a key of 1024 bits or longer
  • Each provider uses its own key pair: NIST recommends a separate key for each provider that sends on the organization's behalf, and when a contract ends, deleting the record or leaving p= empty to revoke the key
  • Keep the private key safe: NIST says only the mail-sending software should be able to read it
  • When you change the key pair, sign with the new key at once: RFC 6376 advises keeping the old public key for a reasonable period so that slow receivers can still validate
  • A signature usually survives forwarding but fails if the content is changed: for example by a central system that appends text to messages

A DKIM key needs an owner and a replacement plan, just like a digital certificate. The same idea appears in Certificate Lifecycle Management in the 47-Day Era.

DMARC: policy and reports

DMARC adds three things to SPF and DKIM: matching of names (alignment), a policy that tells the receiver what to do, and reports sent back to the domain owner. There are two matching modes. Relaxed, the default, accepts names under the same parent domain: if the domain that passed is foo.example.com and the From field says news.example.com, they count as a match. Strict requires exactly the same name.

_dmarc.example.com.  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"
  • v=: the version. The only valid value is DMARC1, and it must be the first tag in the record, otherwise receivers ignore the whole record
  • p=: the domain's policy. The allowed values are none, quarantine and reject
  • rua=: the address to which receivers are asked to send aggregate reports (summary reports). If it is missing, receivers do not send reports
  • sp= and np=: sp is the policy for existing subdomains and np is the policy for non-existent subdomains (np was added in RFC 9989). If they are absent, the p value applies
  • adkim= and aspf=: choose relaxed (r) or strict (s) matching for DKIM and SPF respectively. The default is r
  • t=y: test mode, which asks receivers to apply a policy one step lower, for example reject is applied as quarantine

The p value has three levels. none asks receivers to do nothing special with mail that fails, and is used for monitoring and getting reports. quarantine treats the mail as suspicious, although it may be genuine. reject treats the use of the domain name as invalid. Receivers are not forced to follow the policy every time: RFC 9989 tells them to weigh other factors and not to refuse mail solely because of p=reject.

INFOGRAPHIC
How much each DMARC policy protects
No DMARC
receivers have no rule from the domain
p=none
monitor and get reports, blocks nothing
p=quarantine
treated as suspicious
p=reject
treated as invalid, refuse
Easy to forge the domainHard to forge the domain

Most guides cite RFC 7489, which has now been replaced. RFC 9989 (the core standard), RFC 9990 (aggregate reports) and RFC 9991 (failure reports) were published in May 2026 and state that they replace RFC 7489. Records still begin with v=DMARC1 as before, but the pct, rf and ri tags were removed and the np and t tags were added.

The old pct tag set the share of mail to which the policy applied, for example pct=25. RFC 9989 explains that receivers applied values other than 0 and 100 inconsistently, so it removed pct and uses t=y for the testing phase. If you see pct in an old example, use t=y or move the policy up one step at a time as this article describes.

A safe rollout order: monitor first, then enforce

RFC 9989 sets out the order clearly. Start with p=none so that the reports reveal any forgotten systems or external providers, then tighten step by step. The key rule is that genuine mail that still fails must be fixed before you use quarantine or reject.

INFOGRAPHIC
The rollout in six steps
1
Inventory every sender
own, internal and external providers
2
Set up SPF and DKIM
matching the From domain
3
Publish p=none with rua
collect and read reports, may take months
4
Fix failing senders
genuine mail passes and matches From
5
Move to quarantine
as long as the none stage, compare results
6
Move to reject
once reports are clean and DKIM is in place

Not every domain has to reach reject straight away. CISA recommends reject for outbound mail, but RFC 9989 warns that reject can cause problems for mailing lists, forwarded mail and shared forwarding names (aliases). A domain whose staff send ordinary mail should therefore use p=none for at least a month, then p=quarantine for an equally long time, and compare the results before deciding. If you choose reject, tell users that posting to mailing lists may be affected.

Reading reports and fixing the common problems

Aggregate reports show which sources send mail using our domain and whether the checks passed. The reports are files designed for machines to read, so RFC 9989 recommends using a tool to parse them: several outside services exist, or you can build your own. Split the failing sources into two groups. The first is forgery or misuse. The second is genuine mail that is not fully configured, which must be fixed before tightening the policy. The second group often comes from forgotten senders. RFC 9989 warns that a domain owner may overlook one server or one agreement with an external provider.

INFOGRAPHIC
Senders often forgotten in the reports
Our domain
common examples, not a full list
Newsletters and marketing
sent through an external provider
Invoicing and ERP
older systems may not sign DKIM
Helpdesk and CRM
set up by another team to send as us
Printers and internal apps
send alerts that nobody recorded
SaaS providers
must sign with a domain that matches ours
  • An external provider sends in our name but is not set up to match our domain: SPF passes only for the provider's own domain, which does not match the From field. Have the provider sign DKIM with our domain
  • SPF over 10 lookups, or several records: the whole SPF check gives permerror
  • Forwarding and mailing lists: SPF usually fails once mail is forwarded, and DKIM fails if a central system changes the content

What the large mailbox providers require

Some providers set a minimum for senders. The information below was read from the providers' own pages and may change.

  • Google (Gmail): every sender must set up SPF or DKIM. A sender that sends more than 5,000 messages a day to Gmail accounts must have SPF, DKIM and DMARC, where the policy may be none, and the name in the From field must match the SPF or DKIM domain
  • Yahoo: every sender needs SPF or DKIM. A bulk sender (high volume) needs both, plus DMARC of at least p=none that passes, and Yahoo strongly recommends including rua. Yahoo's page does not give a number for what counts as bulk
  • Takeaway: p=none is only the minimum these providers accept and does not stop domain forgery. Move up once the reports are clean

Common mistakes

  • Turning on reject on day one: genuine mail from forgotten systems will be refused
  • Publishing DMARC without rua, or never reading the reports: it is like closing your eyes, since you cannot see who sends in the domain's name
  • Creating several SPF records: the result is permerror, so merge them into one record
  • Adding include entries beyond 10 DNS lookups: the whole SPF check becomes unusable
  • Staying at p=none forever: it meets the providers' minimum but still does not stop domain forgery
  • Relying on SPF alone with reject: forwarding makes SPF fail, and RFC 9989 requires a domain that uses reject to also have DKIM
  • Letting several providers share one DKIM key, or forgetting to revoke a key when a contract ends: NIST recommends a separate key per provider and revoking it when it is no longer used
  • Following an old guide that cites RFC 7489 without checking the new standard: for example using pct, which has been removed

Start today

  • Look at the existing SPF, DKIM and DMARC records of every domain: including domains that do not send mail
  • Build an inventory of senders: ask every team which systems or providers send mail in the domain's name
  • Prepare a place for the reports, then publish DMARC as p=none with rua: use a dedicated mailbox or a report-parsing service
  • Review the reports every month: move the policy up once every genuine sender passes and matches the From field
  • Check DKIM key lengths and the providers that still hold keys: at least 1024 bits, 2048 recommended, and revoke the keys of providers no longer used
  • Read the overview of all email protection layers: see Email Security: Layered Defense Against Phishing and BEC

To see where your organization's email protection stands against good practice, try the self-assessment.

Scope and accuracy

The DMARC content is based on the text of RFC 9989 as read on 22 October 2026. Mail providers may adopt the new standard at different times, so check the documentation of the providers you use. The Google and Yahoo requirements were read from the providers' own pages. Microsoft is not included because its own page could not be read. The record examples use the placeholder domain example.com and IP addresses reserved for documentation. Replace them with your organization's real values and test on a trial domain first.

References and further reading