How to Setup DNS
DNS Blog
How to Set Up DMARC: Policy, Alignment, and a Safe Rollout
A domain can have working email and still be vulnerable to impersonation. Attackers may place its name in the visible From address, hoping recipients will trust a message that did not come from an approved system. DMARC gives domain owners a way to connect SPF and DKIM authentication to that visible identity, request reports, and tell participating receivers how to handle messages that fail.
A safe DMARC setup is a process rather than a single aggressive DNS change. The reliable approach is to inventory every legitimate sender, make SPF or DKIM align correctly, begin with a monitoring policy, study the reports, fix gaps, and then move gradually toward quarantine or rejection.
What DMARC does
DMARC stands for Domain-based Message Authentication, Reporting, and Conformance. A receiving mail system evaluates SPF and DKIM results, checks whether the authenticated domain aligns with the domain shown in the message’s From header, and applies the published DMARC policy.
A message can pass DMARC when at least one of these paths succeeds:
- SPF passes and its authenticated MailFrom domain aligns with the visible From domain.
- DKIM passes and the domain in a valid DKIM signature aligns with the visible From domain.
Requiring alignment is important. SPF alone authenticates the envelope sender used during delivery, which may differ from the address a person sees. DKIM authenticates the signing domain, which also may be different. DMARC connects a successful authentication result to the visible identity. For a broader overview of the mechanism and its anti-phishing purpose, see this guide to DMARC.
Prepare SPF and DKIM first
Confirm every legitimate sending source
Create an inventory of systems that send mail using the domain: primary mail providers, marketing platforms, support desks, transaction services, billing tools, monitoring systems, website forms, and any service that sends on behalf of a subdomain. An incomplete inventory is the most common reason legitimate mail begins failing when enforcement increases.
Check SPF authorization and alignment
SPF lists which systems may send for an envelope domain. Make sure each legitimate source is covered without creating multiple SPF records or exceeding the protocol’s DNS-lookup limits. The existing article on how the SPF record works explains the authorization side in more detail.
For DMARC, an SPF pass is useful only when the authenticated MailFrom domain aligns with the visible From domain. Under relaxed alignment, the domains may share the same organizational domain. Strict alignment requires an exact match. A third-party platform may therefore pass its own SPF check but still fail the SPF path for your DMARC policy unless it supports a custom aligned return-path domain.
Enable DKIM signing with an aligned domain
DKIM adds a cryptographic signature to the message. The receiver retrieves the public key from DNS and verifies that signed parts of the message were not altered. Review the DKIM record guide if you need a refresher on selectors and public keys.
For DMARC alignment, the domain in the DKIM signature’s d= value must align with the visible From domain. Many email platforms support custom DKIM signing for this reason. DKIM often survives forwarding better than SPF, although mailing-list modifications can invalidate a signature if they change signed content.
Create the DMARC TXT record
Publish DMARC as a TXT record at _dmarc.example.com, replacing example.com with the domain used in the visible From address. A sensible monitoring record can look like this:
v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; pct=100The essential tags are straightforward:
- v=DMARC1 identifies the protocol version and must appear first.
- p=none requests monitoring without asking receivers to quarantine or reject failures.
- rua provides one or more addresses for aggregate reports.
- pct specifies the percentage of applicable messages subject to the requested policy; 100 is the default.
Use a real, monitored mailbox or a suitable report-processing service for aggregate reports. Reports are typically XML files and may arrive in volume. Confirm that the receiving mailbox can handle the traffic and treat report data according to the organization’s privacy and retention requirements.
Understand policy and alignment options
Policy levels
- p=none: Request reporting and normal receiver handling. Use it to discover legitimate senders and authentication gaps.
- p=quarantine: Ask receivers to treat failing messages as suspicious, often by placing them in spam or applying extra scrutiny.
- p=reject: Ask receivers to reject messages that fail DMARC evaluation.
These are requested policies, and final message handling remains with the receiver. Moving directly to p=reject can block legitimate traffic if a forgotten service lacks alignment.
Relaxed and strict alignment
The aspf and adkim tags control SPF and DKIM alignment. Relaxed mode, represented by r, is the default and permits aligned subdomains within the same organizational domain. Strict mode, represented by s, requires the domains to match exactly. Strict alignment is not inherently necessary for every domain; use it only when sending architecture and policy require the tighter match.
Subdomain policy
The sp tag can define a separate requested policy for subdomains. Before setting it, identify subdomains that send mail and those used only for websites or services. A domain that should never send mail can often use stronger controls, but verify that no operational tool depends on it first.
Read aggregate reports before enforcing
Aggregate reports summarize how participating receivers see mail claiming to use the domain. They commonly show source IP addresses, message counts, SPF and DKIM results, alignment outcomes, and the policy applied. They do not automatically tell you whether a source is legitimate; administrators must map sources to known services and investigate unfamiliar traffic.
Use the monitoring period to answer practical questions:
- Which approved platforms send mail for the domain?
- Does each source pass aligned SPF, aligned DKIM, or both?
- Are forwarding and mailing-list flows producing expected failures?
- Do unknown sources indicate spoofing, stale systems, or an incomplete inventory?
- Are high-volume failures concentrated in one provider or subdomain?
Move to enforcement gradually
- Start with p=none. Collect enough representative reports to cover normal campaigns, billing cycles, and infrequent systems.
- Fix legitimate senders. Configure aligned DKIM or a custom return path, remove obsolete sources, and correct DNS records.
- Test quarantine. Move to
p=quarantineafter known sources pass consistently. Continue checking reports and support feedback. - Increase coverage deliberately. If using
pctduring rollout, increase it only after reviewing the affected traffic and understanding receiver behavior. - Adopt reject when ready. Use
p=rejectwhen legitimate sources are aligned, exceptions are documented, and monitoring is ongoing.
DMARC does not replace correct mail routing. MX records still identify where inbound mail should be delivered, while DMARC evaluates messages that claim to come from a domain. The article MX record: Why is it important? explains that separate role.
Verify and maintain the deployment
After publishing the TXT record, query the exact _dmarc name from multiple resolvers and confirm that only one syntactically valid DMARC record is returned. Send controlled tests through every approved platform, inspect authentication results in message headers, and verify that aggregate reports begin arriving.
Continue reviewing reports after enforcement. Vendors, sending IPs, return-path domains, and DKIM selectors change over time. Add DMARC review to the onboarding and removal process for every email service, protect access to DNS and mail-provider accounts, and rotate DKIM keys according to provider capabilities and policy.
The protocol’s discovery, alignment, policy, and reporting model is defined in RFC 7489: Domain-based Message Authentication, Reporting, and Conformance.
Conclusion
A successful DMARC setup begins with visibility. Inventory legitimate senders, establish aligned SPF or DKIM, publish a monitoring record, analyze aggregate reports, and correct failures before enforcement. Gradual movement from none to quarantine and then reject protects legitimate mail while making domain impersonation harder and giving administrators useful feedback about abuse.
Backup DNS: Everything you need to know
So, do you want to be 100% sure that your domain is online? Backup DNS for your Primary DNS service is a handy addition that will make your DNS network broader. If you use a Backup DNS, you can add multiple nameservers that will be authoritative for your domain and answer queries.
What is a Backup DNS service?
Backup DNS service (Secondary DNS) is an additional DNS service that you can get from another DNS provider, different from your primary, with the goal to add extra redundancy. You can use extra nameservers as authoritative, and they can answer queries too.
How does the SPF record work?
SPF record – definition
The Sender Policy Framework record, or simply for short SPF record, is a DNS record that indicates the email servers that are qualified for sending email messages on behalf of the domain name.
Cyber-criminals are capable of forging emails in a lot of different ways. So, they are able to change the “Mail from” and mask the emails to look like legit ones coming from a particular domain. Yet, they actually are not from the original source.
Thanks to the SPF record, it is possible to establish strict rules. The DNS administrator applies SPF to precisely limit who is able to use the domain to send emails. The recipient, on the other hand, is able to check the authorization.
PTR record: Why is it important?
What does the PTR record mean?
The PTR record, also known as a pointer record, has a very precise goal. It has to point the IP address to the domain name. In addition, this type of DNS record is able to work either with IPv4 addresses or with IPv6 addresses efficiently. Therefore, thanks to the pointer record, you are able to configure and perform Reverse DNS.
This DNS record gives the ability to ensure and verify that the particular IP address is exactly belonging to the domain name. That is very important when it comes to sending an email. The receiving mail servers usually desire to verify the source of the email and perform a reverse DNS lookup. Therefore, they examine and seek exactly the PTR records.
MX record: Why is it important?
MX record is one of the common DNS records that is essential to know. Each action that you want to perform and is related to domains also requires DNS records for guidance. So let’s explain what the purpose of it is and why it is important.
MX record explained
You can probably find the MX record to be called a mail exchanger record. Don’t get confused. It is the same thing. The DNS MX record points to which server is arranged for accepting the emails that go for an exact domain.
For example, if you want to send an email to Daniel@example.com, your device will have to know the location of Daniel’s email host. Therefore, it will view for the MX record on the name server of the domain. This server has the data for the domain example.com. After once you have it, your device will get the information about the server, which is arranged to accept the mail. After that, it will send the email there.
So to get it clear.
People need it to send you emails. More accurately to your domain. They receive the information about where the mails are supposed to be sent and the correct server.
What does a Primary DNS server mean?
If you could have an x-ray of the Internet or any other network, you could see how servers are the keystone for them to work. The amount of them and the tasks they comply with are vital for these systems’ existence.
What does a Primary DNS server mean?
It’s called Primary DNS server or Master DNS server. These names indicate its importance since it’s the source of all the original data for a specific DNS zone and its corresponding domains. A Primary DNS server is responsible for storing all the DNS records for its DNS zone. Therefore, every time a record (or more) requires a change, edition, or to be deleted, that can only be made in the original source, the Primary DNS server.
What is a SOA record in DNS?
SOA record is an essential and one of the most common DNS records. It is crucial to understand it properly. So, let’s explain it!
SOA record explained.
The SOA record is the beginning of the chain of authority, which is typical for the DNS. The short SOA stands for start of authority. From all the nameservers that you have, the SOA record will show which holds the original zone file. This server will contain all of the essential data about the zone. It will be your authoritative DNS server.
DKIM record explained.
Spam has become a daily nuisance for everybody. The number of spam e-mails can overwhelm our inboxes, reducing the space and chances for important messages to be received. Besides, they are a constant and real threat to our security. Scams, phishing attacks, malware can be attached to them, risking our personal information, business, and systems.
Fortunately, developers constantly improve and innovate with tools to defeat, or at least mitigate, these threats. DKIM is an example.
Why do you need a DKIM record?