Understanding your DMARC record

12 May 2026 · DMARC Engine · 14 min read

Your DMARC record is a single line of DNS text that tells the world's mailbox providers two things: how to treat email that claims to come from your domain but fails authentication, and where to send the reports that prove it. In DMARC Engine, you never have to hand-craft that line. The Record Builder turns a short form into a valid, standards-compliant record, and the hosted CNAME model means you publish it once and edit it forever from the dashboard.

This guide walks through every field in the Record Builder, explains exactly what each one generates, and shows you how to publish the result through a single CNAME so that DMARC Engine manages the live record on your behalf.

Where the Record Builder lives

In the dashboard at app.dmarcengine.com, open the hosted DMARC area at /dmarc. You will see four tabs across the top:

Manage Records: an overview of every domain you have onboarded, each shown as a card with its current policy badge and its CNAME delegation line.
Record Builder: the form covered in this guide, where you define the policy and reporting behaviour and generate the record.
Aggregate Reports: the parsed RUA data, with pass and fail statistics, sending sources and charts.
Source Analysis: a focused view of which services send mail under your domain.

Start in Manage Records to find the domain you want to work on, then move to Record Builder to configure it. If a domain has never been set up, its card shows the policy badge Not configured; once a record is live, the badge reads none, quarantine or reject to match your published policy.

What a DMARC record actually is

A DMARC record is a TXT record published at the hostname _dmarc.yourdomain.com. Its value is a semicolon-separated list of tag and value pairs. A typical record generated by the builder looks like this:

v=DMARC1; p=none; sp=none; adkim=r; aspf=r; pct=100; rua=mailto:rua@inbox.dmarcengine.com; fo=1; ri=86400

Every tag in that string maps to a field in the Record Builder. The v=DMARC1 version tag is always first and is added for you; it is fixed and never editable, because the specification requires it. Everything after it comes from the choices you make in the form. The rest of this guide takes the fields in the order you meet them.

If you ever want to sanity-check the record an external resolver sees, paste your domain into the free DMARC checker. For a from-scratch string outside the hosted flow, the DMARC generator produces the same kind of output.

Domain

The first field is Domain. This is the exact domain or subdomain the record protects, for example example.com or mail.example.com. The value you choose here decides where the record is published: a record for example.com lives at _dmarc.example.com, and a record for mail.example.com lives at _dmarc.mail.example.com.

Pick the organisational domain (the registrable domain, such as example.com) for your primary policy. Subdomains can either inherit that policy automatically or carry their own record; the Subdomain Policy field below controls the inheritance behaviour for the organisational domain.

Policy (p)

Policy (p) is the most important decision in the whole record. It tells receiving mail servers what to do with a message that fails DMARC, meaning the message did not produce an aligned, passing SPF or DKIM result. The dropdown offers three values:

none: take no special action. Failing mail is still delivered as normal. This is monitoring mode. You collect reports and learn which sources send on your behalf without any risk of losing legitimate mail.
quarantine: treat failing mail as suspicious. Most receivers route it to the spam or junk folder rather than the inbox.
reject: refuse failing mail outright at the SMTP layer, so it never reaches the recipient. This is the enforcement target that actually stops spoofing of your domain.

The value you select becomes the p= tag. Selecting reject generates p=reject. The policy badge on the Manage Records card mirrors this value so you can see at a glance which domains are still in monitoring and which are enforcing.

Start at none. Move to enforcement only once your reports show that every legitimate source is aligned and passing. Jumping straight to reject before your sources are clean is the single most common way to break legitimate mail.

For the staged path from monitoring to enforcement, see Policy progression below.

Subdomain Policy (sp)

Subdomain Policy (sp) sets a separate policy for subdomains of the domain in the record. It only has an effect on an organisational domain record, because that record is what receivers fall back to when a subdomain has no DMARC record of its own. The dropdown offers:

inherit: do not emit an sp= tag at all, so subdomains follow whatever you set in Policy (p). This is the safe default.
none, quarantine, reject: emit an explicit sp= tag that overrides the main policy for subdomains only.

