How To Configure DMARC For Marketing Email

DMARC is now a basic part of responsible marketing-email operations. It helps mailbox providers confirm that a message using your visible From: domain is genuinely authorised by that domain, and gives you a way to see who else is using it.

For permission-based marketing and lifecycle programmes, the practical objective is straightforward: every legitimate platform that sends as your brand should pass DMARC consistently, while unauthorised use of the domain becomes visible and, eventually, subject to a quarantine or reject policy.

This matters beyond anti-spoofing. Gmail requires bulk senders to use SPF, DKIM and DMARC, and requires the visible From: domain to align with either the SPF or DKIM domain. Yahoo has a comparable alignment requirement for bulk senders. Authentication alone will not create inbox placement, but a message that cannot establish a trustworthy sending identity starts at a serious disadvantage. Google’s sender guidelines and Yahoo’s sender requirements are clear on the direction of travel.

What DMARC checks

DMARC stands for Domain-based Message Authentication, Reporting and Conformance. It uses the results of two older email-authentication systems:

• SPF checks whether the server that sent the message is authorised to send for the domain used in the SMTP envelope sender, often visible later as Return-Path.
• DKIM uses a cryptographic signature to show that signed parts of a message have not changed in transit and that the signing domain authorised the signature.

DMARC adds alignment. In plain terms, a passing SPF or DKIM result must be meaningfully connected to the domain a subscriber sees in the From: header.

Suppose your campaign arrives as:

From: Acme Store <offers@news.acme.co.uk>
Return-Path: bounce@mailer.vendor.example
DKIM-Signature: d=vendor.example; s=campaign

SPF might pass for mailer.vendor.example, and DKIM might pass for vendor.example, but neither domain aligns with news.acme.co.uk. The message can therefore fail DMARC.

A better configuration is for the email service provider to sign with a domain you control, such as d=news.acme.co.uk, and preferably to use an aligned custom bounce domain as well. With default relaxed alignment, related subdomains can align through their shared organisational domain. Strict alignment requires an exact domain match and is usually best considered only after a stable, well-understood deployment.

DMARC passes when at least one of SPF or DKIM both passes and aligns. For marketing email, arrange both mechanisms correctly nonetheless. DKIM is often the more resilient aligned mechanism because forwarding and intermediary handling can break SPF. Google currently requires bulk senders to authenticate with both SPF and DKIM, even though alignment of one is sufficient for its DMARC-alignment requirement. Google’s sender-guidelines FAQ also recommends fully aligning both.

Start with an inventory, not a DNS record

The most common DMARC mistake is publishing a record before identifying every system that uses the domain. The result is usually a confusing report feed, followed by a decision to leave the policy at monitoring forever.

Create an inventory of every legitimate sender and record the following for each one:

• the visible From: domain and subdomain;
• the purpose of the mail: promotional, lifecycle, transactional, support, internal or service-generated;
• the platform or relay that sends it;
• the DKIM signing domain and selector;
• the envelope-from or custom bounce domain;
• the owners of the platform and DNS configuration; and
• whether a live message has been checked for SPF, DKIM and DMARC results.

Do not limit the exercise to the main marketing platform. Common omissions include customer-service platforms, event-registration tools, survey systems, review-request services, form tools, invoice software, recruitment systems, CRM workflow mail, cloud applications and a company’s own Microsoft 365 or Google Workspace mail.

Separate marketing from operational mail where it makes sense. A subdomain such as news.example.co.uk or email.example.co.uk can give promotional mail a stable identity without pretending that it is independent of the parent brand. It also reduces the chance that a marketing-platform change disrupts corporate email. This is an operational design decision, not a cure for weak consent, excessive frequency or a disengaged audience.

Configure SPF and DKIM before relying on DMARC

Keep one SPF record per domain

SPF is published in DNS as a TXT record. A domain must have one effective SPF record, so do not add a second record each time another supplier needs authorisation. Consolidate the authorised mechanisms into a single record, following each provider’s documentation.

Be cautious with broad authorisations and with long chains of include statements. SPF has a lookup limit, and a record that exceeds it can return a permanent error rather than a pass. More importantly, SPF should only authorise services that genuinely send mail for that envelope domain.

For an email service provider, use its custom return-path or custom bounce-domain feature if available. This may allow SPF alignment as well as giving bounces a branded, controlled identity. It is useful, but it should not be the only route to DMARC pass.

