What Is DMARC and How to Set It Up

DMARC (Domain-based Message Authentication, Reporting, and Conformance) is the policy layer on top of SPF and DKIM. Where SPF verifies which servers can send email from your domain and DKIM verifies that the message was not tampered with, DMARC answers two questions that neither SPF nor DKIM address on their own: what should the receiving server do when authentication fails, and how can the domain owner find out about it?

Without DMARC, a receiving server that sees an SPF or DKIM failure has no policy guidance. It might reject the email, send it to spam, or accept it anyway. Each receiving server makes its own decision. DMARC lets you, the domain owner, publish an explicit policy: reject unauthenticated emails, quarantine them, or just monitor and report. It also introduces alignment — the requirement that the domain in the visible “From” header matches the domain verified by SPF or DKIM.

How DMARC works#

When a receiving server gets an email claiming to be from your domain, the DMARC check follows this sequence:

1. The receiving server performs the SPF check (is the sending IP authorized?)
2. The receiving server performs the DKIM check (is the signature valid?)
3. The receiving server looks up the DMARC record at  _dmarc.yourdomain.com
4. DMARC checks alignment: does the domain in the visible “From” header match the domain that passed SPF or DKIM?
5. If either SPF or DKIM passes and is aligned with the “From” domain, DMARC passes
6. If DMARC fails, the receiving server follows the policy in your DMARC record (none, quarantine, or reject)
7. The receiving server sends aggregate reports to the address specified in your DMARC record

Why alignment matters

SPF and DKIM each verify a domain, but not necessarily the domain the recipient sees. SPF checks the envelope sender (the return-path), which is invisible to the recipient. DKIM checks the d= domain in the signature, which can be different from the “From” address.

An attacker could send an email with:

• Envelope sender: attacker@evil.com (passes SPF for evil.com)
• DKIM signature: d=evil.com (passes DKIM for evil.com)
• From header: ceo@yourdomain.com (what the recipient sees)

Without DMARC, both SPF and DKIM pass, but the recipient thinks the email is from your domain. DMARC catches this because it requires alignment: the domain that passed SPF or DKIM must match the “From” header domain. In this case, evil.com does not match yourdomain.com, so DMARC fails.

DMARC record syntax#

A DMARC record is a DNS TXT record published at _dmarc.yourdomain.com . A basic record:

v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com

Required tags

Optional tags

Policy levels

The p= tag is the core of DMARC. It has three values:

p=none (monitor only)

v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com

No action is taken on failing emails. They are delivered normally. But aggregate reports are sent to the rua address, telling you which emails passed and failed authentication.

Use this when: you are setting up DMARC for the first time. It lets you see what is happening without breaking anything. You might discover legitimate email sources that are not covered by your SPF record or not signing with DKIM.

p=quarantine

v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@yourdomain.com

Emails that fail DMARC are sent to the recipient’s spam/junk folder instead of the inbox. The email is still delivered, but the recipient has to actively look for it.

Use this when: you have reviewed your DMARC reports under p=none and are confident that legitimate email sources are properly configured, but want a safety net before moving to full rejection.

p=reject

v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourdomain.com

Emails that fail DMARC are rejected outright. The receiving server drops the message. The recipient never sees it.

Use this when: you are confident that your SPF and DKIM are correctly configured for every legitimate email source. This is the strongest protection against spoofing and the end goal of any DMARC deployment.

What "no DMARC record found" means#

If you run an email authentication check (using tools.hostney.com/dmarc or another checker) and see “no DMARC record found,” it means there is no TXT record at _dmarc.yourdomain.com .

This does not mean your email is broken. Email still sends and receives without DMARC. But it means:

• Receiving servers have no policy guidance when SPF or DKIM fails for your domain
• You get no reports about who is sending email as your domain
• Spammers can spoof your domain more easily because there is no alignment check
• Some email providers (Google, Yahoo) now require DMARC for bulk senders and may penalize domains without it

How to fix it

Add a DMARC record. Start with monitoring mode:

Host: _dmarc
Type: TXT
Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com

This is the minimum viable DMARC record. It does not change how your email is handled (p=none means no action), but it starts collecting data about authentication results.

Setting up DMARC#

Step 1: Verify SPF and DKIM are working

Before adding DMARC, make sure SPF and DKIM are properly configured. DMARC builds on top of both. If your SPF record is missing or your DKIM signatures are not valid, DMARC will report failures for every email.

