How to Create a DMARC Record for Your Domain

Phishing emails that look like they came from your domain are not just annoying. They damage trust, create support headaches, and can lead to account compromise or payment fraud. If you need to add dmarc record for your domain, the process is straightforward once SPF and DKIM are already in place.

DMARC sits on top of those controls and tells receiving mail servers what to do when a message fails authentication or does not align with your domain. This guide shows you how to create a DMARC record, publish it in DNS, choose the right policy, and verify that it is working before you tighten enforcement.

You will also see where people typically go wrong, how to avoid blocking legitimate mail, and how to roll out DMARC in a way that protects users without breaking business email. For the official background, review RFC 7489 and the DMARC guidance from DMARC.org.

What Is DMARC and Why Does It Matter?

DMARC stands for Domain-based Message Authentication, Reporting, and Conformance. It is an email authentication protocol that helps mailbox providers decide whether a message claiming to come from your domain should be delivered, quarantined, or rejected. DMARC does not work alone. It evaluates the results of SPF and DKIM, then checks whether the authenticated identity aligns with the visible From address.

That alignment piece is the reason DMARC is so useful. An attacker can spoof a From address, but if the message fails SPF and DKIM alignment, a DMARC-aware receiver can act on it. In practice, that means fewer spoofed emails reaching users, better visibility into legitimate third-party senders, and stronger protection for transactional, marketing, and support mail streams.

DMARC does not stop every bad message. It gives receiving systems enough evidence to separate legitimate mail from forged mail and lets you define what should happen next.

That is why DMARC has become standard for organizations that rely on email for billing, customer communication, and identity workflows. It helps reduce domain abuse, protects brand reputation, and gives administrators reporting data they can actually use.

How DMARC uses SPF and DKIM

DMARC checks two things: whether SPF passes and aligns, or whether DKIM passes and aligns. If one of those mechanisms passes with alignment to the domain in the From header, DMARC can pass. If neither aligns, the receiver looks at the policy you published in DNS.

• SPF verifies whether the sending server is authorized for the envelope domain.
• DKIM verifies whether the message was signed and whether the signature is intact.
• Alignment confirms the authenticated domain matches the visible From domain closely enough under your policy.

For the technical standard, see RFC 7489. For domain and DNS management basics, many administrators also rely on their registrar’s help center plus DNS documentation from providers such as Microsoft Learn or Google Workspace Admin Help when those platforms send mail on behalf of a domain.

Prerequisites Before You Create a DMARC Record

Before you create a DMARC record, make sure you can actually support it. DMARC depends on two things: working authentication and clear ownership of every system that sends mail for your domain. If you skip the prep work, you may publish a record that looks valid but breaks legitimate email.

Start by confirming that you have access to your domain’s DNS console. That may be with a registrar, a hosting provider, a cloud DNS platform, or a dedicated DNS service. Then verify that SPF and DKIM are already configured and passing for the mail systems you use. DMARC is not a substitute for those records. It depends on them.

Next, identify every mailbox that should receive aggregate reports or failure reports. A reporting plan matters because DMARC visibility is one of its biggest advantages. If those reports go to an unattended inbox, you lose the benefit.

For workforce and email security context, NIST guidance and the CISA phishing resources are useful references when you are building a broader anti-spoofing program. If you are managing a Microsoft 365 environment, the DKIM and SPF setup guidance in Microsoft Learn is a practical starting point.

What to check before rollout

1. Confirm DNS access for the domain.
2. Verify SPF passes for legitimate outbound mail.
3. Verify DKIM signatures are valid.
4. List all approved senders, including third-party tools.
5. Decide who will monitor DMARC reports.
6. Choose a starting policy that will not interrupt business mail.

Understand the DMARC Record Structure

A DMARC record is published as a TXT record in DNS at the _dmarc subdomain. The record uses tag-value pairs separated by semicolons. The minimum valid record includes a version tag and a policy tag. Everything else is optional, but several optional fields are worth using from day one.

