DMARC (Domain-based Message Authentication, Reporting and Conformance) is an authentication standard that helps protect the domain used as the sender of emails from spoofing, phishing, and other unauthorized uses.
DMARC uses SPF and DKIM checks and verifies that the authenticated domain is aligned with the one the recipient sees in the From field. It also allows you to instruct providers on how to handle messages that fail these checks.
This article covers which configurations to verify before activating DMARC, how to create the DNS record, and how to choose the most suitable policy.
Before Configuring DMARC
DMARC uses the results of SPF and DKIM, which must therefore be properly configured on the systems used to send emails with the domain.
Specifically:
- SPF allows verification that the server that sent the message is authorized to use the domain.
- DKIM allows verification, through a digital signature, that the message comes from an authorized system and has not been altered during transfer.
DMARC adds an additional check: it verifies that at least one of the domains authenticated via SPF or DKIM is aligned with the domain visible in the From field.
Before configuring DMARC, make sure SPF and DKIM are properly set up for your sending flows.
How DMARC Alignment Works
Consider an email sent from:
newsletter@example.com
The domain used in the From field is example.com. DMARC verifies that this domain is aligned with the one used by SPF or DKIM.
SPF Alignment
For SPF, DMARC compares the domain in the From field with the one used in the Return-Path, on which the SPF check is performed.
For example:
From
newsletter@example.com
Return-Path
bounce@example.com
If SPF is valid and the domains are aligned, the SPF check can be used to pass DMARC.
An SPF check can indeed be valid without necessarily being aligned for DMARC purposes.
In magnews, SPF alignment is not satisfied by default because the Return-Path used for sending belongs to a magnews technical domain.
If you want to also achieve SPF alignment, you can configure a custom technical sender domain, aligned with your sender domain and configured according to the platform’s instructions.
Learn how to configure a technical sender domain.
DKIM Alignment
For DKIM, DMARC compares the domain visible in the From field with the one indicated in the DKIM signature via the d= parameter.
For example:
From
newsletter@example.com
DKIM Signature
d=example.com
If the DKIM signature is valid and the domain is aligned, the check can be used to pass DMARC.
In magnews, you can achieve DKIM alignment by defining the domain used in the From field as the sender domain and configuring the DKIM record indicated by the platform.
Once configuration is complete, magnews signs messages using a DKIM domain aligned with the sender domain.
Do SPF and DKIM Both Need to Be Aligned?
No. To pass DMARC, it is sufficient that at least one between SPF and DKIM passes the check and is properly aligned with the domain visible in the From field.
However, it is recommended to properly configure both authentication mechanisms.
Create the DMARC Record
DMARC is published in DNS through a TXT record.
If the domain used as sender is:
example.com
the DMARC record must be published on the host:
_dmarc.example.com
A basic configuration is:
v=DMARC1; p=none
The two tags indicate:
-
v=DMARC1: identifies the version of the DMARC protocol. -
p=none: defines the policy to apply to messages that fail DMARC.
Publish the chosen value in the domain’s DNS as a TXT record on the _dmarc host.
There must be only one DMARC record per domain. If one already exists, modify the existing one instead of creating a second.
Choose the DMARC Policy
The p parameter tells providers how to handle messages that fail DMARC.
It can take three values:
nonequarantinereject
These three policies correspond to progressively higher levels of protection.
For a new configuration, it is normally recommended to start with p=none and move to stricter policies only after verifying all legitimate sending flows.
Start with p=none
The recommended initial configuration is:
v=DMARC1; p=none
With p=none, providers perform the DMARC check, but you do not ask them to quarantine or reject messages that fail it.
You can thus begin monitoring flows without risking immediately blocking legitimate emails.
p=none mainly represents a monitoring phase and not necessarily the final configuration.
Monitor Sending Flows
Before making the policy more restrictive, identify all systems that use the domain to send emails.
Besides magnews, there could be, for example:
- Company mail servers.
- CRM systems.
- E-commerce platforms.
- Transactional systems.
- Ticketing systems.
- Other marketing platforms.
- External applications or services.
A restrictive policy can also impact legitimate emails coming from systems not properly authenticated or aligned.
To facilitate monitoring, you can add the rua tag to the record, indicating an address to which providers can send DMARC aggregate reports.
For example:
v=DMARC1; p=none; rua=mailto:dmarc@example.com
The reports allow you to identify:
- Sources using the domain for sending.
- Any SPF or DKIM authentication issues.
- DMARC alignment problems.
- Possible unauthorized uses of the domain.
Reports are generally provided in XML format and can be numerous. It may therefore be useful to use a dedicated address or a specific service to collect and analyze them, such as the one offered by DMARC Advisor.
Move to p=quarantine
When monitoring shows that legitimate flows are properly authenticated and aligned, you can consider:
v=DMARC1; p=quarantine
With this policy, you ask providers to treat messages that fail DMARC as suspicious.
Depending on the provider, these messages may, for example, be delivered to the Spam folder.
p=quarantine thus represents an intermediate step between the monitoring phase and the stricter policy.
Continue to verify that legitimate flows do not present issues during this phase.
Move to p=reject
After verifying that all systems authorized to use the domain are properly authenticated and aligned, you can consider:
v=DMARC1; p=reject
With p=reject, you ask recipient providers to reject messages that fail DMARC.
This policy offers the highest level of protection against unauthorized use of the domain.
There is no set number of days to move from one policy to another: it depends on the complexity of the sending infrastructure and the monitoring results.
Other DMARC Tags
Besides v, p, and rua, a DMARC record can include other tags for more advanced configurations.
Among the most used:
-
sp: defines a specific policy for subdomains. -
adkim: defines the DKIM alignment mode. -
aspf: defines the SPF alignment mode.
With adkim and aspf, it is possible to choose between relaxed and strict alignment.
It is normally not necessary to specify these tags in a basic configuration. Before using them, evaluate their impact on different sending flows.
Verify the DMARC Record
After publishing the record, verify that it is reachable from DNS and that the syntax is correct.
Verify DMARC in magnews
If you have already defined the domain as a sender domain in magnews, you can check for the presence and validity of the DMARC record:
- From the Deliverability Check available in communications.
- From the sender domains section in Settings > Brand Protection.
If magnews detects a problem, check the record published in DNS and verify the presence of any configuration errors.
Verify DMARC with an External Tool
You can also verify the record with external tools that directly query DNS.
For example, DMARC Advisor offers a free DMARC Check to verify:
- If the DMARC record is present.
- If the syntax is valid.
- Which policy is published:
p=none,p=quarantine, orp=reject.
If you need to modify the policy or add other tags, always update the existing TXT record instead of creating a second one.
Frequently Asked Questions
Can I configure p=reject directly?
Yes, but it is recommended only if you have already verified all systems using the domain to send emails.
With p=reject, a legitimate message that fails DMARC could be rejected by the recipient provider.
For a new configuration, it is therefore preferable to start with p=none, monitor the flows, and gradually increase the level of protection.
How long should I stay on p=none?
There is no universally valid duration.
Moving to the next policy depends on monitoring results and the complexity of the sending infrastructure.
Before proceeding, you should have good visibility of the sources using the domain and have verified that all legitimate flows are properly authenticated.
Does p=none protect the domain?
With p=none, you activate DMARC and can monitor domain usage, but you do not ask providers to quarantine or reject messages that fail the check.
To increase protection against spoofing and other unauthorized uses, you can consider, after the monitoring phase, moving to p=quarantine and then to p=reject.
Do SPF and DKIM both need to pass the check?
No. To pass DMARC, it is sufficient that at least one between SPF and DKIM is valid and properly aligned with the domain in the From field.
However, it is recommended to properly configure both.
Does DMARC replace SPF and DKIM?
No.
DMARC uses the results of SPF and DKIM and adds the check on alignment with the sender domain. SPF, DKIM, and DMARC are therefore complementary mechanisms.
Can I have multiple DMARC records?
No. There must be only one valid DMARC record for the same domain.
If you need to add new tags or modify the policy, update the existing TXT record instead of creating a second one.
Is DMARC mandatory for bulk senders?
The main mail providers, including Gmail, Yahoo, and Microsoft, require bulk senders to configure DMARC among authentication requirements.
To meet the requirement, a p=none policy is also allowed, but the message must correctly pass the DMARC check.
It is therefore important to configure DMARC even when you do not yet want to apply a quarantine or reject policy.
Does DMARC directly improve deliverability?
No. The presence of DMARC does not guarantee that a message will be delivered to the Inbox.
However, DMARC is one of the authentication requirements requested by major providers for bulk senders and must therefore be properly configured for high-volume sending.
Proper authentication also allows providers to better verify the sender's identity and helps protect the domain from unauthorized use.
Deliverability also depends on other factors such as sender reputation, contact quality, engagement, sending frequency, and spam reports.