How to Generate a DMARC Record for My Domain

If you send emails from your business domain, you need to know how receiving mail servers determine whether those messages are legitimate. Without proper email authentication, attackers can attempt to send messages that appear to come from your domain, putting your brand and recipients at risk.

DMARC helps domain owners address this problem by allowing receiving mail servers to check whether messages claiming to come from a domain pass the required authentication and alignment checks. It also lets domain owners request reports about email activity.

Setting up DMARC starts with creating a DNS record. The record contains specific tags that define your policy, reporting preferences, and other authentication settings. A small formatting mistake or an unsuitable policy can create configuration problems, so it is important to understand what you are publishing.

A DMARC record generator simplifies this process by assembling the record based on your selected settings. You can then publish it in your domain’s DNS configuration.

What Is a DMARC Record?

DMARC stands for Domain-based Message Authentication, Reporting, and Conformance. It is an email authentication protocol that builds on SPF (Sender Policy Framework) and DKIM (DomainKeys Identified Mail).

A DMARC record is published as a DNS TXT record. It tells receiving mail servers which policy to apply when a message claiming to come from your domain fails DMARC authentication and alignment checks.

DMARC has three main policy options:

• None (p=none): Collect information about authentication results without requesting quarantine or rejection under the DMARC policy.
• Quarantine (p=quarantine): Ask receiving servers to treat messages that fail DMARC as suspicious. Depending on the receiver, these messages might be placed in spam or junk.
• Reject (p=reject): Ask receiving servers to reject messages that fail DMARC.

These policies give domain owners different levels of control over unauthenticated messages. The receiving server makes the final delivery decision, so the policy does not guarantee that every message will be handled identically by every provider.

\

Why Does Your Domain Need a DMARC Record?

A DMARC record helps protect your domain against unauthorized use and gives you visibility into how your domain is being used to send email. Here are three reasons it matters.

Reduce the Risk of Domain Spoofing

Email spoofing occurs when a message uses a forged sender address to appear to come from another person or organization. Attackers can exploit this technique in phishing campaigns that imitate trusted brands.

DMARC helps receiving servers evaluate whether messages claiming to come from your domain pass the required authentication checks. With an appropriate policy, you can ask receiving servers to quarantine or reject messages that fail DMARC.

Monitor Email Authentication

Businesses often send email through multiple services, including marketing platforms, customer support systems, billing software, and CRM tools.

If these services are not configured correctly, some legitimate messages might fail authentication or alignment. DMARC aggregate reports can help you identify sending sources and investigate authentication failures.

Support Email Deliverability

Email authentication is one part of a reliable sending setup. Correctly configured SPF, DKIM, and DMARC help receiving providers evaluate whether messages are authorized to use your domain.

However, DMARC does not guarantee inbox placement. Sender reputation, recipient engagement, list quality, message content, and receiving-server policies also affect delivery.\

What Do You Need Before Generating a DMARC Record?

Before creating your record, check a few details about your domain and sending setup.

Your domain’s DNS access: You need access to the DNS settings for the domain you want to protect. Your domain registrar, hosting provider, or DNS service usually manages this.

SPF and DKIM configuration: DMARC relies on SPF and DKIM authentication results. Identify the services that send email on your behalf and make sure their authentication is configured appropriately.

A reporting email address: Consider which mailbox or reporting system will receive your DMARC aggregate reports. These reports help you understand which sources are sending email using your domain.

An appropriate starting policy: If you are setting up DMARC for the first time, monitoring with p=none is generally a sensible starting point. Review the reports, resolve legitimate sending issues, and move toward enforcement when you understand your domain’s email traffic.

These checks help you generate a record that fits your domain rather than simply publishing a default configuration.\

How to Generate a DMARC Record for Your Domain

You do not need to assemble every tag manually. A free DMARC record generator can create the record from the settings you select. Follow these steps to prepare your record.

Step 1: Enter Your Domain Name

Start by entering the domain you want to protect. For example, if your business sends email from addresses such as hello@example.com, the domain to configure is example.com.

Use the domain that appears in the sender addresses you want DMARC to authenticate. If your organization sends from multiple domains or subdomains, review each domain’s requirements separately.

Step 2: Select Your DMARC Policy

Choose the policy that matches your current authentication setup. If you are beginning deployment, p=none lets you monitor authentication results without requesting quarantine or rejection under the DMARC policy. This gives you time to identify legitimate sending sources that need attention.

Once you have reviewed the reports and confirmed that legitimate mail is properly authenticated, you can consider moving to p=quarantine and eventually p=reject.

Do not switch to an enforcement policy without checking your sending services. Legitimate messages that fail DMARC can be affected by the receiving server’s handling of the policy.

Step 3: Configure Report Recipients

