DMARC agent that does the work for busy IT Teams

DMARC is an email authentication standard that protects the domain in the visible From address. A message passes DMARC when SPF or DKIM passes and the authenticated domain aligns with the From domain. The domain owner can ask receivers to monitor, quarantine, or reject failures and send aggregate reports. Read the complete DMARC guide.

Email authentication is the set of technical checks receiving mail systems use to verify a message's sending domain and authorized infrastructure. SPF authorizes sending servers, DKIM verifies a domain's cryptographic signature, and DMARC connects those results to the visible From domain. Together, they reduce direct domain spoofing and identify legitimate mail. Learn how email authentication works.

SPF authorizes sending servers, DKIM verifies a cryptographic signature, and DMARC checks whether either result aligns with the visible From domain. DMARC also publishes a policy for failed mail and enables reporting. Most business domains use all three because each standard solves a different part of email authentication. Compare SPF, DKIM, and DMARC.

An SPF record is a DNS TXT record that identifies the mail servers authorized to send for a domain. A receiving server compares the message's sending IP address with that policy. SPF authenticates the envelope-from domain, not the visible From address, and forwarding can break the check. Learn how SPF works.

DKIM, or DomainKeys Identified Mail, adds a cryptographic signature to an outgoing email. The receiving server retrieves the sender's public key from DNS and verifies that the signed content has not changed. A valid signature also shows that the signing domain accepts responsibility for the message. Learn how DKIM signatures work.

Check the public DNS records for your domain, then inspect headers from real messages to confirm that SPF, DKIM, and DMARC pass and align. Palisade provides free SPF, DKIM, and DMARC checkers. A DNS lookup validates the published record, but only message tests reveal sender-specific failures.

DMARC is not universally mandatory, but it is required for many high-volume senders delivering to Gmail, Yahoo, and Outlook.com consumer accounts. Other organizations may face contractual, insurance, or sector-specific requirements. Even when no rule applies, DMARC at enforcement is the standard control for blocking direct spoofing of your domain.

Gmail and Yahoo require bulk senders to use SPF, DKIM, and a DMARC record with at least p=none. Microsoft requires domains sending more than 5,000 messages per day to Outlook.com consumer addresses to pass SPF, DKIM, and DMARC. Each provider also sets rules for alignment, spam rates, DNS, and one-click unsubscribing.

Yes, DMARC at enforcement can stop direct spoofing of a protected domain when receiving systems honor the published policy. It does not stop lookalike domains, compromised accounts, or display-name impersonation because those attacks do not directly spoof the protected From domain. See how to prevent email spoofing.

DMARC can support email deliverability by helping mailbox providers authenticate legitimate mail and by exposing configuration problems. It does not guarantee inbox placement; reputation, complaints, list quality, content, and sending patterns still matter. Enforcing DMARC before every legitimate sender is aligned can cause delivery failures. Learn how DMARC affects delivery.

DMARC fails when neither SPF nor DKIM both passes and aligns with the visible From domain. Common causes are an unauthorized sending service, missing or invalid DKIM, forwarding that breaks SPF, a third party authenticating with its own domain, or a DNS error. Troubleshoot DMARC failures.

A DMARC policy of p=none requests monitoring and reporting without asking receivers to quarantine or reject messages that fail. Domain owners use it to discover legitimate sending sources and fix authentication before enforcement. It is a useful rollout stage, but it does not ask receivers to block direct spoofing. Review DMARC policy tags.

DMARC p=quarantine asks receivers to treat failing mail as suspicious, usually by placing it in spam; p=reject asks them not to accept the message. Reject offers the strongest protection against direct domain spoofing, but it should be used only after legitimate senders pass aligned SPF or DKIM. Compare DMARC policies.

DMARC enforcement means publishing p=quarantine or p=reject so receivers are asked to act on messages that fail DMARC. A domain is fully enforced when the policy covers all intended mail, commonly with pct=100 and appropriate subdomain policy. Move to enforcement after identifying senders and fixing SPF, DKIM, and alignment. See the path to enforcement.

DMARC aggregate reports are machine-readable XML summaries that participating receivers send to the address in a domain's rua tag. They show sending sources, message counts, SPF and DKIM results, alignment, disposition, and policy. They do not contain message bodies. Learn how to read DMARC reports.

