How to read a DMARC record and choose the right policy

A DMARC record is a DNS TXT record that helps protect a domain from unauthorised email use. It works with SPF and DKIM, then tells receiving mail systems what to do when an email claims to come from the domain but does not pass the required checks.

This guide explains how to read a DMARC record, what the main values mean, and what should be checked before moving to a stronger policy such as p=quarantine or p=reject.

It is written for people who need to understand DMARC in a practical way, including small businesses, professionals, website owners, and organisations using Microsoft 365, Google Workspace, website forms, CRM systems, marketing platforms or other third party senders.

For broader context on SPF, DKIM, DMARC and MTA STS, see our guide to email validation and security.

Use the links below to jump to the section most relevant to your question.

• What is a DMARC record?
• How to read a DMARC record
• DMARC record examples
• What do p=none, p=quarantine and p=reject mean?
• How SPF and DKIM affect DMARC
• Why DMARC alignment matters
• Should DMARC use strict or relaxed alignment?
• What happens if SPF or DKIM is missing?
• Should SPF use ~all or -all?
• What do rua, ruf, sp, fo, aspf and adkim mean?
• Do spaces matter in DMARC records?
• How DMARC reports are used
• Common DMARC record mistakes
• Why a DMARC generator is not enough by itself
• How to move safely towards p=reject
• What DMARC does not do
• Frequently asked questions
• Supporting references
• Further Guidance and Support

A DMARC record is a DNS TXT record published for a domain. It gives receiving mail systems instructions about messages that claim to come from that domain but fail DMARC checks.

DMARC stands for Domain based Message Authentication, Reporting and Conformance. In practical terms, it helps the owner of a domain reduce the risk of someone sending unauthorised email that appears to come from that domain.

A DMARC record is normally published at:

_dmarc.example.com

A simple DMARC record may look like this:

v=DMARC1; p=none; rua=mailto:dmarcreports@example.com

This tells receiving mail systems that the domain has a DMARC policy and that aggregate reports should be sent to the listed reporting address.

DMARC has two main purposes.

1. 1. It gives receiving mail systems a policy for messages that fail DMARC checks.
   2. It allows the domain owner to receive reports showing which systems are sending email using the domain.

This matters because many email attacks rely on trust. A fake invoice, fake login alert or fake supplier message can be more convincing if it appears to come from a familiar domain. DMARC does not stop every phishing email, but it helps reduce unauthorised use of a real domain.

A DMARC record is made from small parts called tags. Each tag has a name, an equals sign and a value.

For example:

v=DMARC1; p=reject; sp=reject; rua=mailto:dmarcreports@example.com; aspf=s; adkim=s; fo=1

This record can be read in sections.

v=DMARC1

This identifies the record as a DMARC record. It must be the first tag.

p=reject

This is the main policy for the domain. It asks receiving mail systems to reject messages that fail DMARC.

sp=reject

This applies a reject policy to subdomains.

rua=mailto:dmarcreports@example.com

This tells receivers where to send aggregate DMARC reports.

aspf=s

This sets SPF alignment to strict.

adkim=s

This sets DKIM alignment to strict.

fo=1

This requests failure reports when either SPF or DKIM fails to produce a DMARC pass, where supported by the receiver.

A DMARC record can be technically valid but still operationally risky if it does not match the real email environment. The record should be read alongside SPF, DKIM and the list of legitimate sending services.

DMARC records can be simple or strict depending on the stage of deployment and the organisation’s email setup. The right record depends on what sends email for the domain and whether SPF and DKIM are aligned correctly.

A monitoring record may look like this:

v=DMARC1; p=none; rua=mailto:dmarcreports@example.com

This record collects reports but does not ask receiving systems to reject or quarantine failed messages because of DMARC.

A stronger record may look like this:

v=DMARC1; p=reject; sp=reject; rua=mailto:dmarcreports@example.com; aspf=s; adkim=s; fo=1

This asks receiving systems to reject messages that fail DMARC and applies a reject policy to subdomains. It also uses strict SPF and DKIM alignment.

A more cautious enforcement record may look like this:

v=DMARC1; p=reject; sp=reject; rua=mailto:dmarcreports@example.com; aspf=r; adkim=r; fo=1

This still uses a reject policy, but keeps relaxed alignment. For many organisations, this may be safer than strict alignment unless all legitimate senders have been confirmed to align exactly.

These examples should not be copied blindly. A record that works well for a dedicated sending subdomain may not be suitable for a main business domain used by several systems.

The main DMARC policy is controlled by the p tag. This tells receiving mail systems what the domain owner wants to happen when a message fails DMARC.

There are three main policy values.

