DMARC Record Checker: Add a Safe Policy for Domain Email

Quick answer: what should a DMARC checker look for?

A useful DMARC checker should check whether your domain has:

The most important rule: DMARC is not a replacement for SPF or DKIM. It works on top of SPF and DKIM.

What is DMARC?

DMARC stands for Domain-based Message Authentication, Reporting, and Conformance.

It lets a domain publish a rule that says: If an email claims to be from this domain but fails authentication and alignment checks, here is how receiving mail servers should handle it.

DMARC helps protect your domain from spoofing, phishing, and unauthorized sending.

For example, without DMARC, an attacker may try to send email that appears to come from:

billing@example.com

DMARC gives receivers a policy for deciding whether suspicious messages should be accepted, quarantined, or rejected.

Where is a DMARC record published?

A DMARC record is published as a TXT record at:

_dmarc.example.com

For the domain:

example.com

the DMARC host/name should be:

_dmarc

or, depending on the DNS provider interface:

_dmarc.example.com

A basic DMARC record looks like this:

v=DMARC1; p=none;

A stricter record may look like this:

v=DMARC1; p=quarantine;

or:

v=DMARC1; p=reject;

DMARC record parts explained

Here is a simple DMARC record:

v=DMARC1; p=none;

A more detailed record may look like this:

v=DMARC1; p=none; rua=mailto:dmarc@example.com; adkim=s; aspf=s;

Most small businesses should not start with an overly complex DMARC record. A simple, valid record is usually better than an incorrect advanced record.

DMARC policies: none, quarantine, reject

DMARC has three main policy levels.

What does p=none mean?

A DMARC record with p=none tells receivers: Do not block mail because of this DMARC policy yet. I am monitoring.

Example:

v=DMARC1; p=none;

This is usually the safest starting point.

When p=none is useful

Use p=none when:

• You are setting up DMARC for the first time
• You are not sure all legitimate senders are authenticated
• You recently changed email providers
• You use several third-party platforms
• You want to collect reports before enforcing a stricter policy

Limitation of p=none

p=none is not strong protection. It publishes a DMARC policy, but it does not ask receivers to quarantine or reject failing mail.

Think of it as the monitoring stage, not the final destination.

What does p=quarantine mean?

A DMARC record with p=quarantine tells receivers: If mail fails DMARC, treat it as suspicious.

Example:

v=DMARC1; p=quarantine;

In practice, this may cause failing messages to be sent to spam or junk folders, depending on the receiving mail provider.

When to use p=quarantine

Move to p=quarantine when:

• Your main email provider passes authentication
• DKIM has been confirmed in real message headers
• SPF is clean and not duplicated
• You understand your legitimate third-party senders
• You have tested email from key systems such as website forms, CRMs, invoicing tools, and email marketing platforms

Risk of moving too early

If a legitimate sender is not authenticated correctly, its messages may be treated as suspicious.

That could affect:

• Contact form notifications
• Booking confirmations
• Invoices
• Receipts
• Password reset emails
• CRM emails
• Marketing campaigns
• Helpdesk replies

What does p=reject mean?

A DMARC record with p=reject tells receivers: If mail fails DMARC, reject it.

Example:

v=DMARC1; p=reject;

This is the strongest DMARC policy. It gives the clearest instruction to block unauthorized mail using your domain.

When to use p=reject

Use p=reject only when:

• You know all legitimate sending sources
• SPF and/or DKIM pass correctly for those sources
• DMARC alignment is working
• You have tested important email flows
• You have already gone through a monitoring or quarantine stage
• You are ready to enforce domain protection more strictly

Why not start with p=reject?

Starting with p=reject can break legitimate mail if your setup is incomplete.

This is especially risky if your domain sends from multiple platforms, such as:

• Google Workspace or Microsoft 365
• Website contact forms
• Shopify or ecommerce tools
• Stripe or invoicing platforms
• CRM systems
• Newsletter tools
• Helpdesk tools
• Booking systems
• Transactional email providers

DMARC depends on SPF and DKIM

