DNS record reference

21 June 2026 · 12 min read

This page is the master reference for every DNS record that DMARC Engine publishes on your behalf or checks for you. For each record you will find the exact hostname, an example value, what the record does, and how it is delegated from your domain to the hosted platform.

DMARC Engine uses a delegation model wherever possible. Instead of asking you to paste long, fragile policy strings into your DNS provider and then return every time something changes, you publish a single, short CNAME record once. That CNAME points a well-known hostname at a hosted target managed by the platform. From then on, the actual record content (the DMARC policy, the SPF mechanisms, the MTA-STS policy ID and so on) is served and updated for you. You edit policies inside the dashboard at app.dmarcengine.com and changes take effect without further DNS edits.

A small number of records cannot be delegated by CNAME and must be published as TXT records directly. Those are called out explicitly below.

If you would rather inspect any of these records on a domain right now, without signing in, the free tools mirror exactly what the platform checks: the DMARC checker, SPF checker, DKIM checker, BIMI checker and MTA-STS checker.

How delegation works

Every hosted record type follows the same pattern.

1. You configure the policy in the dashboard. The platform generates the record content and a delegation target.
2. You publish a short CNAME at your DNS provider, pointing the well-known hostname for that record type at the hosted target.
3. The platform answers DNS queries for that hostname and keeps the content current.

A CNAME line in the dashboard always reads in the form source hostname -> hosted target. The source hostname is what you create at your provider; the hosted target is the value you set it to. For example, a DMARC delegation looks like _dmarc.example.com -> _dmarc.example.com.hosted.dmarcengine.com.

A few important rules apply to CNAME delegation:

• A hostname that carries a CNAME cannot carry any other record. That is fine for the underscore-prefixed hostnames used here (_dmarc, _mta-sts, _smtp._tls, <selector>._domainkey, default._bimi), because nothing else lives there.
• You must publish the CNAME at the exact hostname shown. The most common mistake is adding or omitting the apex domain that some providers append automatically. Copy the Name/Host value exactly.
• SPF and TLS-RPT content is published as TXT, not CNAME, because the apex and the _smtp._tls hostname may need to coexist with other records.

The new-domain wizard and the per-record Configure screens include a guided setup panel that detects your DNS provider, deep-links to the right page, and verifies the record once published. See DNS setup and domain verification for that flow.

DMARC TXT record

DMARC tells receiving mail servers what to do with messages that fail authentication, and where to send reports. Configure it under Hosted DMARC at /dmarc.

• Hostname: _dmarc.example.com
• Published as: TXT (served by the platform), delegated via CNAME
• Delegation: _dmarc.example.com -> _dmarc.example.com.hosted.dmarcengine.com

Example record value:

v=DMARC1; p=reject; sp=reject; adkim=s; aspf=s; pct=100; rua=mailto:rua@reports.dmarcengine.com; fo=1; ri=86400

Configuring it in the dashboard

Open /dmarc and use the tabs across the top.

• Manage Records lists each domain as a card with a policy badge showing p=reject, p=quarantine, p=none or Not configured. The card shows the CNAME delegation line, a Configure button, and a red Withdraw button that removes hosted delegation for that domain.
• Record Builder is the form that produces the record. Fill in the fields below, then publish the delegation.
• Aggregate Reports and Source Analysis read the RUA data once reports start arriving. They are covered in Reading DMARC aggregate reports.

The Record Builder fields map directly onto DMARC tags:

• Domain: the domain the policy protects.
• Policy (p): none, quarantine or reject. This is the instruction for the organisational domain. Start at none, then tighten.
• Subdomain Policy (sp): inherit, none, quarantine or reject. Choose inherit to apply the same policy to subdomains, or set a different one.
• DKIM Alignment (adkim) and SPF Alignment (aspf): Relaxed or Strict. Relaxed allows the authenticated domain to be a subdomain of the From domain; Strict requires an exact match.
• Percentage (pct): 0 to 100. The proportion of failing mail the policy applies to, useful for a phased rollout.
• Aggregate Report Email (rua): the address that receives daily aggregate (RUA) reports. This is prefilled with the hosted reporting address so analytics populate automatically; leave it in place.
• Forensic Report Email (ruf): the optional address for per-message failure (RUF) reports.
• Failure Reporting (fo): controls when failure reports are generated.
• Report Interval (ri): the requested seconds between aggregate reports; 86400 is one day.

The form produces a Generated DMARC Record box with Copy Record and Publish via CNAME buttons, DNS Setup Instructions, and a Policy Progression guide that walks you from none to quarantine to reject. Click Publish via CNAME and follow the delegation line to go live.

To audit a published DMARC record at any time, use the free DMARC checker, or build a record without an account with the DMARC record generator.

SPF TXT record

SPF lists the servers permitted to send mail for your domain. Configure it under Hosted SPF at /spf.

• Hostname: example.com (the apex, or the relevant subdomain)
• Published as: TXT
• Delegation: SPF is delegated by publishing a TXT record that the platform keeps optimised; the Manage Records card shows the exact TXT instruction.

