What is the recommended starting DMARC policy for a new domain?

You should always start with a policy of `p=none`. This monitoring mode allows you to collect aggregate XML reports about your email traffic without blocking or quarantining any messages that fail authentication checks, giving you time to identify legitimate senders.

Why is the leading underscore required in _dmarc?

The DMARC specification mandates that the DNS lookup queries look specifically for the `_dmarc` label under the organizational domain. This naming convention prevents naming collisions with standard website or application subdomains.

How long does it take for IBM Cloud DNS updates to propagate globally?

Most DNS updates propagate within a few minutes depending on the TTL value you selected and global resolver caching. However, complete propagation across all global recursive DNS servers can occasionally take up to 24 hours.

Can I use an external email address for DMARC aggregate reports?

Yes, but if you send reports to a domain different from your publishing domain, the target domain must explicitly authorize it by hosting an external reporting DNS record. Otherwise, mail servers will ignore the rua tag for security reasons.

When should I upgrade my policy from quarantine to reject?

You should upgrade your policy to `p=reject` only after reviewing your aggregate reports for several weeks and confirming that 100% of your legitimate email sources are fully aligned with both SPF and DKIM.

IBM Cloud DNS DMARC Record Configuration Manual

Configuring an IBM Cloud DNS DMARC record is a critical step in safeguarding your domain reputation and protecting your recipients from phishing attacks. By publishing a Domain-based Message Authentication, Reporting, and Conformance (DMARC) record, you instruct receiving mail servers on how to handle emails that fail SPF and DKIM checks.

Implementing this correctly requires adding a specific TXT record to your authoritative DNS zone within the IBM Cloud console. If you want to streamline this setup process, you can use the DMARC Record Generator to instantly build a secure and syntactically correct policy tailored to your exact reporting and enforcement needs.

Understanding DMARC Basics and Prerequisites

DMARC works in tandem with two existing email authentication protocols: Sender Policy Framework (SPF) and DomainKeys Identified Mail (DKIM). SPF validates the sending IP address against your authorized server list, while DKIM adds a cryptographic signature to verify message integrity. DMARC ties these mechanisms together to your visible From: header, enforcing domain alignment and offering reporting mechanisms.

Before you create your DMARC record on IBM Cloud DNS, you must ensure two foundational elements are in place:

Active SPF Record: You must have a valid SPF TXT record published at the root of your domain (e.g., example.com).
Active DKIM Setup: Your outbound mail providers must sign your outgoing emails with valid DKIM keys, and those public keys must be published in your DNS.

Failing to establish SPF and DKIM before enforcing a strict DMARC policy can result in all your legitimate mail being rejected or sent to spam.

Planning Your DMARC Policy

A DMARC record is structured as a series of tag-value pairs separated by semicolons. When planning your policy, you need to decide on three main parameters: the policy mode (p), the subdomain policy (sp), and the reporting destinations (rua and ruf).

Core DMARC Tags Explained

v: Protocol version. Must always be set to DMARC1.
p: Policy for the main domain. Options are none (monitor only), quarantine (send failing emails to spam), and reject (block failing emails entirely).
sp: Policy for subdomains (inherits the p value if omitted).
rua: URI for aggregate statistical reports (usually an email address like mailto:dmarc-reports@example.com).
ruf: URI for forensic failure reports.
pct: Percentage of messages subjected to filtering (useful for gradual rollout, e.g., pct=20).

DMARC Policy (`p=`)	Behavior for Failed Emails	Recommended Use Case
`none`	Delivered normally, reports sent	Initial monitoring and discovery phase
`quarantine`	Routed to spam or junk folder	Intermediate testing phase
`reject`	Blocked at SMTP connection time	Final enforcement phase for mature domains

Step-by-Step: Adding a DMARC Record in IBM Cloud DNS

IBM Cloud provides a robust DNS infrastructure to manage public zones. To add your DMARC record, you will navigate through the IBM Cloud dashboard to your specific DNS zone.

Step 1: Access Your DNS Zone

Log in to the IBM Cloud console.
Navigate to the menu icon and select Resource list, or go directly to Network > DNS services.
Click on your DNS Services instance and select your target domain zone (e.g., example.com).

Step 2: Create the TXT Record

Because DMARC operates via the _dmarc subdomain, the record name must always be formatted precisely. Note that menu paths in the IBM Cloud console may differ slightly depending on UI updates, but the core DNS record manager remains consistent.

Inside your DNS zone view, click Add to create a new resource record.
Set the Name field to _dmarc (or _dmarc.example.com depending on whether the interface automatically appends your root domain).
Set the Type field to TXT.
Set the TTL (Time To Live) to a standard value, such as 3600 seconds (1 hour).
In the Value or Text field, enter your DMARC record string. For example:
```
v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; sp=none;
```
Click Save or Add record to commit the changes to the zone.

Verifying Your IBM Cloud DNS DMARC Record

Once you have published the record, you need to verify that it is publicly accessible and syntactically valid. Global DNS propagation usually takes a few minutes, but can occasionally take up to a few hours.

You can verify your record using command-line tools like dig or nslookup from your local machine.

dig +short TXT _dmarc.example.com

Expected Output:

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

If you prefer using PowerShell on Windows, run the following command:

Resolve-DnsName -Name _dmarc.example.com -Type TXT

To ensure your mail server configurations are sound, you can also perform a quick TLS check or inspect headers of emails sent from your infrastructure using openssl or curl against your mail submission ports if applicable.

Common Mistakes and How to Fix Them

Even experienced engineers occasionally make syntax errors when configuring DMARC. Avoiding these common pitfalls will save your email deliverability:

Incorrect Record Name: Omitting the leading underscore. The record must strictly be named _dmarc, not dmarc. If your IBM panel appends the domain name automatically, entering _dmarc results in _dmarc.example.com.
Conflicting Multiple Records: Publishing more than one DMARC record for the same domain. Receiving servers will ignore multiple records, leading to a complete failure of your policy. Always combine settings into a single TXT record.
Jumping Straight to Reject: Setting p=reject on day one without reviewing aggregate reports. This frequently breaks legitimate third-party mailing tools that have not been properly aligned with SPF or DKIM. Always start with p=none.
Syntax Typos: Forgetting semicolons between tags or misspelling tags (e.g., writing policy=reject instead of p=reject).

DMARC Implementation Checklist

Verify that SPF and DKIM are fully configured and passing.
Create a dedicated mailbox (e.g., dmarc-reports@example.com) to collect XML reports.
Generate your baseline policy starting with p=none.
Log into IBM Cloud DNS and create a new TXT record with the name _dmarc.
Verify propagation using dig or nslookup commands.
Monitor XML reports for 2 to 4 weeks before escalating to p=quarantine and eventually p=reject.