Choosing inherit keeps the record short and means one policy governs everything. Choosing an explicit value is useful in two opposite situations. You might keep p=reject on the parent while setting sp=none so that a noisy subdomain you do not yet understand cannot bounce real mail. Or you might run p=none on the parent while setting sp=reject to lock down subdomains that should never send mail at all, which is a strong defence against attackers inventing subdomains to spoof.

When you pick an explicit value, the builder adds, for example, sp=quarantine to the generated record. When you leave it on inherit, no sp= tag appears.

DKIM Alignment (adkim)

DKIM Alignment (adkim) controls how strictly the domain in your DKIM signature must match the domain in the visible From: address. The dropdown offers Relaxed and Strict:

Relaxed generates adkim=r. The organisational domains must match. A DKIM signature using d=mail.example.com aligns with a From: address at example.com, because both share the registrable domain example.com.
Strict generates adkim=s. The domains must match exactly. A signature for mail.example.com would not align with a From: of example.com.

Relaxed is the right choice for almost everyone, because it allows the common practice of signing with a subdomain while sending from the parent. Choose Strict only when you have a specific, well-understood reason to require an exact match and you have confirmed your signing domains line up. You can confirm what an external check sees for a given selector with the DKIM checker.

SPF Alignment (aspf)

SPF Alignment (aspf) is the SPF counterpart to the field above. It controls how strictly the domain checked by SPF, which is the MAIL FROM or return-path domain, must match the From: domain. Again the choices are Relaxed and Strict:

Relaxed generates aspf=r. A return-path of bounces.example.com aligns with a From: of example.com.
Strict generates aspf=s. The return-path domain must equal the From: domain exactly.

As with DKIM, Relaxed is the sensible default and is what most senders need, particularly when an email service provider sets its own bounce domain. SPF alignment is fragile across forwarders and bulk senders, which is one reason DMARC treats a single aligned pass on either SPF or DKIM as sufficient. To inspect the SPF record those checks rely on, use the SPF checker.

Percentage (pct)

Percentage (pct) accepts a whole number from 0 to 100 and tells receivers what fraction of failing messages your chosen policy should apply to. It generates the pct= tag, for example pct=50.

The value 100 is the default and means your policy applies to all failing mail. A lower number is a deliberate slow rollout: with p=quarantine and pct=25, receivers quarantine roughly a quarter of failing messages and treat the rest as if the policy were none. This lets you ramp enforcement gradually and watch the impact in your aggregate reports before committing to the full policy.

A few practical notes. The percentage only affects quarantine and reject; it has no meaning when Policy (p) is none, because there is nothing to apply. Receivers apply the percentage probabilistically per message, so the split is approximate rather than exact. When Percentage (pct) is 100, some validators omit the tag entirely because it is the default; either form is valid.

Aggregate Report Email (rua)

Aggregate Report Email (rua) is where mailbox providers send their daily aggregate (RUA) reports: XML summaries of how much mail passed and failed DMARC, broken down by sending source. This field generates the rua=mailto: tag.

In DMARC Engine this field is prefilled with your hosted reporting address, something like mailto:rua@inbox.dmarcengine.com. Leaving the hosted address in place is what powers the Aggregate Reports and Source Analysis tabs: the platform receives the raw XML, parses it and turns it into the statistics, tables and charts described later in this guide. If you remove the hosted address, those tabs will have nothing to show.

You can add your own addresses alongside the hosted one. Multiple destinations are comma-separated inside the tag, for example rua=mailto:rua@inbox.dmarcengine.com,mailto:dmarc@example.com. Keep the hosted address present so the dashboard continues to work, and add extra recipients only if you genuinely need a second copy.

Aggregate reports are the engine of the whole process. They are how you discover every service sending mail as your domain, and they are what tell you when it is safe to tighten the policy. Never publish a record without a working rua.

Forensic Report Email (ruf)

Forensic Report Email (ruf) sets the destination for forensic, or failure, reports: per-message detail sent when an individual message fails authentication. It generates the ruf=mailto: tag.