1. 1. p=none

This means monitoring only. Messages that fail DMARC are not rejected because of the DMARC policy.

This is commonly used at the beginning of a DMARC project. It allows the domain owner to collect reports and identify legitimate sending sources before stronger enforcement is applied.

1. 2. p=quarantine

This asks receiving mail systems to treat failed messages as suspicious.

In practice, this may mean the message is placed in spam or handled with extra caution. Different receiving systems may apply this differently.

1. 3. p=reject

This asks receiving mail systems to reject messages that fail DMARC.

This is the strongest normal enforcement policy. It can be appropriate once legitimate senders have been reviewed and SPF or DKIM alignment is working correctly.

A strong policy is useful only when it matches the real email environment. If a business uses Microsoft 365, website contact forms, CRM systems, invoicing systems and marketing platforms, each sending source needs to be considered before moving to p=reject.

DMARC does not replace SPF or DKIM. It sits above them and uses their results to make a domain level decision.

SPF checks whether the sending mail server is authorised to send for a domain. This is based on the SPF record published in DNS.

DKIM checks whether the email has a valid digital signature linked to a domain. This is also based on DNS records.

DMARC then asks an extra question. It does not only ask whether SPF or DKIM passed somewhere. It asks whether the passing result aligns with the visible From address.

For example, a recipient may see this From address:

accounts@example.com

If SPF passes for example.com, and that result aligns with the visible From domain, DMARC can pass.

If DKIM passes with a signature for example.com, and that result aligns with the visible From domain, DMARC can pass.

A message does not need both SPF and DKIM to pass DMARC. It can pass DMARC if either SPF or DKIM passes and aligns correctly.

This is one of the most important points in DMARC. SPF passing somewhere is not always enough. DKIM passing somewhere is not always enough. The passing result must align with the domain shown in the visible From address.

Alignment is the part of DMARC that often causes confusion. It is the reason why an email can appear to pass SPF or DKIM but still fail DMARC.

The visible From address is what the recipient normally sees. DMARC uses this visible domain as the main identity to protect.

SPF uses the envelope sender or return path domain. This is often used for bounces and mail handling.

DKIM uses the signing domain shown in the DKIM signature.

DMARC checks whether the SPF domain or DKIM signing domain lines up with the visible From domain.

For example, an email may show:

news@example.com

But the SPF return path may use:

bounce.thirdpartyplatform.example

Or the DKIM signature may use:

thirdpartyplatform.com

Those technical values may be valid for the sending platform, but they may not align with example.com.

If neither SPF nor DKIM produces an aligned pass, DMARC fails.

This is why DMARC is not only a question of adding one DNS record. It requires understanding which systems send email and which domain each system uses for authentication.

DMARC alignment can be relaxed or strict. These settings are controlled by the aspf and adkim tags.

The SPF alignment setting is:

aspf

The DKIM alignment setting is:

adkim

Each can use either r for relaxed or s for strict.

Relaxed alignment allows a related subdomain to align with the main domain.

For example, mail.example.com may be treated as aligned with example.com if relaxed alignment is used.

Strict alignment requires an exact match.

If the visible From domain is:

example.com

then the SPF or DKIM authenticated domain must also be:

example.com

This means the following record uses strict alignment:

v=DMARC1; p=reject; aspf=s; adkim=s

Strict alignment can be a good security position once all legitimate sending services have been reviewed and tested. It reduces the amount of flexibility that related subdomains have.

However, strict alignment can also increase the risk of legitimate email failing DMARC. This is especially relevant where third party platforms, marketing systems, websites, booking systems or CRM tools send email on behalf of the domain.

For many organisations, relaxed alignment is safer during discovery and early rollout:

v=DMARC1; p=none; aspf=r; adkim=r

A stricter record can be considered later once reports show that legitimate email sources are passing correctly.

DMARC needs at least one aligned pass from SPF or DKIM. It does not require both to pass, but it does require one of them to pass and align.

If a domain has no working SPF path and no working DKIM path for a message, DMARC will fail.

If SPF exists but does not align with the visible From domain, SPF will not help DMARC pass.

If DKIM exists but the signing domain does not align with the visible From domain, DKIM will not help DMARC pass.

This becomes more important when strict alignment is used:

aspf=s; adkim=s

With strict alignment, the match must be exact.

For example, a business sends email from:

hello@example.com

The message is sent through a third party platform.

SPF passes, but the SPF authenticated domain is:

bounce.thirdpartyplatform.com

DKIM passes, but the DKIM signing domain is:

thirdpartyplatform.com

If the DMARC record uses strict alignment, neither authenticated domain exactly matches example.com. The message may therefore fail DMARC, even though SPF and DKIM passed technically.

