Last updated: July 2026

In short: After this guide your domain publishes a DMARC record that tells receiving servers what to do with unauthenticated mail — and shows you via reports who sends in your name.

Prerequisites

  • An IONOS account with access to DNS management
  • SPF and DKIM must be set up first — DMARC builds on them and doesn’t work without this foundation

What is DMARC?

DMARC (Domain-based Message Authentication, Reporting & Conformance) combines SPF and DKIM into an enforceable policy. It’s a TXT record that IONOS creates under the subdomain _dmarc (e.g. _dmarc.example.com). In it you define two things: what a recipient should do with mail that fails the check (the p policy), and where it sends you reports (the rua address).

The reports are the clever part: via rua you get daily aggregated reports on which servers send in your name — legitimate and forged alike. That’s exactly what makes the path to safe enforcement.

The safe path: none → quarantine → reject

You don’t switch DMARC to enforcing right away. The three policy levels are a ramp:

  1. p=none — observe, block nothing. According to IONOS it “has no effect on email delivery and is particularly suitable for testing”. You start here and collect reports.
  2. p=quarantine — suspicious mail lands in spam. Optionally with pct= for only a portion, to test carefully.
  3. p=reject — unauthenticated mail is rejected. The goal.

Only move on when the reports show that all your legitimate sending sources pass SPF/DKIM. Otherwise you block your own mail.

Step-by-step guide

1. Start with p=none

Begin with the observation record:

v=DMARC1; p=none; rua=mailto:dmarc@beispiel.de

The rua address is the mailbox (or service) that receives the aggregated reports. For analysis, a DMARC monitor like MARCo is worthwhile — it makes the daily XML reports readable and shows you which sources aren’t yet cleanly authenticated.

2. Create the DNS entry in your IONOS account

For your domain, under Actions, click the three-dots icon, then DNS. Choose Add record → type TXT. In the Hostname field enter _dmarc — the subdomain _dmarc.example.com is created automatically. In Value you enter the record (tags separated by semicolons).

3. Analyze reports, then tighten

After one or two weeks of p=none, the reports show whether all sources are clean. Then switch to quarantine — feel free to stagger with pct:

v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@beispiel.de

pct=25 applies the policy to 25% of mail — increase step by step to 100.

4. Switch to reject

When quarantine runs cleanly, enforcement follows — optionally with strict alignment and a subdomain policy:

v=DMARC1; p=reject; rua=mailto:dmarc@beispiel.de; sp=reject; adkim=s; aspf=s

5. Wait until the change is live

DNS changes take time — a few hours depending on caching.

The most important tags

TagMeaning
v=DMARC1version, must be at the start
p=policy: none (observe), quarantine (spam), reject (reject)
rua=address for aggregated status reports
ruf=address for forensic failure reports
sp=separate policy for subdomains
adkim= / aspf=alignment (r relaxed, s strict) for DKIM and SPF respectively

On adkim=s: “The header of the emails must exactly match the value d=name in the DKIM email headers” — strict, but safest when your setups are clean.

Verify the result

Check your configuration with the free MXAudit scanner — it shows you the DMARC policy, SPF, and DKIM at a glance.

Common mistakes

Straight to p=reject. Without a prior none phase you almost certainly block legitimate sources (newsletter, CRM, invoicing tool) that aren’t yet cleanly authenticated. Always start with p=none and read the reports.

No rua set. Without a report address you’re flying blind — you never see which sources fail. rua belongs in from the start.

DMARC without SPF/DKIM. DMARC evaluates the results of SPF and DKIM. If both are missing, no mail passes the check. First SPF and DKIM, then DMARC.

Wrong hostname. The record belongs at _dmarc — not at @ or the bare domain.

Further reading