This field is optional and is left blank by default. Forensic reports can contain redacted copies of message headers and sometimes content, so they carry privacy considerations, and in practice very few mailbox providers send them at all. Most organisations run a complete DMARC programme on aggregate reports alone. Fill in Forensic Report Email (ruf) only if you have a specific need for message-level samples and a place to store them securely. If you leave it empty, no ruf= tag is generated.

Failure Reporting (fo)

Failure Reporting (fo) fine-tunes when a forensic report should be generated. It only matters when you have supplied a Forensic Report Email (ruf) address, and it produces the fo= tag. The options follow the standard values:

fo=0: generate a report only when both SPF and DKIM fail to produce an aligned pass. This is the specification default.
fo=1: generate a report when either SPF or DKIM fails to produce an aligned pass. This is the most useful setting in practice, because it surfaces partial failures that 0 would hide.
fo=d: generate a report whenever the DKIM signature fails to verify, regardless of alignment.
fo=s: generate a report whenever SPF fails, regardless of alignment.

If you are collecting forensic data, fo=1 gives the broadest visibility. The tag has no effect without a Forensic Report Email (ruf) value, since there is nowhere for the reports to go.

Report Interval (ri)

Report Interval (ri) is your requested gap, in seconds, between aggregate reports. It generates the ri= tag, for example ri=86400, which is 86400 seconds, or 24 hours. That daily cadence is the default and the value almost everyone should keep.

This is a request, not a guarantee. Most large mailbox providers send aggregate reports once a day no matter what you ask for, so lowering Report Interval (ri) rarely produces more frequent reports in reality. Leave it at 86400 unless you have a documented reason to change it.

The Generated DMARC Record box

As you fill in the fields, the Record Builder assembles the tags live in the Generated DMARC Record box. This is the exact value that will be published at _dmarc.yourdomain.com. Read it back against the explanations above to confirm each tag reflects your intent before you go any further.

Two actions sit with this box:

Copy Record copies the generated string to your clipboard. Use this if you want to paste the record into an external DNS provider manually, or keep a copy for your change records.
Publish via CNAME is the hosted route, and it is the recommended one. It is covered in the next section.

Below the box, DNS Setup Instructions spell out the precise hostname and value to create at your DNS provider, so there is no ambiguity about what goes where.

Publishing via CNAME

The hosted model is what makes DMARC Engine different from editing raw TXT records by hand. Instead of publishing the DMARC TXT record yourself and re-editing it every time your policy changes, you publish a single CNAME once and delegate the record to the platform.

On the Manage Records card for your domain, the CNAME delegation line shows the mapping you need to create. It points your DMARC hostname at a hosted target, in the shape:

_dmarc.example.com.  CNAME  example.com._dmarc.dmarcengine.com.

To publish:

In the Record Builder, confirm the Generated DMARC Record box reads exactly as you intend.
Click Publish via CNAME.
Follow the DNS Setup Instructions at your DNS provider: create a CNAME record at the host shown (for example _dmarc.example.com) pointing to the hosted target shown on the delegation line.
Save the change at your DNS provider and allow time for propagation.

Once the CNAME resolves, mailbox providers that look up _dmarc.example.com are transparently redirected to the record DMARC Engine serves. From then on, every change you make in the Record Builder, whether tightening Policy (p) to quarantine or adjusting Percentage (pct), takes effect the moment you save, with no further DNS edits on your side. That is the core benefit: you delegate the hostname once, and the live policy is always whatever the dashboard says it is.

You can verify the published record at any time from outside the platform with the DMARC checker. The same CNAME-delegation approach underpins the other hosted records too; see /products/dmarc for the wider picture and /products/spf, /products/dkim, /products/mta-sts and /products/bimi for the related standards.

Withdrawing a record

If you ever need to stop hosting a record, the Manage Records card carries a Withdraw button, shown in red. Withdrawing removes the hosted record from the platform. Because mail authentication depends on it, treat Withdraw with care: once you withdraw, the CNAME you created will point at a target that no longer serves a policy, so plan to remove or repoint that CNAME at your DNS provider as part of the same change.