Enable branded DKIM signing

Ask each sending platform to DKIM-sign with a domain under your control, such as mail.example.co.uk or news.example.co.uk. Usually the provider will supply one or more DNS CNAME or TXT records for a selector. Publish them precisely, activate the configuration in the platform and send a live test.

Use 2048-bit DKIM keys where the platform and DNS provider support them. Google accepts keys of at least 1024 bits for mail sent to personal Gmail accounts and recommends 2048-bit keys where possible. Its sender guidance also stresses verifying that a third-party provider authenticates your domain with SPF and DKIM.

Check the delivered message headers rather than assuming that a DNS record is enough. You want to see:

spf=pass
 dkim=pass header.d=news.example.co.uk
dmarc=pass header.from=news.example.co.uk

The exact presentation varies by mailbox provider, but the principle does not. A passing platform-level signature such as d=provider-mail.example may help the provider identify its own infrastructure, yet it does not by itself prove alignment with your brand domain.

Publish a monitoring DMARC record

Once legitimate traffic is authenticated, publish a DMARC TXT record at _dmarc beneath the domain being protected. For example.co.uk, the DNS host name is:

_dmarc.example.co.uk

A sensible starting record is:

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.co.uk

In a DNS control panel, enter the host/name and TXT value in the format that panel expects. Some panels append the domain automatically, so entering the full host name can accidentally create _dmarc.example.co.uk.example.co.uk. Check the published DNS result after saving.

The tags mean:

Tag	Purpose
v=DMARC1	Declares the DMARC protocol version.
p=none	Monitoring mode. It requests reports without asking receivers to apply a DMARC enforcement action because of this policy.
rua=mailto:...	Requests aggregate reports, which summarise how receivers evaluated mail using the domain.

Aggregate reports are typically compressed XML files sent by participating receivers. They are useful but awkward to interpret manually at volume, so use a mailbox and reporting process that can securely receive, parse and retain them. The current DMARC standard specifically recommends starting with p=none and analysing aggregate reports to uncover forgotten senders or unaligned legitimate traffic. RFC 9989, the current DMARC standard, replaced the earlier RFC 7489 in May 2026.

Avoid adding optional tags merely because an online generator includes them. In particular, the former pct sampling tag is historic in RFC 9989: it was removed because implementation was inconsistent. A staged deployment is better managed through a deliberate scope and evidence-based policy change than an assumed percentage of enforcement.

Read reports as an authorisation audit

For each meaningful report row, establish four things: the source IP or sending service, the visible From: domain, the SPF and DKIM results, and whether the traffic is expected.

Classify the outcome before changing policy:

• Expected and passing: record the system in the sender inventory. Confirm that its volumes and domain usage make sense.
• Expected but failing: correct the provider configuration. Typical causes are an absent branded DKIM domain, an unaligned return-path, a new platform that was never added to DNS, or a changed sending domain.
• Unknown and failing: investigate. It may be harmless internet noise, a forwarding pattern, an old vendor integration, or attempted impersonation.
• Unknown and passing: investigate promptly. A passing stream using your domain suggests an authorised configuration you have not documented, a delegated service or, in a worse case, unauthorised access to DNS or sending infrastructure.

Reports are a source of evidence, not a complete catalogue of all mail on the internet. Different receivers report at different levels of detail and frequency. Combine them with real-message header tests, platform sending logs and DNS change records.

It is also wise to test representative live mail after every major template, platform or domain change. Verify the message at Gmail, Yahoo and Microsoft consumer inboxes where those providers matter to your audience; check the full authentication results, not just whether a test message arrived.

Move from monitoring to enforcement

p=none is useful for discovery, but it does not ask receivers to block or quarantine unauthenticated impersonation. Once the reports show that authorised mail is consistently passing and there is a repeatable process for approving new senders, move towards enforcement.

The two enforcement policies are:

• p=quarantine: asks receivers to treat DMARC-failing mail suspiciously, commonly by putting it in spam or junk.
• p=reject: asks receivers to reject DMARC-failing mail during delivery.

Neither policy overrides a mailbox provider’s own judgement; receivers still apply their own filtering and handling. DMARC is an authentication and domain-protection control, not a guarantee of inbox placement. Gmail explicitly notes that DMARC failure is one among several factors in delivery decisions. Its FAQ on sender requirements explains that messages can be rejected or routed to spam when requirements are not met.