Check both at tools.hostney.com/dmarc.

Step 2: Add a DMARC record with p=none

Add a TXT record to your DNS:

Host: _dmarc
Type: TXT
Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com

The rua address receives aggregate reports. Use an email address you actively monitor. Some organizations use a dedicated address or a third-party DMARC reporting service that parses the XML reports into readable dashboards.

Step 3: Wait and review reports

Leave p=none in place for at least 2-4 weeks. During this time, aggregate reports arrive daily (most large email providers send them once per day). The reports are XML files that show:

• Which IPs sent email claiming to be from your domain
• Whether SPF passed or failed for each IP
• Whether DKIM passed or failed
• Whether DMARC alignment passed or failed
• The volume of email from each source

Review these reports to identify:

• Legitimate senders you missed. A third-party service sending email as your domain that is not in your SPF record. A system that is not signing with DKIM.
• Unauthorized senders. IPs you do not recognize sending email as your domain. This is spoofing, and it is exactly what DMARC is designed to stop.

Step 4: Fix any gaps

If the reports show legitimate sources failing, update your SPF record to include them and ensure DKIM is configured for each provider.

Step 5: Move to p=quarantine

Once reports show that all legitimate email passes DMARC:

v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@yourdomain.com

You can use the pct tag to apply the policy gradually:

v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc-reports@yourdomain.com

This applies quarantine to 25% of failing emails. The rest are treated as if the policy were p=none. Increase the percentage over time (25, 50, 75, 100) while monitoring reports for any legitimate email that gets caught.

Step 6: Move to p=reject

After running at p=quarantine with pct=100 and seeing no legitimate email failures:

v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourdomain.com

This is the end state. Unauthorized emails are rejected. Your domain is fully protected against spoofing.

Setting up DMARC on GoDaddy#

1. Log in to your GoDaddy account
2. Go to My Products and find your domain
3. Click DNS (or Manage DNS)
4. Click Add Record
5. Select TXT as the record type
6. Set Name to  _dmarc
7. Set Value to your DMARC record (e.g.,  v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com )
8. Set TTL to 1 hour
9. Save

On Namecheap

1. Go to Domain List > Manage > Advanced DNS
2. Click Add New Record
3. Select TXT Record
4. Set Host to  _dmarc
5. Set Value to your DMARC record
6. Set TTL to Automatic
7. Save

On Hostney

Go to Hosting > DNS Zone Editor in the control panel, add a TXT record with the host _dmarc and your DMARC policy as the value.

Reading DMARC aggregate reports#

Aggregate reports arrive as XML files, usually inside a compressed archive. They are not designed to be human-readable, but the structure is straightforward once you know what to look for.

A simplified example:

<feedback>
  <report_metadata>
    <org_name>google.com</org_name>
    <date_range>
      <begin>1710892800</begin>
      <end>1710979200</end>
    </date_range>
  </report_metadata>
  <policy_published>
    <domain>yourdomain.com</domain>
    <p>none</p>
  </policy_published>
  <record>
    <row>
      <source_ip>203.0.113.50</source_ip>
      <count>142</count>
      <policy_evaluated>
        <disposition>none</disposition>
        <dkim>pass</dkim>
        <spf>pass</spf>
      </policy_evaluated>
    </row>
    <row>
      <source_ip>198.51.100.20</source_ip>
      <count>3</count>
      <policy_evaluated>
        <disposition>none</disposition>
        <dkim>fail</dkim>
        <spf>fail</spf>
      </policy_evaluated>
    </row>
  </record>
</feedback>

What to look for:

• source_ip: the IP that sent email claiming to be from your domain
• count: how many emails from that IP during the reporting period
• dkim: pass or fail
• spf: pass or fail
• disposition: what the receiving server did (none, quarantine, reject)

The first row shows 142 emails from 203.0.113.50 where both DKIM and SPF passed. This is likely your legitimate mail server.

The second row shows 3 emails from 198.51.100.20 where both failed. This is either a misconfigured legitimate source or a spoofing attempt. Look up the IP to determine which.

DMARC reporting services

Parsing XML reports manually works for small volumes, but quickly becomes impractical. Third-party services parse the reports and present them as dashboards:

• Postmark DMARC (free for basic monitoring)
• DMARC Analyzer
• Valimail
• dmarcian

