🛡️ How to Set Up DMARC for PodPitch

How to Set Up DMARC for PodPitch

DMARC (Domain-based Message Authentication, Reporting, and Conformance) tells receiving mail systems what to do when a message using your domain does not authenticate correctly. It also provides reports that help you find legitimate senders, configuration gaps, and attempted spoofing.

DMARC passes when at least one of these methods both passes and aligns with the visible From domain:

SPF for the envelope or Return-Path domain; or
DKIM for the signing domain.

Important: Do not publish p=reject as your first DMARC policy. If a legitimate sender is missing or misaligned, an enforcement policy can send valid mail to spam or cause it to be rejected.

How DMARC relates to PodPitch

PodPitch send outreach through a mailbox you connect to the applicable workspace. In PodPitch, manage it under Email Addresses. The connected mailbox provider and any other services that send as your domain must authenticate and align correctly.

Before you add or change DMARC

Inventory every service that sends email using the domain.
Confirm that the domain has one valid SPF record and that all legitimate senders are covered.
Enable DKIM for every service that supports it.
Send test messages and confirm that SPF or DKIM passes and aligns with the visible From domain.
Choose a mailbox or DMARC reporting service that your team will actively monitor.
Confirm who manages DNS and who can approve a domain-wide enforcement change.

If you cannot complete these checks, keep DMARC at monitoring only and ask your email administrator for help.

Create the DMARC record

DMARC is published as a TXT record at _dmarc for the domain. There should be one DMARC record at that host.

Use your email provider's DMARC setup tool, a trusted DMARC reporting service, or your email administrator to build the exact record. Do not copy a complete record from an article or another domain.

The record may include these tags:

v=DMARC1 — identifies the record as DMARC.
p=none, p=quarantine, or p=reject — sets the requested policy.
rua=mailto: followed by a real, monitored reporting address — receives aggregate reports.
pct= — applies an enforcement policy to a percentage of messages during a gradual rollout.
sp= — sets a separate policy for subdomains when needed.

Use an address your organization actually controls or an authorized DMARC reporting service. Do not leave a placeholder or example address in DNS.

The optional ruf forensic-report tag can expose message-level information and is not supported by every receiver. Do not add it unless your security or legal team has approved the destination and data handling.

Stage 1: Monitor with `p=none`

Start with p=none and collect aggregate reports. This asks receivers not to take a DMARC-specific enforcement action while you identify every legitimate mail stream.

Monitor for at least one week and through a full business sending cycle. Continue longer if your organization has monthly, seasonal, or low-volume senders.

Review:

which services send using your domain;
whether SPF or DKIM passes;
whether the passing domain aligns with the visible From domain; and
whether any legitimate source is failing.

Fix every legitimate failure before enforcement.

Stage 2: Move gradually to `p=quarantine`

After the reports show that legitimate mail is aligned, move to p=quarantine for a small percentage of failing messages. Microsoft 365 and Google Workspace both recommend a gradual rollout.

Depending on your mail volume and risk tolerance, your email administrator may begin with pct=1 or pct=10, monitor the results, and then increase through stages such as 25, 50, 75, and 100 percent.

Pause the rollout and fix the source if valid mail is quarantined.

Stage 3: Move gradually to `p=reject`

Use p=reject only after:

every known legitimate sender authenticates and aligns;
quarantine monitoring shows no unexplained valid-mail failures;
the reporting mailbox or service is still being reviewed; and
the business owners of important mail streams approve enforcement.

Start with a limited percentage when appropriate, monitor closely, and increase only when results remain clean. Continue monitoring after reaching full enforcement.

Microsoft 365 domains should follow this same sequence. Do not jump directly from no DMARC record to p=reject.

Alignment settings

DMARC uses relaxed SPF and DKIM alignment by default. Relaxed alignment is appropriate for many organizations because a related subdomain can align with the parent domain.

Do not add strict alignment settings such as aspf=s or adkim=s unless your email administrator understands every sending path and has a specific reason to require them.

Subdomains

Subdomains normally inherit the parent domain's DMARC policy unless you publish a subdomain policy or a separate DMARC record. Review active sending subdomains before strengthening the parent policy.

Verify DMARC

Confirm that exactly one TXT record is visible at _dmarc for the domain.
Send fresh tests from every legitimate sending service.
Open the full headers and find Authentication-Results.
Confirm dmarc=pass and review the SPF and DKIM domains used for alignment.
Continue reviewing aggregate reports after every policy or percentage change.

If legitimate mail is affected

Stop increasing enforcement. Identify the failing sender and correct SPF, DKIM, or alignment. If the impact is broad, your email administrator can temporarily reduce the policy while the issue is fixed.

Do not solve DMARC failures by authorizing unknown senders, publishing a second SPF or DMARC record, or disabling authentication across the domain.

Need help?

Message Support through the chat in your PodPitch dashboard and share your sending domain, email provider, current DMARC policy, and a redacted Authentication-Results header. Do not share passwords, recovery codes, private DKIM keys, or full message content that contains personal information.

Official provider guidance

Updated on: 08/09/2026

Was this article helpful?

Thank you!