DMARC does not work by itself.

It checks whether the message passes SPF or DKIM in a way that aligns with the visible From domain.

The visible From domain is the domain users see in their inbox, such as:

From: Your Company <hello@example.com>

For DMARC to pass, the email usually needs either:

• SPF pass with alignment, or
• DKIM pass with alignment

It does not always need both, but having both correctly configured is better.

SPF alignment explained simply

SPF checks whether the sending server is allowed to send for the envelope sender domain.

DMARC then checks whether that authenticated domain aligns with the visible From domain.

Example:

Visible From: hello@example.com
Return-path: bounce@example.com

This is aligned because both use example.com.

But this may not align:

Visible From: hello@example.com
Return-path: bounce.thirdpartyservice.com

SPF may pass for the third-party service, but DMARC alignment may fail because the authenticated SPF domain does not match your visible From domain.

This is why many sending platforms ask you to configure a custom return-path, custom bounce domain, or DKIM authentication.

DKIM alignment explained simply

DKIM signs the message with a domain.

DMARC checks whether the DKIM signing domain aligns with the visible From domain.

Example:

Visible From: hello@example.com
DKIM signing domain: example.com

This is aligned.

But this may not align:

Visible From: hello@example.com
DKIM signing domain: emailservice.com

The message may have a valid DKIM signature, but not aligned with your domain for DMARC.

For reliable DMARC passing, third-party senders often need domain authentication so they can sign with your domain or a related subdomain.

Relaxed vs strict alignment

DMARC supports relaxed and strict alignment.

A DMARC record can specify alignment using:

adkim=s

for strict DKIM alignment, or:

aspf=s

for strict SPF alignment.

If these are not specified, many setups use relaxed alignment by default.

For most small businesses, relaxed alignment is usually easier to manage. Strict alignment can be useful for more advanced security setups, but it should be used carefully.

Common DMARC problems

Missing DMARC record: what it means

If a DMARC checker says your domain has no DMARC record, it usually means no TXT record was found at:

_dmarc.example.com

This does not always mean your email will stop working. But it does mean your domain is missing a major authentication policy layer.

Why missing DMARC matters

Without DMARC:

• Receivers have less guidance on failed authentication
• Your domain is more exposed to spoofing
• You cannot clearly tell receivers to quarantine or reject suspicious mail
• You may fail email compliance checks from some platforms
• Your domain setup looks incomplete

Basic fix

A safe starting record is:

v=DMARC1; p=none;

Add this as a TXT record at:

_dmarc

Then review SPF and DKIM before moving to a stricter policy.

Invalid DMARC record: what to check

If your DMARC record exists but appears invalid, check:

1. Is it published at _dmarc.example.com?
2. Does it start with v=DMARC1?
3. Does it contain a valid p= policy?
4. Is there only one DMARC record?
5. Are tags separated by semicolons?
6. Are reporting addresses formatted correctly?
7. Did you accidentally paste smart quotes or hidden characters?
8. Did you add the record at the wrong DNS host?

A clean basic DMARC record should look like:

v=DMARC1; p=none;

Do not overcomplicate the first version.

Duplicate DMARC records

A domain should normally have only one DMARC record.

This is wrong:

v=DMARC1; p=none;

v=DMARC1; p=reject;

Receivers may not know which policy to apply.

If you find duplicate DMARC records, decide which policy is correct and publish only one valid DMARC record at _dmarc.

DMARC reporting: rua and ruf

DMARC can include reporting addresses.

Aggregate reports: rua

Aggregate reports are summary reports. They may show which sources are sending email for your domain and whether they pass SPF, DKIM, and DMARC.

Example:

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

Forensic reports: ruf

Forensic reports are more detailed failure reports. They are less commonly supported and may involve privacy considerations.

Example:

v=DMARC1; p=none; ruf=mailto:dmarc-forensic@example.com;

For many small businesses, aggregate reports are more practical than forensic reports.

Important note about reports

DMARC reports can be technical and noisy. If you add a reporting address, make sure the mailbox exists and is monitored, or use a proper DMARC report analysis service.