This is why strict alignment should not be copied into a DMARC record without checking how email is actually sent.

SPF records often end with either ~all or -all. These look similar, but they do not mean the same thing.

~all means softfail. In plain English, the domain owner is saying that any sender not already listed in the SPF record is probably not authorised.

-all means fail. In plain English, the domain owner is saying that any sender not already listed in the SPF record is not authorised.

Many vendor examples use ~all because it is safer during initial setup. It reduces the chance of disrupting legitimate email if the organisation has not yet identified every system that sends email on behalf of the domain.

Once authorised sending sources have been confirmed, -all is normally the stronger security position.

This is especially true for a dedicated sending subdomain. For example, if a subdomain such as mail.example.com is used only by one authorised platform, the SPF record should normally identify that platform and then end with -all once testing has confirmed that no other legitimate sender is required.

Example:

v=spf1 include:example-sending-platform.com -all

For a main business domain, the decision may require more care. Email may be sent from Microsoft 365, Google Workspace, website forms, invoicing systems, CRM tools, booking platforms, marketing systems, helpdesk platforms or other third party services.

The practical rule is to use ~all during discovery, testing or uncertain rollout, and move to -all once the authorised senders are known and the record has been tested.

A DMARC record can include several tags. Some are required, while others adjust reporting, subdomain policy or alignment behaviour.

The most common tags are listed below.

1. 1. v

This is the version tag. It must be v=DMARC1 and it must appear first.

1. 2. p

This is the main policy for the domain. Common values are none, quarantine and reject.

1. 3. sp

This is the subdomain policy. For example, sp=reject asks receivers to reject failed messages from subdomains.

If sp is not used, subdomains normally inherit the main domain policy unless they publish their own DMARC record.

1. 4. rua

This defines where aggregate DMARC reports should be sent. These reports are normally the most useful for understanding sending sources.

Example:

rua=mailto:dmarcreports@example.com

1. 5. ruf

This defines where failure reports should be sent. Failure reports can contain more message level detail and are not supported by all receivers. They should be handled carefully because they may contain sensitive information.

Example:

ruf=mailto:dmarcreports@example.com

1. 6. aspf

This controls SPF alignment. The value can be r for relaxed or s for strict.

1. 7. adkim

This controls DKIM alignment. The value can be r for relaxed or s for strict.

1. 8. fo

This controls when failure reports are requested. For example, fo=1 requests failure reports when either SPF or DKIM fails to produce a DMARC pass, where supported by the receiver.

Some older examples and some tools also show pct and ri. The pct tag was historically used for percentage based rollout, and ri was historically used to request a reporting interval. Current DMARC standards treat these as historic, although they may still appear in older records, tools and examples.

For most small organisations, these historic values should not be treated as a substitute for reviewing reports and testing real sending behaviour.

Spaces after semicolons normally do not matter in a DMARC record. They are usually added for readability.

These two records are both readable forms of the same basic policy:

v=DMARC1;p=reject;sp=reject;pct=100

v=DMARC1; p=reject; sp=reject; pct=100

The space after each semicolon is cosmetic. What matters much more is the structure of the record.

A DMARC record must start with:

v=DMARC1

The v tag must be the first tag in the record, and DMARC1 must be written exactly like that. If the version tag is missing, placed later in the record, or written incorrectly, the whole DMARC record may be ignored.

For readability, it is sensible to standardise on one space after each semicolon:

v=DMARC1; p=reject; sp=reject; rua=mailto:dmarcreports@example.com; ruf=mailto:dmarcreports@example.com; aspf=s; adkim=s; fo=1

Avoid adding spaces inside tag names, domain names, email addresses or mailto: values.

For example, do not write:

rua=mailto: dmarcreports@example.com

The space after mailto: would make the reporting address invalid or unreliable.

DMARC reports help the domain owner understand who is sending email using the domain. This is important before moving from monitoring to enforcement.

Aggregate reports are usually the most useful starting point. They show sending sources, volumes, SPF results, DKIM results, alignment results and what policy was applied by the receiver.

These reports are normally sent to the address listed in the rua tag.

Example:

rua=mailto:dmarcreports@example.com

Aggregate reports are usually XML files. They can be difficult to read manually, so many organisations use a DMARC monitoring platform to process them.

Failure reports are different. They are requested with the ruf tag and controlled partly by the fo tag. They may include more detailed information about individual failed messages. Not all receivers send them, and they may contain sensitive message information.

For small organisations, the most practical use of reports is to answer these questions:

