What Is DMARC?
DMARC stands for Domain-based Message Authentication, Reporting and Conformance. It is an email authentication protocol that tells receiving mail servers how to handle messages that claim to come from your domain but fail identity verification checks.
Published as RFC 7489 in 2015, DMARC builds on two earlier email authentication standards — SPF and DKIM — and adds two critical capabilities that neither standard provides on its own: a clear policy instruction for receivers, and a reporting mechanism that lets domain owners see exactly who is sending email on their behalf.
Without DMARC, any attacker can send email with your domain in the “From” address. Receiving servers have no authoritative instruction about what to do with unauthenticated messages, so they often deliver them. With DMARC, you publish a policy at _dmarc.yourdomain.com that tells receivers to monitor, quarantine, or reject those messages — and report back to you when they see them.
How DMARC Works
DMARC works by combining the results of SPF and DKIM checks and applying a concept called identifier alignment.
When a receiving mail server gets an inbound message, it performs the following checks in sequence:
- SPF check — The server looks up the SPF TXT record at the sender’s domain and verifies that the sending IP address is authorised to send mail for that domain.
- DKIM check — The server verifies the DKIM signature in the email header against the public key published in the sending domain’s DNS.
- DMARC alignment check — The server checks whether the domain used in SPF or DKIM matches the domain in the visible “From” header that the recipient sees in their email client.
- DMARC policy lookup — The server queries
_dmarc.senderdomain.comand applies the published policy to any message that fails both SPF alignment and DKIM alignment.
The alignment requirement is what makes DMARC effective against spoofing. An attacker can technically pass SPF by sending email from an authorised server in a different domain, but DMARC alignment requires the authenticated domain to match the visible “From” domain — which the attacker does not control.
What Is Identifier Alignment?
Identifier alignment is the core mechanism that ties DMARC to the visible sender address.
SPF authenticates the envelope sender (the MAIL FROM address used during the SMTP transaction). DKIM authenticates the d= domain in the signature header. Neither of these addresses is necessarily the same as the From: header the recipient sees.
DMARC adds the rule that at least one of the authenticated domains must align with the From: domain. Alignment can be:
- Relaxed (
aspf=roradkim=r, the default) — the authenticated domain must share the same organisational domain as theFrom:domain. For example,mail.example.comaligns withexample.com. - Strict (
aspf=soradkim=s) — the authenticated domain must match theFrom:domain exactly.
A DMARC pass requires SPF to pass AND align, OR DKIM to pass AND align. If both fail, the receiving server applies the DMARC policy.
The Three DMARC Policies
The p= tag in a DMARC record defines what receivers should do with messages that fail DMARC.
p=none — Monitor mode. Failing messages are delivered normally. The domain owner receives reports about authentication failures but no filtering action is taken. This is the correct starting point for any new DMARC deployment.
p=quarantine — Enforcement begins. Failing messages are moved to the recipient’s spam or junk folder. Some receivers may also add warning banners. This policy provides real protection while leaving a fallback in case legitimate mail is accidentally failing.
p=reject — Full enforcement. Receiving servers refuse to accept messages that fail DMARC at the SMTP level — they are never delivered to the inbox or spam folder. This is the target policy for any domain that wants maximum protection against spoofing.
What a DMARC Record Looks Like
A DMARC record is a TXT record published at _dmarc.yourdomain.com. A minimal monitoring record looks like this:
v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.comA stricter enforcement record with more options:
v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourdomain.com; ruf=mailto:dmarc-forensic@yourdomain.com; sp=reject; adkim=s; aspf=s; pct=100The most important tags are:
| Tag | Description | Example |
|---|---|---|
v= |
Protocol version — always DMARC1 | v=DMARC1 |
p= |
Policy for the domain | p=reject |
sp= |
Policy for subdomains (inherits p= if omitted) |
sp=quarantine |
rua= |
Aggregate report destination | rua=mailto:reports@example.com |
ruf= |
Forensic report destination | ruf=mailto:forensic@example.com |
pct= |
Percentage of failing mail to apply policy to (1–100) | pct=25 |
adkim= |
DKIM alignment mode: r (relaxed) or s (strict) |
adkim=r |
aspf= |
SPF alignment mode: r (relaxed) or s (strict) |
aspf=r |
fo= |
Forensic report options | fo=1 |
DMARC Reporting: Aggregate and Forensic Reports
One of the most valuable features of DMARC is its reporting capability.
Aggregate reports (rua) are sent daily by receiving mail servers to the address specified in your rua tag. They are XML files summarising all email traffic that claimed to be from your domain — including IP addresses, sending domains, SPF and DKIM results, and whether DMARC passed or failed. Aggregate reports let you see your full sending landscape without exposing message content.
Forensic reports (ruf) are triggered by individual authentication failures and may include a copy of the message headers (and sometimes the full message, depending on the receiver’s privacy settings). Not all receiving servers send forensic reports, and some organisations skip the ruf tag due to privacy considerations.
To receive aggregate reports from third-party domains (if your rua address is at a different domain than the sender), the reporting destination domain must publish a DMARC external authorization record. For example, if example.com sends reports to reports@reportingservice.com, then _dmarc.example.com._report._dmarc.reportingservice.com must exist with the value v=DMARC1.
How DMARC Protects Against Email Spoofing
Email spoofing — forging the visible “From” address to impersonate a trusted sender — is one of the most common techniques used in phishing, business email compromise (BEC), and brand abuse attacks. A forged “From: accounts@yourbank.com” in a phishing email is indistinguishable from a legitimate message unless the receiving server has instructions to check its authenticity.
DMARC eliminates the ambiguity. When a domain publishes p=reject, receiving servers have a clear, machine-readable instruction: if a message claiming to be from this domain cannot be verified through SPF or DKIM alignment, refuse it. The message never reaches the inbox.
High-profile cases of organisations moving to p=reject consistently report dramatic reductions in phishing attempts using their domain. Financial institutions, government agencies, and large enterprises with p=reject in place effectively make their domain useless for impersonation attacks — attackers quickly move on to unprotected domains.
DMARC and the Email Authentication Stack: SPF, DKIM, and DMARC
DMARC does not replace SPF or DKIM. It requires both. Understanding how they work together is essential.
SPF (Sender Policy Framework) publishes a list of IP addresses and mail servers authorised to send email for your domain. It authenticates the envelope sender — the behind-the-scenes MAIL FROM address used during SMTP delivery. SPF alone cannot prevent spoofing of the visible “From” address because the envelope sender and the From header are different fields.
DKIM (DomainKeys Identified Mail) adds a cryptographic signature to email headers. The signing domain publishes a public key in DNS, and receivers verify the signature on arrival. DKIM persists through forwarding because it is tied to the message content, not the transmission path. However, DKIM alone does not prevent a spoofed From header either — a spammer can sign a message with their own domain’s DKIM key while putting your domain in the From address.
DMARC closes the gap by requiring alignment: the domain authenticated by SPF or DKIM must match the From address the recipient sees. It then adds the policy instruction (p=) and the reporting mechanism (rua=, ruf=).
The three standards work as a stack. All three must be correctly configured for full protection.
How to Check Your DMARC Record
You can check whether a domain has a valid DMARC record in two ways.
Using nslookup.net’s free DMARC lookup tool: Go to nslookup.net/tools/dmarc-checker, enter the domain, and click “Check DMARC”. The tool queries _dmarc.yourdomain.com and validates every tag — policy, alignment modes, reporting addresses, and subdomain policy. It also checks that your SPF and DKIM are in place and highlights any issues that would prevent DMARC from working correctly.
Using the command line: Run the following in a terminal:
dig TXT _dmarc.example.comOr with nslookup:
nslookup -type=TXT _dmarc.example.comIf no record is returned, the domain has no DMARC policy. If a record is returned, verify that it begins with v=DMARC1 and contains a valid p= tag.
How to Deploy DMARC: A Step-by-Step Guide
DMARC deployment should follow a phased approach. Jumping directly to p=reject without first auditing your sending infrastructure will block legitimate email.
Step 1: Audit your sending sources
Before publishing any DMARC record, identify every service that sends email using your domain. This includes your primary mail server, marketing platforms (Mailchimp, HubSpot, Salesforce), support systems (Zendesk, Intercom), transactional email services (SendGrid, Postmark, Amazon SES), payroll systems, CRM tools, and any third-party application that sends automated email on your behalf.
Step 2: Ensure SPF and DKIM are configured for every sender
Every sending source must have valid SPF and DKIM alignment. Add each third-party sender’s include mechanism to your SPF record, and configure DKIM signing for each sender using either their own subdomain or your primary domain. Without SPF and DKIM in place for all senders, legitimate mail will fail DMARC and be blocked when you reach enforcement.
Step 3: Publish a p=none record and collect reports
Create a TXT record at _dmarc.yourdomain.com:
v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comThis publishes a monitoring-only policy. No filtering occurs, but receiving servers will begin sending aggregate reports to the rua address. Allow at least two to four weeks of report collection before moving forward.
Step 4: Analyse the aggregate reports
Aggregate reports are delivered as XML files. Use a DMARC report analyser to process them — many are available as free tools or services. Look for:
- IP addresses sending mail that is failing SPF or DKIM
- Third-party services not yet covered by your SPF record
- Forwarding scenarios causing SPF failures (this is normal and expected; DKIM alignment should still pass for forwarded mail)
- Any sources you do not recognise — these may be unauthorised senders or attackers already trying to spoof your domain
Step 5: Escalate to p=quarantine with pct=10
Once you are confident that all legitimate senders are authenticating correctly, move to a partial quarantine policy:
v=DMARC1; p=quarantine; pct=10; rua=mailto:dmarc@yourdomain.comThe pct=10 tag applies the quarantine policy to only 10% of failing mail. This provides a safety net — if a legitimate sender was missed during the audit, only a fraction of their messages will be affected. Monitor reports closely. Gradually increase pct to 25, 50, and 100 over several weeks.
Step 6: Move to p=reject
With pct=100 in place and no legitimate mail failing, switch to full enforcement:
v=DMARC1; p=reject; rua=mailto:dmarc@yourdomain.comAt this point, any message from your domain that fails DMARC is refused at the receiving server. Your domain is protected against spoofing.
Common DMARC Deployment Mistakes
Setting p=reject immediately. This is the most common mistake. Any unidentified sending source will have its mail silently dropped. Always start with p=none and audit before enforcing.
Not configuring DKIM for third-party senders. SPF can fail when mail is forwarded. If a third-party sender is authenticated only via SPF and not DKIM, forwarded messages from that sender will fail DMARC. Configure DKIM for every sender.
Publishing an SPF record that exceeds 10 DNS lookups. SPF has a limit of 10 DNS lookups per evaluation. Adding too many include: mechanisms causes SPF to fail with a permerror, breaking DMARC. Use SPF flattening tools to stay within the limit.
Using a subdomain policy that is too permissive. If sp= is not set, subdomains inherit the main domain’s p= policy. This is usually the correct behaviour. But if you set p=reject; sp=none, attackers can spoof marketing.yourdomain.com and billing.yourdomain.com freely.
Ignoring aggregate reports. DMARC reports are only useful if you read them. Set up regular report analysis — at minimum, check them before escalating policy and whenever you add a new sending service.
Publishing the rua address at a different domain without external authorisation. If your rua address is reports@third-party.com, the domain third-party.com must publish an authorisation record or receiving servers will not send reports there.
Frequently Asked Questions
What is the difference between DMARC, SPF, and DKIM?
SPF publishes a list of authorised IP addresses for your domain. DKIM adds a cryptographic signature to email headers. DMARC ties them together by requiring that the authenticated domain aligns with the visible “From” address, and adds a policy instruction (none, quarantine, or reject) for receivers to follow. All three are needed for complete email authentication.
Does DMARC stop all phishing?
DMARC prevents phishing that spoofs your exact domain in the From header. It does not prevent attacks using lookalike domains (such as example-support.com instead of example.com), display name spoofing (where the attacker uses your name but a different email address), or compromised accounts within your own organisation. DMARC is one layer of a broader email security strategy.
Can DMARC block legitimate email?
Yes, if SPF or DKIM is not correctly configured for all legitimate sending sources before enforcement begins. This is why the phased deployment approach — starting with p=none and analysing reports — is essential. Once all legitimate senders are verified, moving to p=reject will not affect legitimate mail.
What happens if I have no DMARC record?
Without a DMARC record, receiving servers have no policy instruction for unauthenticated mail from your domain. Most will deliver it anyway. Attackers can freely spoof your domain in phishing emails, and you have no visibility into who is sending on your behalf. Google and Yahoo now require bulk senders to have DMARC at p=none or stricter as a condition of email delivery to their users.
How do I check my DMARC record?
Use the free DMARC lookup tool at nslookup.net/tools/dmarc-checker. Enter your domain, and the tool validates your record and checks for common configuration issues. You can also run dig TXT _dmarc.yourdomain.com from the command line.
What is a good DMARC record to start with?
A good starting record is:
v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comPublish this at _dmarc.yourdomain.com, collect and review aggregate reports for two to four weeks, then follow the phased escalation path toward p=reject.
Conclusion
DMARC is the most effective technical control available to prevent your domain from being used in phishing and email spoofing attacks. By combining SPF and DKIM authentication with a policy instruction and a reporting mechanism, it closes the gap that both earlier standards leave open.
Deploying DMARC correctly requires a phased approach: start with p=none to gain visibility, audit every sending source, ensure SPF and DKIM alignment for all of them, and gradually escalate through p=quarantine to p=reject. Done carefully, the result is a domain that is effectively unusable for impersonation — and a complete picture of your email sending landscape.
To check whether your domain currently has a valid DMARC record, use the free DMARC lookup tool at nslookup.net/tools/dmarc-checker. To check your SPF record, use nslookup.net/tools/spf-checker.