These services provide a dedicated reporting email address that you use in your rua tag. They aggregate reports from all receiving servers and show you trends, unauthorized senders, and configuration issues in a web interface.

Advanced DMARC configuration#

Subdomain policy (sp=)

By default, subdomains inherit the parent domain’s DMARC policy. If your domain has p=reject , emails from marketing.yourdomain.com are also subject to reject unless that subdomain has its own DMARC record.

To set a different policy for subdomains:

v=DMARC1; p=reject; sp=quarantine; rua=mailto:dmarc@yourdomain.com

This rejects spoofed email from the main domain but only quarantines spoofed email from subdomains. Useful when you have subdomains with less mature email authentication setups.

To prevent email from subdomains you do not use:

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

Combined with v=spf1 -all SPF records on those subdomains, this shuts down subdomain spoofing.

Alignment modes (adkim, aspf)

Alignment can be relaxed or strict:

Relaxed (default): the authenticated domain can be a subdomain of the “From” domain. An email from user@yourdomain.com with DKIM signature d=mail.yourdomain.com passes alignment because mail.yourdomain.com is a subdomain of yourdomain.com .

Strict: the authenticated domain must exactly match the “From” domain. d=mail.yourdomain.com does not align with From: user@yourdomain.com .

v=DMARC1; p=reject; adkim=s; aspf=s; rua=mailto:dmarc@yourdomain.com

Relaxed alignment is the default and is correct for most domains. Strict alignment is useful when you want to prevent subdomains from being used to send email that appears to come from the parent domain.

Percentage (pct=)

The pct tag applies the policy to a percentage of failing messages:

v=DMARC1; p=reject; pct=10; rua=mailto:dmarc@yourdomain.com

This rejects only 10% of messages that fail DMARC. The remaining 90% are treated as if the policy were p=none. This is a safety valve for gradual rollout. Increase the percentage over time as you gain confidence.

When pct is absent, it defaults to 100.

Forensic reports (ruf, fo)

Forensic reports provide per-message details about failures, unlike aggregate reports which are daily summaries. They include message headers and sometimes partial body content.

v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.com; ruf=mailto:forensics@yourdomain.com; fo=1

The fo tag controls when forensic reports are sent:

In practice, many large email providers (including Google and Microsoft) do not send forensic reports due to privacy concerns. Do not rely on them as your primary data source. Aggregate reports are more reliable and universally supported.

Common DMARC mistakes#

Setting p=reject on day one

Starting with p=reject before reviewing reports is the most common mistake. You discover the hard way that a legitimate email source was not in your SPF record or was not signing with DKIM. Those emails are now being rejected. Customers do not receive order confirmations. Partners do not receive invoices.

Always start with p=none, review reports, fix gaps, then escalate to quarantine, then reject.

Forgetting the rua tag

A DMARC record without rua is valid but nearly useless:

v=DMARC1; p=none

Without reports, you have no visibility into what is passing and failing. You are flying blind. Always include rua with a monitored email address.

Not acting on reports

Adding a DMARC record with p=none and then never reading the reports defeats the purpose. The reports exist to guide you toward a stricter policy. If you set p=none and leave it there permanently, you get zero protection against spoofing. p=none is the starting point, not the destination.

Misunderstanding what DMARC protects

DMARC protects your domain from being spoofed in emails sent to others. It does not protect you from receiving spam or phishing. If you receive a phishing email, that is the sender’s domain that lacks DMARC (or the attacker is using a different technique). DMARC protects your reputation by preventing others from impersonating your domain.

Multiple DMARC records

Like SPF, a domain should have exactly one DMARC record at _dmarc.yourdomain.com . Multiple records cause unpredictable behavior. Some receiving servers pick the first record, others fail the check entirely.

The full email authentication stack#

Setting up all three records gives receiving servers a complete picture:

1. SPF – add a TXT record on your domain root listing authorized sending servers
2. DKIM – add TXT/CNAME records for each email provider’s DKIM keys
3. DMARC – add a TXT record at  _dmarc  with your policy and reporting address

When all three are in place, receiving servers can confidently determine whether an email genuinely came from your domain. This directly improves deliverability: email that passes SPF, DKIM, and DMARC is far less likely to be flagged as spam.

Verify your complete setup at tools.hostney.com/dmarc. The tool checks all three records and reports any issues.