1. 1. Which services are sending email using the domain?
   2. Are Microsoft 365 or Google Workspace messages passing correctly?
   3. Are website forms sending email correctly?
   4. Are CRM, marketing, invoicing or ticketing systems aligned?
   5. Are unknown sources trying to use the domain?
   6. Is it safe to move from monitoring to quarantine or reject?

Reports are not just technical logs. They are evidence for making safer policy decisions.

DMARC records are short, but small mistakes can make them invalid or less useful. This is why the record should be checked after it is created or changed.

Common mistakes include the following.

1. 1. Multiple DMARC TXT records

There should normally be only one DMARC TXT record for a domain. If more than one DMARC record exists at the same _dmarc name, receivers may ignore DMARC processing for that domain.

1. 2. Missing or incorrect version tag

The record must start with v=DMARC1. The value DMARC1 is case sensitive.

1. 3. Wrong separators

DMARC tags are separated with semicolons. Report addresses inside rua and ruf are separated with commas.

Correct:

rua=mailto:first@example.com,mailto:second@example.com

Incorrect:

rua=mailto:first@example.com;mailto:second@example.com

1. 4. Missing mailto: in report addresses

DMARC report addresses should use the mailto: format.

Correct:

rua=mailto:dmarcreports@example.com

Incorrect:

rua=dmarcreports@example.com

1. 5. Copying strict alignment without testing

The settings aspf=s and adkim=s can be valid, but they should not be copied blindly. They require exact alignment and may cause legitimate email to fail DMARC if sending services have not been configured correctly.

1. 6. Treating a generated record as a complete implementation

DMARC generators can help create a valid record, but they cannot fully understand every legitimate sender in a real organisation. The generated value still needs to be reviewed against Microsoft 365, Google Workspace, website forms, CRM systems, marketing platforms and other sending services.

1. 7. Forgetting to check the record after DNS tools modify it

Some DNS platforms and email security tools can help manage DMARC records. That can be useful, but the final DNS value should still be checked after any automatic change. A missing semicolon, duplicated value or malformed report address can break an otherwise good record.

A DMARC generator can help create a correctly formatted record. It is useful for avoiding obvious syntax mistakes and for selecting common values.

However, a generator cannot know how a real organisation sends email. It cannot automatically know whether the domain uses Microsoft 365, Google Workspace, website forms, Salesforce, a booking platform, an invoicing tool, a helpdesk system, a CRM system, or a marketing platform.

This means a generated record may be valid but still unsuitable.

For example, a generator may produce a record such as:

v=DMARC1; p=reject; sp=reject; rua=mailto:dmarcreports@example.com; aspf=s; adkim=s; fo=1

This record may look strong, but it uses p=reject, applies reject to subdomains, and uses strict SPF and DKIM alignment.

That may be appropriate for a dedicated sending subdomain where only one authorised platform sends email and everything has been tested.

It may be risky for a main business domain if legitimate senders have not been reviewed.

A DMARC generator should therefore be treated as a starting point, not a final decision. The record still needs to be checked against the organisation’s real email systems, DNS records and reporting evidence.

A stronger DMARC policy should normally be introduced in stages. The aim is not only to publish a strict looking record, but to make sure legitimate email continues to work.

A practical sequence is:

1. 1. Confirm SPF and DKIM are configured for the main email provider.
   2. Identify all systems that send email using the domain or its subdomains.
   3. Publish a DMARC monitoring policy using p=none and rua reporting.
   4. Review reports to identify legitimate and unknown sources.
   5. Correct SPF, DKIM and alignment issues for legitimate senders.
   6. Consider quarantine when reports show that normal mail is passing.
   7. Move to reject only when the organisation is confident that legitimate senders are aligned.
   8. Review the record periodically because email platforms, DNS providers and business systems change.

Dedicated sending subdomains are often easier to secure than a main business domain. For example, if mail.example.com is used only by one marketing platform, it may be easier to use strict SPF, strict DKIM and a stronger DMARC policy after testing.

Main domains used for normal person to person email require more care. Forwarding, mailing lists, aliases, website forms and third party platforms can all affect how authentication appears to receiving systems.

This guide is not a permanent checklist. Email systems, standards and provider behaviour change over time. DMARC should be treated as part of a layered security approach that includes DNS hygiene, account security, endpoint protection, user awareness and periodic review.

DMARC is useful, but it is not complete email security. It protects a specific part of the email trust model.

DMARC does not stop every phishing email. Attackers can still use lookalike domains, compromised real accounts, free email addresses, display name tricks or malicious links.

DMARC does not prove that an email is safe. A message can pass SPF, DKIM and DMARC and still contain a bad link, a malicious attachment or a fraudulent request if it was sent from a compromised legitimate system.