Example record value:

v=spf1 include:_spf.dmarcengine.com -all

Configuring it in the dashboard

Open /spf. The tabs are Manage Records, Record Builder, SPF Flattening and Vendor Management.

• Manage Records shows a per-domain card with an SPF hosted badge, Configure and Withdraw buttons, and the TXT instruction to publish.
• Record Builder has a Domain dropdown and an SPF Mechanisms list. Each row has a Type (include, ip4, ip6, a or mx), a Value field, and a per-row delete control; Add appends a row. The Default Qualifier sets the catch-all: ~all (SoftFail, recommended while testing), -all (HardFail, the strict end state), +all (Pass, never use this) or ?all (Neutral).

The output is a Generated SPF Record with Copy and Save Record buttons, plus a DNS Setup optimised include. Crucially, the builder shows an X/10 DNS lookups indicator with a coloured progress bar: green at 7 or fewer, amber up to 10, red above 10. SPF allows a maximum of 10 DNS-resolving mechanisms; exceed it and SPF returns permerror and effectively fails. Keep this indicator out of the red.

SPF Flattening

If you are close to or over the 10-lookup limit, open the SPF Flattening tab, enter a Domain and click Analyse. The results show:

• the total DNS lookups against the limit of 10;
• the Raw SPF Record as currently published;
• an Include Tree showing nested includes with each one's lookup count and any error badges;
• Flattened IP Addresses, the resolved ip4/ip6 ranges, with a Copy button.

Flattening replaces include mechanisms with their underlying IP ranges, cutting lookups. The trade-off is that flattened IPs do not update automatically if a sender changes infrastructure, so re-analyse periodically.

Vendor Management

The Vendor Management tab has an Add Vendor modal with a Vendor Preset dropdown (for example Google Workspace, Microsoft 365, SendGrid) and an Include Domain field. This is a local helper to assemble the right includes; it is not saved to your account.

Verify any SPF record with the free SPF checker.

DKIM CNAME or TXT record

DKIM signs your outbound mail so receivers can verify it was not altered. Each signing key lives under a named selector. Configure keys under DKIM keys at /dkim.

• Hostname: selector._domainkey.example.com
• Published as: CNAME (delegated) or TXT (the public key directly)
• Delegation: the Selectors tab shows the CNAME instruction for each selector.

Example hostname and value:

google._domainkey.example.com  IN  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhki..."

Configuring it in the dashboard

Open /dkim. The tabs are Selectors, Generate Keys and Health.

• Selectors lists each domain as a card under _domainkey.example.com with a Generate Keys button. Each selector shows its name, a key type and size badge, a status badge, its age in days, the CNAME instruction, and a Revoke button.
• Generate Keys is the creation form. Fill in Domain and Selector, choose a Key Type of RSA (widely supported) or Ed25519 (modern), and for RSA a Key Size of 2048, 1024 or 4096. There is an optional Sending Service label. Click Generate Key Pair.

The output gives you the Generated DNS Record (the DKIM TXT public key), the Record Hostname (selector._domainkey.example.com), a Copy Public Key button and a View in Selectors link. The Private Key appears once, in an amber box noting it is never sent to your servers, with a Copy Private Key button. Copy and store the private key securely at the moment of generation, because it is shown only once.

Use 2048-bit RSA for the best balance of compatibility and strength. The 1024-bit option exists for legacy systems but is treated as weak.

Health

The Health tab summarises Active Keys, Weak Keys (any 1024-bit key), Revoked Keys and Avg Key Age, shows a weak-key warning where relevant, and lists every key in a Key Health Details table (Selector, Service, Strength, Age, Status and a Revoke control). Rotate keys periodically and revoke any that are weak or unused.

Confirm a published selector with the free DKIM checker.

MTA-STS policy and TXT record

MTA-STS tells sending servers to require TLS when delivering to your domain, closing the door on downgrade attacks. It needs two pieces: a policy file served over HTTPS, and a TXT record that signals the policy version. Configure it under Hosted MTA-STS at /mta-sts.

• Policy hostname: mta-sts.example.com (serves the policy file)
• TXT hostname: _mta-sts.example.com
• Published as: CNAME for both the policy host and the TXT host (delegated)
• Delegation: three CNAMEs are shown: policy, txt and tls-rpt.

Example _mta-sts TXT value:

v=STSv1; id=20260623000000

The id changes whenever the policy changes, which is exactly why delegation helps: the platform updates the id for you so receivers re-fetch the policy.

Configuring it in the dashboard

Open /mta-sts. The tabs are Manage Policies, Policy Builder, Policy Tester and TLS-RPT Reports.

• Manage Policies shows a per-domain card with a status badge (Active, Configured or Not configured) and a mode badge (testing or enforce), the Max Age and MX host count, Configure or Edit, a Withdraw button, and three CNAME instructions: policy, txt and tls-rpt.
• Policy Builder has a Domain field, a Policy Mode of testing or enforce, an MX Hosts list with an Add MX Host button, and a Max Age of 1 day, 1 week (recommended), 2 weeks or 30 days. Start in testing so failures are reported but mail still flows, then switch to enforce.