Policy progression: none -> quarantine -> reject

Beneath the output, the Record Builder lays out the Policy Progression path: none then quarantine then reject. This is the safe, evidence-led route to enforcement, and it is worth following deliberately rather than rushing.

none: publish with p=none and the hosted rua address in place. Change nothing else yet. Let reports accumulate for a couple of weeks so you capture monthly senders as well as daily ones.
Read the Aggregate Reports tab. Identify every sending source. Fix authentication for the legitimate ones: add them to SPF, set up DKIM signing, and confirm alignment. The goal is for every legitimate source to show an aligned pass.
quarantine: when legitimate mail is consistently passing, change Policy (p) to quarantine. Optionally set Percentage (pct) below 100, for example pct=25, to ramp gradually, then raise it to 100 as confidence grows.
reject: once quarantine has run cleanly with no legitimate mail being diverted, change Policy (p) to reject at pct=100. Your domain is now protected: spoofed mail is refused outright.

Each step is a one-field change in the Record Builder and takes effect immediately through the CNAME you already published. For the underlying account, message-volume and authentication prerequisites behind this path, see /requirements, and look up any unfamiliar terms in the /glossary.

Reading the reports your record produces

Publishing the record is only half the job. The reports it requests are what tell you whether it is safe to advance through the policy progression. Two tabs turn the raw RUA XML into something you can act on.

Aggregate Reports

Open the Aggregate Reports tab and choose a domain from the domain picker. At the top, four summary statistics frame the picture:

Emails Passed: the count of messages that produced an aligned, passing DMARC result.
Emails Failed: the count that failed DMARC.
DMARC Alignment %: the share of your mail that is passing, which is the single number to watch as you work towards enforcement.
Sending Sources: how many distinct sources sent mail under your domain in the period.

Below the statistics, a table lists each source by Source IP and Volume, with pass and fail badges for SPF, DKIM and DMARC. This is where you identify which services need their authentication fixed before you tighten the policy.

The same data is then visualised:

A Pass/Fail Volume bar chart shows the balance of passing and failing mail over time.
A Disposition Breakdown donut splits how receivers actually treated your mail into None/Delivered, Quarantine and Reject, so you can see your policy taking effect.
An Alignment Analysis bar compares SPF against DKIM alignment, which helps you see at a glance which mechanism is carrying your pass rate.

If you have raw report XML from elsewhere that you want to inspect outside the account, the free DMARC report analyzer reads the same format.

Source Analysis

The Source Analysis tab takes the same picker-driven approach and concentrates on who is sending. An Email Volume by Source donut shows the proportion of your traffic each service represents, and a Sending Source Breakdown table lists the sources in detail. Use this view to confirm you recognise every sender before moving Policy (p) towards reject, and to spot any unexpected source that might be a misconfiguration or an attempt at abuse.

A quick recap of the fields

To summarise the tags the Record Builder generates from each field:

Policy (p): p=none, p=quarantine or p=reject. What receivers do with failing mail.
Subdomain Policy (sp): inherit emits nothing; otherwise sp=none, sp=quarantine or sp=reject for subdomains.
DKIM Alignment (adkim): adkim=r (Relaxed) or adkim=s (Strict).
SPF Alignment (aspf): aspf=r (Relaxed) or aspf=s (Strict).
Percentage (pct): pct=0 to pct=100. The fraction of failing mail the policy applies to.
Aggregate Report Email (rua): rua=mailto:.... Keep the hosted address so the dashboard works.
Forensic Report Email (ruf): ruf=mailto:.... Optional, usually left blank.
Failure Reporting (fo): fo=0, fo=1, fo=d or fo=s. Only relevant with a ruf address.
Report Interval (ri): ri=86400 by default. Requested gap between aggregate reports.

Fill the form, confirm the Generated DMARC Record box, click Publish via CNAME, create the CNAME from the delegation line, and then let the Aggregate Reports and Source Analysis tabs guide you safely from none to reject.