Set up your email domain

Connect your sending domain, arrange a mailbox for authentication reports, then use those reports to move from monitoring to protection against spoofing. You need access to your domain's DNS and your existing email provider.

Examples below use hello@mail.example.com as the sender. Replace every example domain and address with your own.

1. Connect the sending domain

Open Project → Emails → Domains, add mail.example.com, and open its details. Copy the records shown there into your DNS provider:

If Cloudflare manages the authoritative DNS, choose Set up with Cloudflare on the domain page. Sign in, select the owning account, review the Zone Read and DNS Write access, and authorize the changes. funnelsgrove applies the current DKIM and MAIL FROM records plus a starter p=none DMARC record when no policy exists. The temporary grant is not stored, and setup succeeds only after its revocation succeeds. If a CNAME, MAIL FROM MX, SPF, or DMARC record conflicts, funnelsgrove makes no changes; resolve the listed conflict and run setup again.

Record	Where it belongs	What it does
DKIM CNAME records	Each exact name shown in funnelsgrove	Lets Amazon SES sign your messages.
MAIL FROM MX, priority 10	The displayed bounce subdomain, such as bounce.mail.example.com	Routes delivery failures to SES.
SPF TXT	The same bounce subdomain	Authorizes SES to send using that MAIL FROM domain.

Use the displayed values, including the AWS region in the MX destination. The bounce subdomain must have exactly one MX and must not also host an ordinary mailbox. Keep your normal inbox MX records intact. AWS: custom MAIL FROM

Do not add a second SPF policy at an existing name. Have your DNS administrator reconcile existing senders first. SPF record rules

Use your provider's default TTL. If it appends example.com automatically, enter relative names such as bounce.mail or _dmarc.mail. Click Recheck DNS after saving; SES verification can take up to 72 hours. AWS: domain verification

2. Arrange a real destination for reports

Create a dedicated mailbox such as dmarc-reports@example.com with your existing email provider, or an alias that delivers to a mailbox someone monitors. Confirm that it accepts mail from external senders by sending it a normal test message. Keep enough storage for recurring reports and allow their XML/compressed attachments. Alternatively, use the reporting address supplied by a DMARC monitoring service.

Adding a sending domain in funnelsgrove does not create a receiving mailbox. Neither DKIM verification nor the SES bounce MX creates an inbox for dmarc-reports@…. SES receiving is a separate setup and does not provide a normal POP/IMAP mailbox. AWS: receiving concepts

3. Check existing DMARC before adding a record

Review the DMARC result in the domain details. A sending subdomain can already inherit its organizational domain's policy, including its reporting settings. Keep that policy unless the domain owner deliberately changes it. A new p=none record on the subdomain can override and weaken an inherited reject. Do not publish two DMARC policies at the same name. DMARC policy discovery

If no applicable policy exists and your reporting address works, publish:

DNS field	Example
Type	TXT
Name	_dmarc.mail.example.com
Value	v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com;

p=none requests no blocking for DMARC failures. rua requests aggregate reports at the address you arranged. The shorter v=DMARC1; p=none; is a valid starting policy, but it does not request reports. AWS: DMARC setup

If reports go to another organization's domain

The reporting provider must authorize the destination in its DNS. For a policy at _dmarc.mail.example.com reporting to reports@reports.example.net, the authorization is a TXT record at:

mail.example.com._report._dmarc.reports.example.net

with value v=DMARC1;. The reporting provider manages this record; follow its instructions, which may use a wildcard. The name starts with the domain where the applicable policy is published, so inherited policies can change it. Without authorization, receivers ignore that external reporting destination. External report authorization

4. Verify messages and read reports

Recheck DNS, then send a test email to an inbox you control. Inspect its full headers for spf=pass, dkim=pass, and dmarc=pass. DMARC needs a passing SPF or DKIM result whose domain aligns with the visible From domain. SES custom MAIL FROM uses relaxed SPF alignment; preserve existing strict policies and check DKIM alignment before changing them. AWS: DMARC alignment

Reports usually arrive in daily batches from participating receivers. They contain sending sources, counts and authentication results, often as XML or compressed XML. Use a report viewer or your monitoring provider to identify legitimate senders that fail authentication. These reports measure domain authentication; they do not measure campaign clicks or purchases. Aggregate reports

If reports are missing, check mailbox delivery, spam filtering, rua, and any external authorization. Absence of reports is not evidence that all mail passes.

5. Strengthen the policy when your mail is ready

Edit the existing TXT record, keeping its working rua and other intentional settings. For a new policy using the example above:

Stage	Example value	When to use it
Monitor	v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com;	Identify every legitimate service sending for the covered domain.
Quarantine	v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com;	Representative legitimate traffic passes; failures are understood and fixed or deliberately accepted.
Reject	v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com;	Monitoring under quarantine confirms that stricter handling will not unexpectedly block legitimate mail.

Quarantine asks receivers to treat failures as suspicious; reject asks them to refuse failures. Continue reviewing reports and delivery problems after each change. Include infrequent mail such as monthly billing in your review; elapsed days alone do not prove readiness. AWS: phased DMARC rollout

Some older rollout guides suggest pct=5 to sample enforcement. The current DMARC standard removed pct because receivers applied it inconsistently. This guide uses explicit policy stages; do not rely on a percentage to protect untested mail. DMARC: removal of pct

DNS verification and DMARC help authenticate your sender. They do not guarantee inbox placement. Continue following the email sending policy, including consent and unsubscribe requirements. Gmail permits p=none for its bulk-sender DMARC requirement, but that is a starting point for authentication, not enforcement against spoofing. Gmail sender requirements