DMARC Generator: Create the Perfect DMARC Record in 2 Minutes

Why every domain needs DMARC

In the current email security landscape, not having a DMARC record is like leaving the door open to attackers. Google, Yahoo, and Apple made email authentication mandatory for bulk senders in 2024, but even for low-volume domains, DMARC has become a fundamental requirement for deliverability. Without DMARC, emails sent from your domain are treated with greater suspicion by receiving servers, increasing the likelihood they end up in spam.

Our DMARC Generator simplifies record creation by eliminating the need to memorize the syntax. Simply select the desired options — policy, report email, alignment parameters — and the tool generates the TXT record ready to copy and paste into your DNS panel. But before generating the record, it is essential to understand each parameter and its implications.

DMARC parameters explained

v=DMARC1;          # Versione (obbligatorio, sempre DMARC1)
p=quarantine;       # Policy per il dominio: none|quarantine|reject
sp=reject;          # Policy per i sottodomini (opzionale)
pct=100;            # Percentuale di email a cui applicare la policy
rua=mailto:x@d.com; # Email per report aggregati (consigliato)
ruf=mailto:y@d.com; # Email per report forensi (opzionale)
adkim=r;            # Allineamento DKIM: r=relaxed, s=strict
aspf=r;             # Allineamento SPF: r=relaxed, s=strict
ri=86400;           # Intervallo report in secondi (default 24h)
fo=1;               # Opzioni report forense: 0|1|d|s

The pct parameter is particularly useful during rollout: it allows you to apply the policy to only a percentage of emails. With pct=25, only 25% of unauthenticated emails are treated according to the policy (quarantine or reject), while 75% are treated as if p=none. This allows for a gradual and safe rollout: start with pct=10, monitor the reports, increase to 25, 50, 75, and finally 100.

DMARC implementation workflow

Before generating the DMARC record, verify that the foundations are solid. Use SPF Lookup to confirm that the SPF record is valid and covers all services that send email on your behalf. Check DKIM for every service that supports it. Only after confirming that authentication works can you proceed with DMARC.

The recommended workflow involves four phases: Week 1-2, generate a record with p=none and rua to start collecting data. Week 3-4, analyze the reports and fix any authentication issues. Month 2, switch to p=quarantine with pct=25 and gradually increase. Month 3+, when reports confirm that all legitimate emails pass authentication, activate p=reject with pct=100.

Common DMARC configuration mistakes

The most frequent mistake is skipping the monitoring phase and activating p=reject directly. This can block legitimate emails from third-party services (CRM, newsletter, invoicing) that are not covered by SPF or DKIM. Another mistake is not specifying rua: without aggregate reports, you are flying blind and cannot know if legitimate emails are being blocked by your policy.

Also watch out for alignment: with aspf=s (strict), the domain in the Return-Path must exactly match the domain in the From. Third-party services that use their own domain in the Return-Path will fail strict alignment. Use relaxed (r) unless you have specific security requirements that demand strict. The same applies to adkim: relaxed allows subdomains to align, strict requires an exact match.

A common technical mistake is inserting the TXT record with the wrong hostname. The DMARC record must be placed exactly at _dmarc.yourdomain.com, not at the domain root and not at dmarc.yourdomain.com (without the underscore). Verify with our DMARC Lookup that the record is visible and syntactically correct after deployment. DNS propagation typically takes from a few minutes to a few hours.