DMARC does not replace mailbox protection. Microsoft Defender for Office 365, Google Workspace security controls, spam filtering, anti malware scanning, safe links, safe attachments and user reporting still matter.

DMARC does not replace account security. Multi factor authentication, conditional access, strong passwords, device protection and careful administration are still important.

DMARC does not maintain itself. New systems may be added later, suppliers may change sending infrastructure, DNS records may be modified, and old platforms may continue sending unnoticed.

The practical view is that DMARC reduces one important risk. It should be reviewed alongside SPF, DKIM, MTA STS, DNS configuration, mailbox protection and wider security controls.

This section answers common practical questions about DMARC records and policy settings. The answers are simplified for readability, but they should still be treated as configuration guidance rather than universal instructions for every domain.

Does DMARC require both SPF and DKIM to pass?

No. DMARC can pass if either SPF or DKIM passes and aligns with the visible From domain.

However, if neither SPF nor DKIM produces an aligned pass, DMARC fails.

Is p=reject always the best DMARC policy?

p=reject is the strongest normal enforcement policy, but it is not always the right first step.

For a new implementation, p=none is often used first to collect reports and understand legitimate sending sources. p=reject is more suitable once SPF, DKIM and alignment have been reviewed.

Should strict alignment always be used?

No. Strict alignment can be suitable when all legitimate senders are configured to match the visible From domain exactly.

Relaxed alignment is often safer during discovery or early rollout because it allows related subdomains to align. Strict alignment should be introduced only when the real email environment supports it.

Should SPF use ~all or -all?

~all is a softfail. It says an unlisted sender is probably not authorised.

-all is a fail. It says an unlisted sender is not authorised.

For a dedicated sending subdomain where only one platform should send, -all is normally the better security position after testing. For a main business domain, the decision should follow a review of all legitimate senders.

Do spaces after semicolons break DMARC?

No, spaces after semicolons normally do not break DMARC. They are usually cosmetic and help readability.

The record must still start with v=DMARC1, and spaces should not be inserted inside tag names, domain names, mailto: values or email addresses.

Is rua required?

The rua tag is not always technically required, but it is strongly recommended. Without aggregate reports, the domain owner has much less visibility into which systems are sending email using the domain.

Is ruf required?

No. The ruf tag requests failure reports, but these are not supported by all receivers and may contain sensitive information. Many organisations prioritise aggregate reporting first.

Can a DMARC generator create the correct record automatically?

A generator can create a syntactically valid record, but it cannot know every legitimate sender in the organisation. The generated record still needs to be reviewed against the real email environment.

Can DMARC break email?

DMARC does not usually affect delivery by itself when set to p=none. Stronger policies such as quarantine or reject can affect legitimate email if SPF, DKIM or alignment are not configured correctly for real sending sources.

Should subdomains use sp=reject?

sp=reject can be appropriate where subdomains should not send unauthorised email. It is a strong posture, but subdomains used by legitimate platforms should be checked first.

Why does a DMARC checker show a warning even when the record looks correct?

A checker may flag missing reporting addresses, strict alignment, historic tags, missing subdomain policy or formatting issues. Some warnings are about best practice rather than invalid syntax. The result should be interpreted in context.

This guide is based on practical email security and DNS configuration experience, supported by published technical standards and provider guidance.

Relevant supporting references include:

1. 1. RFC 9989, Domain Based Message Authentication, Reporting and Conformance.
   2. RFC 9990, DMARC Aggregate Reporting.
   3. RFC 9991, DMARC Failure Reporting.
   4. RFC 7208, Sender Policy Framework.
   5. Google Workspace Help, Set up DMARC.
   6. Existing Evening Computing guide, Email validation and security explained.

A guide can explain the values and the risks, but DNS records should be changed carefully when a domain is used for business email, website forms, marketing systems or other third party services.

Evening Computing can help review SPF, DKIM, DMARC and related DNS records, identify legitimate sending sources, and advise on staged improvements where appropriate.

This is especially useful where a domain uses Microsoft 365, Google Workspace, Salesforce, website contact forms, CRM platforms, invoicing systems, marketing tools or multiple suppliers.

This guide forms part of a broader layered security approach. For structured guidance on security and resilience planning, see our Security and Resilience page.

For information about practical implementation and ongoing support, you can review our IT services and local IT support coverage across London, Hertfordshire, and Essex.

Return to all guides

Author
Elías Sánchez
IT Support Consultant
Evening Computing
London, United Kingdom

This guide was prepared by Elías Sánchez with research and drafting assistance from AI tools. All technical content has been reviewed and adapted for clarity and accuracy.

Last reviewed
18 June 2026