The most common starter record looks like this: v=DMARC1; p=none;. That tells receivers you are using DMARC and that you want reports without enforcement. It is the safest way to begin because it does not tell mailbox providers to block or quarantine messages while you are still learning your normal traffic patterns.

Key tags you will see in real deployments include p, rua, ruf, adkim, aspf, and sp. The policy tag controls enforcement. The reporting tags define where feedback goes. The alignment tags control how strictly domains must match. The subdomain policy tag lets you treat subdomains differently from the parent domain.

Tag	What it does
v=DMARC1	Identifies the record as DMARC version 1
p	Sets the policy for the main domain: none, quarantine, or reject
rua	Receives aggregate reports
ruf	Receives failure or forensic reports where supported
adkim / aspf	Controls strict or relaxed alignment
sp	Applies a separate policy to subdomains

For the authoritative specification, use RFC 7489. For practical implementation details, many DNS administrators also lean on registrar-specific help articles and vendor mail documentation such as Google Workspace Admin Help or Microsoft Learn.

How to Access Your DNS Management Console

To publish a DMARC record, you need to find the DNS management area for the domain. That is usually located in one of three places: your registrar account, your hosting provider’s dashboard, or a dedicated DNS service. The exact layout changes from provider to provider, but the workflow is usually the same.

Look for sections labeled DNS, Zone Editor, Manage Records, or Advanced DNS. Once there, confirm that the domain is using the correct nameservers. If the domain points somewhere else, changes made in the wrong console will have no effect.

This is the point where many administrators accidentally edit the wrong record type or the wrong host name. Take a minute to verify the active zone before making changes. If you are managing a multi-domain environment, keep notes on which provider hosts which zone.

For DNS management best practices, vendor support pages from domain registrars and authoritative documentation from mail providers are more useful than generic walkthroughs. If your organization uses Microsoft 365, review the email authentication guidance in Microsoft Learn. If you use Google Workspace, use the official admin documentation at Google Workspace Admin Help.

How to Create the DMARC TXT Record

Once you are in the DNS console, add a new record and set the record type to TXT. DMARC is published as text in DNS, not as an MX, A, or CNAME record. The host or name field should usually be _dmarc. Some providers automatically append the root domain, so you may only need to enter _dmarc rather than _dmarc.example.com.

The value field is where the real work happens. A basic monitoring record looks like this:

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

If your provider requires the full domain in the host field, use the format required by that interface. That is where many people get tripped up when they try to configure dmarc record settings for the first time. Some control panels ask for the name only, while others want the FQDN. The value syntax, however, should remain standard.

TTL settings and publishing details

TTL stands for time to live. It controls how long DNS resolvers cache the record. A common value is 3600 seconds, which is one hour, but many organizations leave the default in place. If you expect to make several changes while tuning DMARC, a shorter TTL can make testing faster.

Use the following steps as a safe baseline:

1. Choose TXT as the record type.
2. Enter _dmarc as the host or name.
3. Paste the DMARC value string carefully.
4. Add a monitored reporting address if you are ready for reports.
5. Save the record and document the exact value.

For DNS syntax details, the DMARC specification at RFC 7489 remains the source of truth. If you are using hosted mail services, consult official vendor guidance before changing a record that may affect mail flow.

How to Choose the Right DMARC Policy

The policy tag is the part most people care about, and for good reason. It tells receivers what to do when a message fails DMARC. The three core values are none, quarantine, and reject. Each one serves a different stage of deployment.

p=none is the monitoring policy. It gives you reports without changing delivery behavior. That makes it the right choice for the first phase of deployment, especially if your organization uses multiple email vendors or sends from many platforms. p=quarantine tells receivers to treat failures suspiciously, usually by sending them to spam. p=reject is the strongest option and instructs receivers to block failing messages outright.