SPF flattening replaces DNS-based include chains with their current IP ranges to reduce lookup count. It can help avoid SPF's 10-lookup limit, but a static flattened record becomes stale when a provider changes infrastructure. Safe flattening requires continuous monitoring and automatic updates. Check your SPF record.

SPF permits at most 10 DNS-querying terms during one evaluation. The include, a, mx, ptr, exists, and redirect mechanisms can count, including nested lookups. Exceeding the limit produces a permanent SPF error, so approved email may fail SPF. Review SPF syntax and limits.

Not always. The organizational domain's DMARC policy applies to subdomains unless its sp tag or a separate subdomain record sets a different policy. Publish a separate record when a subdomain needs different reporting, alignment, or enforcement. Any subdomain that sends mail still needs correctly configured authentication. Review DMARC for subdomains.

No. A domain should publish exactly one DMARC TXT record at its _dmarc hostname. If receivers find multiple DMARC records, DMARC processing stops and the policy is not applied. Combine all required tags and reporting destinations in one syntactically valid record. Fix multiple DMARC records.

Most business domains should configure SPF, DKIM, and DMARC. A message needs only aligned SPF or aligned DKIM to pass DMARC, but using both creates more reliable coverage across direct delivery, forwarding, and third-party services. DMARC then adds visible-domain alignment, failure policy, and reporting.

DMARC stops one common phishing technique: direct spoofing of a protected domain in the visible From address. It does not stop all phishing because attackers can use lookalike domains, compromised legitimate accounts, malicious links, or social engineering that passes email authentication. DMARC is a core domain-protection control, not a complete anti-phishing system.

Yes, an enforcement policy can affect legitimate mail when an approved sender lacks aligned SPF or DKIM. A p=none policy only requests monitoring, while p=quarantine and p=reject ask receivers to change handling. Inventory every sender, fix authentication, review reports, and increase enforcement gradually.

DMARC implementation can take days for a simple domain or months for an organization with many vendors, subdomains, and unknown mail streams. Publishing the DNS record is quick; sender discovery, authentication fixes, observation, and safe policy progression determine the timeline. A fixed deadline without representative report data increases delivery risk.

Yes. DMARC is an open technical standard, and publishing a DMARC DNS record does not require a software subscription. The operational work still has a cost: someone must collect reports, identify senders, fix SPF and DKIM, monitor changes, and move the domain safely to enforcement. Organizations can do that manually or use a platform.

BIMI lets a domain publish a brand logo that participating mailbox providers may display beside authenticated mail. BIMI requires DMARC at enforcement, aligned email, and a compliant SVG logo; some providers also require a mark certificate. Meeting the technical requirements does not guarantee that every mailbox will display the logo. Read the BIMI guide.

Palisade is a DMARC and email authentication platform for IT teams, security teams, and service providers. It turns DMARC reports into a sender inventory, identifies authentication and alignment problems, helps manage SPF, DKIM, DMARC, and BIMI, and tracks every domain toward enforcement. Explore the Palisade platform.

Palisade automates DMARC by identifying sending services, analyzing authentication results, and turning problems into prioritized tasks and proposed configuration changes. Teams review the evidence and choose what to apply. Hosted records and continuous monitoring reduce repetitive DNS and reporting work while keeping policy changes under human control. See the DMARC Agent.

Yes. Palisade provides one portfolio view for domains across brands, business units, regions, or customers. Teams can group domains, track authentication and policy status, assign access, and prioritize the domains that need attention. The workflow supports both internal domain portfolios and service providers managing client domains. View multi-domain capabilities.

Yes. Palisade gives managed service providers a central platform to assess customer domains, manage authentication, monitor policy status, and produce client-facing reports. MSP workflows include multi-domain operations, role-based access, prospecting reports, and supported PSA integrations. Explore Palisade for MSPs.

Palisade uses per-domain pricing instead of charging by reported email volume. The first domain is free, so an IT team or MSP can evaluate its own authentication workflow before expanding. Review the current domain allowance, included features, support, and partner terms on the Palisade pricing page.