DMARC supports reporting options that help domain owners understand authentication activity.

• Aggregate reports (rua): Identify where aggregate DMARC reports should be sent. These reports provide summarized information about message volume and authentication results.
• Failure reports (ruf): Specify a destination for certain detailed authentication failure reports, where supported.

Aggregate reports are generally the starting point for monitoring. Failure reports are optional, and not all receiving providers send them. Consider privacy and report-handling requirements before enabling detailed reporting. Use a reporting address that your team monitors or connect it to a reporting system that can interpret the results.

Step 4: Review Alignment Settings

DMARC checks whether SPF or DKIM authentication aligns with the domain in the visible From address.

The record includes two alignment settings:

• SPF alignment (aspf): Controls how closely the SPF-authenticated domain must match the visible From domain.
• DKIM alignment (adkim): Controls how closely the domain associated with the DKIM signature must match the visible From domain.

Relaxed alignment generally allows domains within the same organizational domain to align. Strict alignment requires an exact domain match. Relaxed alignment is often a practical starting point, but the right choice depends on your domain structure and sending configuration.

Step 5: Review Optional Settings

Some generators provide additional fields for subdomain policies, policy percentages, reporting intervals, and failure-report options.

The subdomain policy (sp) specifies how the DMARC policy should apply to subdomains when configured. The percentage tag (pct) can be used for staged policy deployment, where supported by the applicable specification and receiving systems.

Reporting and failure options control aspects of report handling. You do not need to change every optional field simply because it is available.

If you are unfamiliar with a setting, check its purpose before changing it. Unnecessary or incorrect values can complicate troubleshooting.

Step 6: Generate and Review the Record

After entering the required details, generate the record and review the output.

A basic example of a DMARC record is:

v=DMARC1; p=none; rua=mailto:dmarc@example.com
This example contains three elements:

• v=DMARC1 identifies the DMARC version.
• p=none sets the policy to monitoring rather than quarantine or rejection.
• rua=mailto:dmarc@example.com specifies the destination for aggregate reports.

Replace the example reporting address with an address you control. The generated record should reflect your actual domain and chosen settings. A generator helps format the record, but it does not automatically confirm that your SPF and DKIM configuration is correct or that the record has been published successfully.

Step 7: Publish the Record in Your DNS Settings

Once you have reviewed the output, add it to your domain’s DNS configuration.

In most DNS management panels, you need to create a TXT record with these details:

• Record type: TXT
• Host or name: _dmarc
• Value: The complete DMARC record generated by the tool

Some DNS providers expect the full hostname, such as _dmarc.example.com, instead of just _dmarc. Follow the format required by your provider.

Save the record and allow time for DNS changes to become visible. The time required depends on your provider, caching, and DNS configuration.

Generating the record and publishing it are separate steps. The generator prepares the value, but you must add it to DNS yourself.

How to Check Whether Your DMARC Record Is Working\

After publishing the record, confirm that it is visible in DNS and that the syntax is correct.

Next, review the aggregate reports as they become available. Look for sending sources you recognize, messages that pass authentication, and sources that fail DMARC.

If legitimate messages are failing, check the relevant sending service’s SPF and DKIM configuration and investigate alignment issues before tightening the policy.

Avoid moving directly to rejection simply because the record has been published. A successful setup requires both a valid DNS record and an understanding of how your legitimate email sources authenticate.

Common Mistakes to Avoid When Creating a DMARC Record

A few mistakes can make DMARC deployment more difficult than it needs to be.

• Publishing an enforcement policy too early: Quarantine or rejection can affect legitimate mail that fails DMARC. Review authentication results before increasing enforcement.
• Ignoring third-party sending services: Marketing, support, billing, and CRM platforms may each need appropriate authentication configuration.
• Entering an incorrect reporting address: A mistyped or unmonitored reporting destination limits the value of aggregate reports.
• Assuming a generated record is already active: You still need to publish the record in DNS and verify that it is visible.
• Expecting DMARC to solve every delivery problem: Authentication helps receiving servers evaluate messages, but it does not eliminate spam complaints, poor list quality, or reputation problems.

Taking time to review these details makes it easier to identify configuration issues and manage the transition from monitoring to enforcement.

Final Thoughts

Generating a DMARC record is an important step toward protecting your domain from spoofing and improving visibility into email authentication. The process involves choosing a policy, configuring reporting options, reviewing alignment settings, and publishing the resulting TXT record in DNS.

A DMARC record creator simplifies formatting, but the settings still need to match your domain and sending setup. Start by monitoring authentication results, resolve issues affecting legitimate mail, and increase enforcement only when you are ready.

ExactVerify’s DMARC Record Generator helps you create a record from your selected settings. Use it to prepare the DNS value, then publish and monitor the record as part of your wider email authentication process.

\