The safest rollout path is to start with p=none, analyze your traffic, fix alignment issues, and move gradually to quarantine or reject. If you jump straight to reject without knowing every legitimate sender, you can break invoices, password resets, service notifications, and customer communications.

Best practice: Treat DMARC policy changes like firewall rule changes. Monitor first, then restrict, then enforce.

Subdomain policy matters too. If you send different mail from different business units or brands, the sp tag lets you define a separate rule for subdomains. That can be useful when the parent domain is protected but a marketing subdomain still needs time to be cleaned up.

For policy and risk context, CISA’s email security recommendations and the broader DNS and domain abuse guidance from CISA are worth reviewing. If your organization operates under stricter compliance demands, pair DMARC planning with your internal security framework and logging requirements.

How to Configure Reporting Addresses and Alignment Settings

DMARC reporting is where the protocol becomes operationally useful. The rua tag points to aggregate reports, which are XML summaries that show who sent mail, what authentication results were seen, and how receivers handled the messages. The ruf tag is used for forensic or failure reports, although support for those reports is more limited because of privacy and provider restrictions.

Use a monitored mailbox, a shared security inbox, or a ticketing workflow that someone actually watches. Do not send reports to a personal mailbox that will be ignored after a week. The volume can be large if your domain sends widely, and the reports are only useful if someone reviews them consistently.

Alignment settings control how strict DMARC should be about matching domains. With adkim=r and aspf=r, alignment is relaxed, which is usually the right choice early on. Strict alignment, represented by s, can be useful later if you want tighter control, but it can also create false failures if your mail ecosystem is complex.

If you are dealing with a more advanced sender model, check the official authentication docs for each platform you use. That may include Microsoft documentation, Google Workspace admin guidance, or AWS mail-related documentation where applicable. The point is to match your DMARC settings to your actual mail architecture, not an idealized one.

Save, Publish, and Wait for DNS Propagation

After you confirm the host, record type, and value, save the record and give DNS time to propagate. DNS updates are not instant everywhere. Some resolvers refresh quickly, while others continue serving cached data until the TTL expires. In many environments, changes show up in minutes, but it is normal to wait up to 24 hours before everything is fully consistent.

Keep a copy of the exact record you entered. That matters later when you are troubleshooting mail failures, comparing historical changes, or explaining a policy shift to your team. Even a small change in semicolons, spacing, or a reporting address can affect validation.

It is tempting to keep editing the record every few minutes, especially if you are watching for results. Resist that urge unless you find a clear typo. Every change resets the clock on caches and makes troubleshooting harder because you lose a clean baseline.

If you need to test a variation, document the prior version first. That makes it easier to compare results and identify which edit caused a problem. It also helps if multiple administrators manage the same DNS zone.

For DNS and mail authentication troubleshooting, vendor admin centers and DNS lookup tools from official sources are the cleanest references. Avoid relying on guesswork when changes are still propagating.

How to Verify That Your DMARC Record Is Working

Verification should happen in two places: DNS and live mail flow. First, confirm that the _dmarc subdomain resolves to the TXT record you intended to publish. Then check whether the syntax is valid and whether your reporting mailbox is receiving aggregate data.

You can also send test email from each major sending source and inspect the headers. A valid message should show SPF and DKIM results, and DMARC should pass if one of those mechanisms aligns with the From domain. If DMARC fails, compare the envelope domain, the DKIM signing domain, and the visible From address.

One of the most useful checks is reading the aggregate reports. They show which IPs are sending mail, whether those senders are aligned, and whether receivers are applying your policy. That is how you uncover forgotten marketing platforms, support tools, or legacy systems still sending mail from your domain.

For domain lookup and validation, use trustworthy tools and official docs where possible. The DMARC.org site provides background and implementation guidance, while RFC 7489 defines the protocol behavior. If you use a major email platform, its official admin documentation should be part of your verification process.