For a straightforward marketing domain with a complete inventory and stable provider configuration, the journey may be relatively short: monitor, resolve every legitimate failure, then move to quarantine and ultimately reject. For a large organisation with many legacy systems, regional teams and suppliers, it can take longer. The important point is that enforcement should follow evidence rather than a calendar deadline.

Before changing the record, review active projects and scheduled migrations. A new ESP, a new customer-data platform or a change to the visible From: domain can create a legitimate failing stream overnight. Make DMARC review part of supplier onboarding and change management, with clear ownership across marketing, IT, security and any external email provider.

Subdomains, third parties and reply handling

A parent-domain DMARC record normally influences subdomains unless a subdomain publishes its own record. That is helpful, but it can also conceal differences between mail streams. If news.example.co.uk is a long-term promotional identity with separate suppliers and owners, give it its own DMARC record and report destination. This makes its policy and reporting explicit.

Use the sp tag only when you have a clear reason to set a different policy for subdomains. It is not required for a basic deployment, and a broad subdomain policy can expose overlooked systems.

Be careful when a third-party DMARC-reporting service receives reports for you. The current standard includes an authorisation mechanism for external report destinations. Established reporting providers usually provide the associated DNS instruction; follow it rather than simply pointing rua at an unrelated domain.

Finally, keep the visible sender identity coherent. Marketing messages should use a valid, recognisable From: address and a reply path that can be handled, even where operationally replies are routed to customer care. Yahoo asks senders to use a valid, relevant reply-to address, and Microsoft’s high-volume sender guidance similarly emphasises valid sender and reply identities. Yahoo’s sender best practices are a useful reference.

DMARC is necessary, but it is not the whole deliverability programme

Correct DMARC configuration establishes identity and limits direct-domain impersonation. It does not repair a poor audience, a high complaint rate, stale data, misleading creative or uncontrolled contact pressure. Promotional email still needs consent, an easy unsubscribe route, sensible frequency and suppression of people who no longer want the mail.

For larger programmes, DMARC work is best connected to normal deliverability monitoring: authentication checks, real-message testing, Google Postmaster data where available, bounce and complaint handling, and a disciplined process for bringing new senders online. If an organisation is recovering from a deliverability problem, an independent inventory of sending infrastructure and authentication is often the correct first step before increasing volume or changing campaign tactics. That is the kind of infrastructure and authentication review Email Foundry can support for permission-based senders.

A well-run DMARC deployment is therefore not a one-off DNS task. It is a maintained record of who is allowed to send as your brand, technical evidence that they can do so safely, and a policy that protects the domain when they cannot.

Frequently asked questions

Do marketing emails need DMARC if they already pass SPF and DKIM?

Yes. SPF and DKIM alone do not require the authenticated domain to match the visible From: domain. DMARC adds that alignment check and provides reporting and a published policy for messages that fail it. Gmail, Yahoo and Microsoft have made this increasingly important for higher-volume senders.

Should I start DMARC with p=reject?

Usually no. Start with p=none and aggregate reporting, identify every legitimate sender and resolve alignment failures first. Moving immediately to reject can disrupt valid mail sent by an overlooked platform, relay or business unit.

Does p=none mean DMARC is working?

It means receivers can evaluate DMARC and send reports, but it does not request DMARC-based quarantine or rejection. It is monitoring mode, not full protection against spoofing.

Is DKIM alignment enough for marketing email?

A passing, aligned DKIM signature can make DMARC pass even if SPF is not aligned. In practice, configure and monitor both. DKIM is often more robust for alignment, while SPF remains required by major mailbox-provider sender rules for bulk traffic.

Will DMARC put marketing emails in the inbox?

No. DMARC validates identity and protects the domain from unauthorised use. Inbox placement also depends on consent, engagement, complaints, list quality, sending patterns, content and the recipient provider’s filtering decisions.

Sources and further reading

• Email sender guidelines — Google
• Email sender guidelines FAQ — Google
• Sender best practices — Yahoo Sender Hub
• RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance (DMARC) — Internet Engineering Task Force
• Strengthening email ecosystem: Outlook’s new requirements for high-volume senders — Microsoft