Should every domain have DMARC?

Yes, most business domains should have at least a basic DMARC record.

Even if you are not ready for p=quarantine or p=reject, a basic p=none policy helps establish a starting point.

This is especially important if the domain is used for:

• Customer communication
• Invoices
• Password resets
• Booking confirmations
• Sales emails
• Support replies
• Newsletters
• Login links
• Anything involving trust or payments

A domain that sends business email should not ignore DMARC.

Safe DMARC rollout plan

Use this sequence:

Stage 1: Check SPF and DKIM

Before enforcing DMARC, confirm:

• SPF exists
• SPF is not duplicated
• DKIM is enabled for your main email provider
• Important third-party senders are authenticated
• Test messages pass authentication

Stage 2: Start with monitoring

Publish:

v=DMARC1; p=none;

This creates a DMARC policy without asking receivers to block mail.

Stage 3: Review legitimate senders

Check all systems that send email from your domain:

• Google Workspace
• Microsoft 365
• Website forms
• Ecommerce platforms
• CRM
• Newsletter tools
• Helpdesk systems
• Transactional email services
• Invoicing platforms

Make sure they are authenticated properly.

Stage 4: Move to quarantine

When confident, move to:

v=DMARC1; p=quarantine;

Monitor whether any legitimate email is affected.

Stage 5: Move to reject

When you are confident all legitimate email passes DMARC, move to:

v=DMARC1; p=reject;

This is the strongest common enforcement policy.

Gradual enforcement using pct

DMARC supports a pct tag that can apply policy to only a percentage of failing messages.

Example:

v=DMARC1; p=quarantine; pct=25;

This means the quarantine policy applies to a portion of messages, not necessarily all of them.

You may gradually increase:

pct=25
pct=50
pct=75
pct=100

For many small businesses, this may be more advanced than necessary. But it can be useful when moving carefully toward enforcement.

Example DMARC records

Basic monitoring record

v=DMARC1; p=none;

Use this when you are starting out.

Monitoring with aggregate reports

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

Use this if you have a mailbox or reporting tool ready to receive reports.

Quarantine policy

v=DMARC1; p=quarantine;

Use this after SPF/DKIM are working and legitimate senders are known.

Reject policy

v=DMARC1; p=reject;

Use this only after testing.

Reject policy with reports

v=DMARC1; p=reject; rua=mailto:dmarc@example.com;

Use this when you are enforcing DMARC and want reporting.

DMARC for Google Workspace domains

For a Google Workspace domain, check:

• Google Workspace MX records are correct
• SPF includes Google if Google sends mail
• DKIM is generated and enabled in Google Admin
• DMARC exists at _dmarc
• Third-party senders are authenticated if they send from your domain

A safe starting DMARC record is:

v=DMARC1; p=none;

Do not move straight to p=reject unless Google DKIM is confirmed in real message headers and any third-party senders are properly authenticated.

DMARC for Microsoft 365 domains

For a Microsoft 365 domain, check:

• Microsoft 365 MX record is correct
• SPF includes Microsoft 365 if Microsoft sends mail
• DKIM CNAME records are configured
• DKIM is enabled
• DMARC exists at _dmarc
• Other sending platforms are accounted for

A safe starting DMARC record is:

v=DMARC1; p=none;

After SPF, DKIM, and third-party senders are verified, you can consider moving to quarantine or reject.

DMARC and third-party sending platforms

Many DMARC failures happen because of third-party senders.

Examples:

• Email newsletter tools
• CRM platforms
• Cold email tools
• Helpdesk systems
• Website contact forms
• Ecommerce platforms
• Transactional email providers
• Booking tools
• Invoice tools

A platform may send email using your visible From domain, but fail DMARC because SPF or DKIM is not aligned.

To fix this, follow the provider's domain authentication instructions. That may involve:

• DKIM CNAME records
• DKIM TXT records
• Custom return-path or bounce domain
• SPF include
• Verified sending domain
• Subdomain setup