A DMARC record is not “done” when it is published. It is working only when the reports make sense and legitimate mail continues to pass.

What good verification looks like

• The TXT record resolves at _dmarc.yourdomain.
• The syntax contains v=DMARC1 and a valid policy tag.
• Aggregate reports arrive at the mailbox you configured.
• Legitimate messages from your approved senders pass SPF or DKIM alignment.
• No critical systems are being quarantined or rejected unexpectedly.

Common DMARC Setup Mistakes to Avoid

The most common mistake is publishing DMARC before SPF and DKIM are stable. DMARC depends on those mechanisms, so if you skip them, the record may technically exist but still fail legitimate messages. Another common error is adding the record at the wrong host name. If the record lives at the root domain instead of _dmarc, receivers will not find it.

Bad reporting addresses are another frequent problem. If rua or ruf points to an inbox that does not exist, reports may bounce or disappear. That is a missed opportunity, because the reports are the main way you learn what is really happening with your domain.

People also move too quickly to enforcement. A strict p=reject policy can be the right end state, but it is a risky first move if you have not yet cataloged all legitimate mail sources. The result is often broken notifications, failed password resets, and frustrated users.

Subdomains deserve attention too. If your main domain is protected but a subdomain is still being used by an old vendor, attackers may target that weaker spot. The sp tag helps close that gap.

For current threat context, email abuse trends and phishing data from Verizon DBIR and threat intelligence from Mandiant help explain why DMARC deployment should be treated as an ongoing control, not a one-time task.

Best Practices for Managing DMARC Long Term

DMARC works best as a maintenance process. Start in monitoring mode, study the reports, and then tighten policy only after you understand all legitimate senders. That may take days for a small environment or weeks for a large organization with many third-party platforms.

Review aggregate reports on a schedule. Weekly is a good starting point for most teams, and more frequent reviews may be needed during rollout. Look for unfamiliar IPs, mail sources that fail alignment, and subdomains that are sending when they should not be. If a new vendor starts sending on your behalf, update SPF and DKIM before the DMARC policy exposes the gap.

Whenever a business unit adds a new platform, ask one question: does it send email as our domain? If the answer is yes, include it in your authentication review. That simple check prevents a lot of future pain.

• Monitor first: Use p=none until sender inventory is complete.
• Verify changes: Recheck SPF and DKIM after every mail vendor change.
• Tighten gradually: Move to quarantine, then reject if the data supports it.
• Watch subdomains: Apply sp when subdomain behavior differs from the parent domain.
• Keep records current: Update documentation when mail services change.

For broader email security strategy, this is the kind of operational hygiene that aligns with guidance from NIST and CISA. It is also consistent with the kind of evidence-based monitoring organizations expect when they evaluate spoofing risk, phishing exposure, and secure email delivery.

How to Create a DMARC Record for Your Domain

If you need the short version, here it is: prepare SPF and DKIM, publish a TXT record at _dmarc, start with a monitoring policy, verify the results, and then move toward enforcement. That is the cleanest way to create a DMARC record without interrupting legitimate mail.

DMARC is effective because it gives you control and visibility at the same time. You are not just telling inbox providers to block bad mail. You are also learning who is sending on behalf of your domain, whether those senders are aligned correctly, and where your current exposure lives.

If you want to create a dmarc record that protects users instead of creating support tickets, treat rollout as a process, not a checkbox. Start with p=none, collect reports, fix your sending systems, and only then consider quarantine or reject. That is how you reduce spoofing without breaking the mail your business depends on.

For a practical next step, log into your DNS console, confirm your SPF and DKIM setup, and publish a baseline DMARC record today. Then review the first set of reports before making the policy stricter. That approach is safer, easier to troubleshoot, and far more effective in the long run.

CompTIA®, Microsoft®, AWS®, ISC2®, ISACA®, PMI®, and Cisco® are registered trademarks of their respective owners. CEH™ is a trademark of EC-Council®.