The output is a read-only Generated Policy File with Copy Policy and Save Policy buttons, the Published DNS Records (including TLS-RPT), and the three-line CNAME Delegation.

Policy Tester

Open Policy Tester, enter a Domain and click Run Test. It returns a verdict of PASS, WARN or FAIL, the Policy ID, Discovery Steps cards showing how the policy was resolved, the Published Policy (mode, max age and MX patterns), and an MX Coverage table marking each MX host Covered or Not covered. Any Not covered MX host means mail to that server is not protected, so add it to the policy.

You can run the same discovery without signing in via the free MTA-STS checker.

TLS-RPT TXT record

TLS-RPT requests reports about TLS connection failures to your mail servers, which is how you discover MTA-STS or certificate problems. It is published alongside MTA-STS and is delegated as the third CNAME above.

• Hostname: _smtp._tls.example.com
• Published as: TXT (served by the platform), delegated via CNAME
• Delegation: the tls-rpt CNAME line on the Manage Policies card

Example record value:

v=TLSRPTv1; rua=mailto:tlsrpt@reports.dmarcengine.com

Reading the reports

In /mta-sts, open the TLS-RPT Reports tab and pick a domain. It shows TLS Success Rate, Successful Sessions and Failed Sessions, and a Failures table listing Date, Result Type, Count, Receiving MX and Sending MTA IP. The same tab shows the TLS-RPT record with a Copy button. A rising failure count usually points to a misconfigured MX or an expiring certificate.

BIMI record (and the VMC)

BIMI displays your brand logo next to authenticated mail in supporting inboxes. It requires a DMARC policy at quarantine or reject first, an SVG logo published over HTTPS, and for the major mailbox providers a Verified Mark Certificate (VMC). Configure it under Hosted BIMI at /bimi.

• Hostname: default._bimi.example.com
• Published as: TXT (served by the platform), delegated via CNAME
• Delegation: the CNAME shown on the Manage BIMI card

Example record value:

v=BIMI1; l=https://bimi.example.com/logo.svg; a=https://bimi.example.com/vmc.pem

The l tag is the logo URL and the a tag is the VMC or CMC certificate URL.

Configuring it in the dashboard

Open /bimi. The tabs are Manage BIMI, Record Builder, SVG Validator, VMC Checker and Requirements.

• Manage BIMI shows a per-domain card with a status (Active, Pending or Not configured), the default._bimi.example.com hostname, Configure or Edit, a Withdraw button and the CNAME.
• Record Builder has a Domain field, a Selector field (default default), a Brand Logo drag-and-drop upload, a Logo URL (HTTPS) field, a VMC/CMC Certificate URL field and an Upload VMC PEM control. The output includes a Multi-Client Preview (Gmail, Apple Mail and Outlook), the Generated BIMI Record and hostname, a Save BIMI Record button, and the CNAME Delegation.

Validating the logo and certificate

• SVG Validator: paste your SVG into the textarea and click Validate. The Validation Results check items such as valid XML, version 1.2, baseProfile and a square ratio, each marked Pass or Fail, alongside an SVG Preview. BIMI requires SVG Tiny 1.2 Portable/Secure; ordinary SVG exports usually fail until tidied.
• VMC Checker: enter a VMC Certificate URL and click Check Certificate. The Certificate Details show a verdict (Valid VMC, Not a VMC, Expired or Not Yet Valid), the Issuer, Subject, Valid From and Valid To dates, Days Remaining, Serial Number, and whether the logotype extension is present.
• Requirements: pick a domain to see a checklist (DMARC policy, SPF and DKIM, SVG logo, VMC) with check or warning icons, plus the SVG Tiny 1.2 P/S requirements and a code example.

Check any published BIMI record with the free BIMI checker.

Hostnames at a glance

For quick copying, here are the well-known hostnames for example.com:

• DMARC: _dmarc.example.com
• SPF: example.com (apex TXT)
• DKIM: <selector>._domainkey.example.com
• MTA-STS policy host: mta-sts.example.com
• MTA-STS TXT: _mta-sts.example.com
• TLS-RPT: _smtp._tls.example.com
• BIMI: default._bimi.example.com

A sensible order to publish in

If you are starting from scratch, publish in this order so each layer supports the next:

1. SPF and DKIM first, so your legitimate mail authenticates.
2. DMARC at p=none to begin collecting reports without affecting delivery. Watch the Aggregate Reports tab until your alignment is healthy.
3. Tighten DMARC to quarantine, then reject, using the Policy Progression guide and the Percentage (pct) field to phase it in.
4. MTA-STS in testing mode, then enforce once the Policy Tester shows full MX Coverage.
5. BIMI last, once DMARC is at quarantine or reject and your SVG and VMC validate.

For the underlying standards and inbox-provider rules, see Email authentication requirements and the glossary. If a term here is unfamiliar, every tag and acronym is defined there.