Do not assume that adding SPF alone fixes every third-party sender. DKIM alignment is often more reliable for DMARC.

DMARC and subdomains

DMARC can also apply to subdomains.

For example:

example.com

and:

mail.example.com

may have different sending setups.

The main DMARC policy applies to the organizational domain, but you can also define subdomain behavior using the sp= tag.

Example:

v=DMARC1; p=reject; sp=quarantine;

This says the main domain policy is reject, while the subdomain policy is quarantine.

Most small businesses do not need complex subdomain DMARC at the start. But it becomes useful if different subdomains are used for marketing, transactional email, or support.

What to check before changing DMARC to reject

Before moving to p=reject, confirm:

• Your main email provider passes DKIM
• Your SPF record is clean and not duplicated
• Your website forms still send correctly
• Your CRM emails pass authentication
• Your email marketing platform is authenticated
• Your invoicing or receipt emails are authenticated
• Your helpdesk replies pass authentication
• Your transactional emails pass authentication
• Your DMARC reports do not show important unknown legitimate sources
• Your team understands that failing messages may be rejected

Do not use p=reject as a shortcut. It is a strong policy and should be used after verification.

What to do if DMARC fails

If a test email fails DMARC, check:

1. Did SPF pass?
2. Did DKIM pass?
3. Did either SPF or DKIM align with the visible From domain?
4. Is the visible From domain the same domain you configured?
5. Is the email being sent by a third-party service?
6. Does that service have domain authentication enabled?
7. Is the DKIM selector correct?
8. Is the SPF return-path aligned?
9. Is the message being forwarded?
10. Is the DMARC record valid?

A DMARC failure does not always mean your DMARC record itself is wrong. Often, the record is valid but one sender is not authenticated properly.

Common DMARC troubleshooting scenarios

My DMARC checker says no DMARC record

Likely causes:

• No TXT record at _dmarc
• Record added to root instead of _dmarc
• Record added at the wrong DNS host
• Typo in the host/name field
• DNS propagation delay

Fix: Add a TXT record at _dmarc with a basic valid policy.

My DMARC record exists but is invalid

Likely causes:

• Missing v=DMARC1
• Missing p= tag
• Invalid policy value
• Multiple DMARC records
• Formatting error
• Incorrect quotation marks or copied hidden characters

Fix: Start with a clean simple record:

v=DMARC1; p=none;

DMARC passes for Gmail but fails for my newsletter tool

Likely cause:

Your main email provider is authenticated, but the newsletter tool is not aligned.

Fix:

• Authenticate the sending domain inside the newsletter platform
• Add the required DKIM records
• Configure custom return-path if required
• Retest from that platform

Should I use p=none or p=reject?

Use p=none when you are starting or unsure.

Use p=reject only after you confirm all legitimate senders pass DMARC.

For most small businesses, the practical sequence is:

p=none -> p=quarantine -> p=reject

DMARC checklist for small businesses

Use this checklist:

• DMARC record exists at _dmarc
• Record starts with v=DMARC1
• Record has one valid p= policy
• Only one DMARC record exists
• SPF exists and is not duplicated
• DKIM is enabled for your main email provider
• Third-party senders are authenticated
• You start with p=none if unsure
• You move to quarantine only after testing
• You move to reject only when confident
• Reporting mailbox exists if using rua
• Important business emails are tested after changes

Final recommendation

Every business domain should have DMARC.

If you are just starting, publish a simple monitoring policy:

v=DMARC1; p=none;

Then check SPF, DKIM, and third-party senders before moving to a stricter policy.

Do not jump straight to p=reject unless you know all legitimate email sources are authenticated and aligned.

A good DMARC setup is not just a DNS record. It is a rollout process.

Run a DMARC check

Use Domain Email Doctor to check whether your domain has a valid DMARC record, whether it is published in the right place, and whether your email DNS setup is ready for a stricter policy.

Start by checking the record before changing DNS, so you know whether the problem is missing DMARC, invalid syntax, duplicate records, or incomplete SPF/DKIM setup.