# Palisade: full content > Palisade is agentic DMARC software for IT teams and MSPs. Find every sender, fix SPF and DKIM, and reach p=reject with human-approved changes. This file contains the full text of every published Palisade guide. The curated index with product and tool links is at https://www.palisade.email/llms.txt. Each section begins with the canonical URL of the page it came from; cite that URL when referencing the content. ## Learning Center guides --- # Apple phishing email: how to verify and report it Canonical: https://www.palisade.email/learning/apple-phishing-email > Apple never asks for your password or a verification code by email. Check the claim in Settings or at appleid.apple.com, then report the message to Apple. Treat an unexpected Apple email as unverified until you confirm its claim outside the message. Do not use its links, call a number it provides, open an attachment, or share an Apple Account password or verification code. Instead, use a trusted Apple device or type an official Apple address yourself. Apple asks recipients to forward suspicious email claiming to be from Apple to `reportphishing@apple.com`. ## Quick takeaways - A familiar Apple logo, display name, or visible From address is not proof by itself. - Apple says its support representatives will never ask for your password or device passcode. - Never share or enter a six-digit verification code because an unsolicited message or caller asks. - Verify a purchase, device, case, or security event through an Apple surface you opened independently. - Forward suspected Apple phishing to `reportphishing@apple.com` and follow any internal security process. This guide belongs to Palisade's [email threats hub](/learning/threats). It addresses Apple impersonation across receipts, security alerts, and support pretexts. It does not provide an allowlist of every address Apple may use. ## What does an Apple phishing email look like? Apple's current social-engineering guidance identifies several observable signs: a sender address that does not match the claimed company, a link whose URL does not match the company website, a message that looks different from legitimate company mail, a request for personal information, or an unsolicited attachment ([Apple: recognize and avoid social engineering](https://support.apple.com/en-us/102568)). Any one detail can have an innocent explanation, so use it to trigger verification rather than announce a verdict. Here is a fictional worked example using a domain that cannot be registered: ```text From: Apple Account Security Subject: Purchase 630184 will be approved in 27 minutes We detected a USD 1,149 Mac purchase. Call +1 202-555-0147 now and read the six-digit code sent to your device to cancel it. ``` The useful evidence is concrete. The sender uses `apple-account-review.invalid`, not an Apple-controlled domain. The message combines a `27`-minute countdown, a high-value purchase, an unsolicited phone number, and a request for a six-digit code. The transaction identifier `630184` provides something to compare with independently opened account activity. None of those values comes from a real campaign. An authentic-looking address would not remove the need to verify. The visible From field is supplied as part of a message and can be forged. Receiver-added authentication results may provide stronger domain evidence, but they do not prove that the claimed purchase exists, that the reply address is safe, or that a link leads where its label says. Record concrete mismatches before deciding. ![Verification map separating a suspicious Apple email from independent account activity and Apple's reporting path](/images/editorial/apple-phishing-email/apple-verification-map.svg "1200x676") *Source: Palisade deterministic workflow based on [Apple's social-engineering guidance](https://support.apple.com/en-us/102568).* Verify through a trusted Apple surface. ## How do I verify the claimed Apple activity? ### Check the event without using the email Use a trusted Apple device, an established Apple app, or a typed official Apple URL. Look for the claimed purchase, subscription, device, password change, or support case. If the message claims a receipt, compare it with purchase history. Apple's guidance for legitimate App Store and iTunes Store purchase emails says genuine receipts include the current billing address and will not ask for a full credit-card number or card security code ([Apple purchase-email guidance](https://support.apple.com/en-gb/102406)). The page is region-labelled, so field names can vary by country. ### Compare the request with what Apple says it will not ask Apple says support will never ask for an Apple Account password, device passcode, or two-factor authentication code. It also says support will never ask a person to tap Accept in a two-factor dialog or disable security features such as two-factor authentication, Find My, or Stolen Device Protection ([Apple social-engineering guidance](https://support.apple.com/en-us/102568)). A request for any of those actions is enough to stop the conversation and use an independent support route. Apple's current two-factor documentation describes a six-digit verification code shown on a trusted device or sent to a trusted phone number when signing in on a new device or browser ([Apple two-factor authentication](https://support.apple.com/en-us/102660)). The code authorizes access. It is not a ticket number to read to someone who contacted you. ### Inspect destinations without visiting them On a desktop mail client, view the destination the client exposes without clicking. On an iPhone or iPad, Apple's own guidance is to touch and hold the link, which shows its destination without navigating to it. A lookalike such as `apple-support.example.net` belongs to `example.net`, not Apple. The important part is the registrable domain, not the occurrence of the word "apple" somewhere to its left or in the path. The [Palisade phishing link checker](/tools/phishing-link-checker) inspects a URL's public threat signals without you visiting it, though a clean result is not proof the destination is safe. Do not sign in after following an unexpected message link merely to see whether the page works. A phishing site can relay credentials to the real service and ask for the code immediately. ### Use headers as supporting evidence An authorized security team can inspect raw headers. RFC 8601 Section 1.2 explains that `Authentication-Results` must be interpreted within the receiver's trust boundary because a sender can add an untrusted field with the same name ([RFC 8601, Section 1.2](https://www.rfc-editor.org/rfc/rfc8601.html#section-1.2)). A pass for an unrelated domain does not authenticate Apple. A pass for an aligned Apple domain can support domain identity, but the recipient should still verify the claimed account activity. The guide on [why phishing passes SPF and DKIM](/learning/why-do-phishing-emails-pass-spf-and-dkim) explains that boundary in more depth. ## How do I report an Apple phishing email? Apple directs people to forward suspicious emails that purport to be from Apple to `reportphishing@apple.com`. Preserve the original message if your mail client supports forwarding it as an attachment, and follow your organization's security-reporting method as well. Apple's page provides different reporting routes for suspicious FaceTime calls, SMS messages, and iCloud spam, so use the route that matches the medium ([Apple reporting instructions](https://support.apple.com/en-us/102568)). Do not reply to the suspected sender. Do not forward an active attachment to colleagues for informal review. If the message targets a work account or device, the security team may need the original headers, delivery logs, account events, and endpoint evidence. ## What if I already clicked or shared information? Close the suspicious page without entering more information. If you entered an Apple Account password, change it through a trusted Apple surface, review trusted devices and account information, and contact Apple through its official support route. If you disclosed a verification code, approved an unexpected sign-in, installed software, or sent money, escalate immediately. A work device or work account also belongs in the organization's incident process. Do not wait for an email reply from the suspected sender. Preserve the URL, time, message, and any account alert. Avoid deleting browser history, mail, or device evidence if your security team has an established preservation procedure. The [Apple two-factor authentication email guide](/learning/apple-two-factor-authentication-email) can help distinguish an expected code notification from an event you did not initiate. The [Private Relay Apple ID guide](/learning/private-relay-apple-id) is about address privacy and does not validate a message claiming to be Apple. ## When does this guidance not apply? This page does not decide whether every Apple-branded message is fraudulent. Real receipts and account alerts can be unexpected, and regional templates can differ. Independent account activity and a trusted support route settle the business context more reliably than a screenshot or remembered template. It also does not apply to a known internal security simulation once the authorized training team confirms the exercise through its established channel. Even then, employees should use the normal reporting action; the lesson should not require unsafe clicking or credential entry. ## Sources and further reading - [Apple: Recognize and avoid social engineering schemes](https://support.apple.com/en-us/102568) - [Apple: Identify legitimate App Store or iTunes Store emails](https://support.apple.com/en-gb/102406) - [Apple two-factor authentication](https://support.apple.com/en-us/102660) - [RFC 8601, Authentication-Results](https://www.rfc-editor.org/rfc/rfc8601.html) ## Frequently asked questions ### Can an Apple phishing email show an Apple address? Yes. A visible From address can be forged, and a lookalike domain can be easy to miss. Use trusted receiver-added authentication as supporting evidence and verify the claimed event through an Apple surface you open independently. ### Does Apple ask for a six-digit verification code by email? No. Apple's guidance says support will never ask for a two-factor authentication code. A six-digit code is used to authorize a sign-in on a new device or browser, so keep it private. ### Are billing details proof that an Apple receipt is real? No. Current billing details can support a legitimate-receipt assessment, but copied personal data can appear in fraud. Match the purchase in independently opened Apple purchase history and never provide full card details or a security code by email. ### Should I forward a suspicious Apple email to Apple? Yes. Apple asks recipients to forward suspicious mail purporting to be from Apple to `reportphishing@apple.com`. A workplace message may also need to go through the organization's security-reporting route. ### Can I safely call the number in an Apple security email? No. Use Apple's official support path opened independently. A phone number inside an unexpected message keeps you inside the sender's chosen channel and may connect you to the attacker. ### Will reporting the email secure a compromised account? No. Reporting helps send the message to Apple, but it does not change a password, remove an unknown trusted device, reverse a payment, or inspect a work endpoint. Complete the relevant account and incident-response steps separately. --- # Bank of America phishing email: verify it safely Canonical: https://www.palisade.email/learning/bank-of-america-phishing-email > Bank of America will not ask for your PIN or password by email. Verify any transaction in the app or by calling the number on your card, then report it. Treat an unexpected Bank of America email as unverified until you check the claimed transaction or account event in the banking app, a browser session you open independently, or by calling the number on your card. Do not use the email's sign-in button, reply address, attachment, or phone number. A familiar logo, masked account number, or urgent fraud warning is not enough. ## Quick takeaways - Open the bank app independently and check the exact transaction or alert. - Call the number printed on your card, not a number in the email. - Never send a password, one-time code, PIN, or full card details in response. - Treat payment reversals, locked accounts, and transfer alerts as claims to verify. - Report the email through your mailbox and the bank's current official path. - Contact the bank promptly through a verified channel if money or account access is at risk. ## What does a Bank of America phishing email look like? A Bank of America impersonation email often claims that something changed in the account: a card was locked, an unusual purchase occurred, a transfer or payment needs review, a statement is ready, a deposit is pending, or personal information must be updated. The message may say that access will be limited unless the reader acts quickly. The requested action can be signing in, calling a fraud number, replying with account information, opening a statement, confirming a transfer, or sharing a one-time code. Another pattern promises a refund or reversal but requires the reader to move money or reveal banking details first. These are pattern shapes, not descriptions of a breach or a specific campaign. The bank is being impersonated. The safest response is to remove the email from the verification process and check the claimed event in records controlled by the customer and bank. The Federal Trade Commission explains in its [phishing guidance](https://consumer.ftc.gov/articles/how-recognize-avoid-phishing-scams) that impersonation messages can seek personal information or money. Banking lures add urgency because recipients want to stop a transfer or restore access before checking the contact route. The [phishing examples guide](/learning/phishing-email-examples) covers general patterns. This page focuses on transactions, account access, cards, and payment recovery. ## Which banking email clues matter most? Start with the transaction. Does the independently opened account show the purchase, transfer, card status, or profile change described? A reference number inside the message does not count as separate proof. Match the amount, merchant, date, account, and status against your own records. Read the full sender address and Reply-To value. A display name can say "Bank of America" while the address uses an unrelated or lookalike domain. Extra words and spelling substitutions support suspicion. A familiar-looking sender still does not prove that the phone number, button, or transaction claim is safe. Preview links without opening them. Do not infer ownership because the bank's name appears somewhere in a longer hostname or URL path. Compare the complete destination with the banking route you opened independently. Do not use the email to learn the bank's correct address. Treat requests for a password, PIN, one-time code, full card number, bank-account credentials, or remote access as stop signs. Do not debate the sender or provide partial information. Open a new path to the bank and explain what the message requested. ## How do I verify the transaction safely? Open the banking app you already use or use a trusted bookmark. You can also call the number printed on the back of your card or on a statement you already possessed. Do not search the suspicious email for a better number. Check the specific account evidence: - Review posted and pending card transactions for the named merchant and amount. - Review transfers and bill payments for the claimed recipient or destination. - Check whatever transaction, alert, or profile evidence the independently opened account exposes. - Compare a statement claim with the statement retrieved through your normal banking route. - Ask another authorized account holder whether they initiated the activity. If the event is real and expected, continue only in the independent session. If it is real and unauthorized, locate the bank's current fraud process there or through the card number. If no matching event exists, report the email and keep its links and phone number unused. A fake email can arrive while an unrelated real transaction is pending. Match exact details instead of treating any account activity as confirmation. ## How do I handle a transfer or refund request? Do not move money to "protect" it because an email or caller instructs you to. A transfer request changes the situation from message verification to potential financial loss. End the sender-controlled conversation and contact the bank through a verified route. Refund pretexts can ask you to share card details, sign in, install remote-access software, or return an alleged overpayment. Check whether the original debit exists and whether a credit appears in the account. Do not rely on a screenshot, email receipt, or balance shown by a person who controls your device. For a business account, use the established payment-approval process. Confirm any beneficiary or routing change with the known requester through a separate channel. A security team can examine the email; finance or treasury must validate the payment authority. Keep the call, account, and device paths separate. A caller who knows the amount written in the email has not proved anything because both details came from the same source. ## How do I report a Bank of America phishing email? Bank of America publishes `abuse@bofa.com` for reporting suspicious email ([Bank of America: report suspicious activity](https://web.bankofamerica.com/en/security/report-suspicious-activity)). Verify any account claim by signing in through the app or by typing the address yourself, never through the message. Locate the reporting process documented for the receiving mailbox. If it reached a work account or involved a business banking relationship, follow the organization's security and finance escalation paths. Follow their retention or deletion instructions rather than assuming a universal workflow. To notify Bank of America, open the bank's app or official site independently and locate its current fraud or suspicious-message instructions. You can also call the number on your card or existing statement. Do not guess a reporting email address and do not use a form, link, or number provided by the suspected message. Handle an unauthorized transaction through the bank's current account or card process, reached independently. Handle the suspicious email through the receiving mailbox's documented reporting process. This article does not assume that one submission starts both workflows. The [phishing reporting guide](/learning/report-email-phishing-scams) explains the evidence and destination choices without restating brand-specific examples. ## What if I already shared banking information? Contact the bank promptly through the card number, known app, or trusted statement. Tell the bank exactly what you disclosed: username, password, PIN, one-time code, card number, account number, identity data, transfer approval, or remote access. Those exposures require different controls. Use a trusted device to change exposed passwords and follow the account-recovery checks supplied through the bank's independent app, site, or card number. If you reused the banking password elsewhere, replace it on those accounts too. If money moved, preserve transaction records and ask the bank or payment provider about the available recovery process. If remote-access software was installed, follow a device incident process and do not let the original caller reconnect. If identity documents were shared, use independently located identity-recovery channels. Reporting the email can wait a few minutes while you protect the account and payment path. The [clicked-phishing-link recovery guide](/resources-post/what-to-do-if-you-clicked-on-a-phishing-link) provides separate actions for credentials, payments, and devices. ## Why did a Bank of America phishing email reach me? Sender authentication provides domain-identity evidence, not proof that a delivered banking claim is true. The transaction and support path still need independent verification. [DMARC connects an aligned authentication pass with the domain visible in the From address and publishes a requested policy for failures](https://www.rfc-editor.org/rfc/rfc9989.html). Treat that as domain-identity evidence, then verify the transfer, card charge, or support contact through the independent banking route. Read [why phishing emails can pass SPF and DKIM](/learning/why-do-phishing-emails-pass-spf-and-dkim) for that technical limit. The decisive banking evidence remains the account session and the contact route you opened independently. ## A safe Bank of America email decision rule Write down the claimed account event, amount, and requested action. Then set aside every button, number, address, and attachment that came from the email. Open the bank account or call the number on your card and compare the details. If no matching event exists, report the email. If an expected event exists, handle it in the independent session. If an unauthorized event exists, begin the bank's fraud process. If you already exposed credentials, codes, money, or device access, state that clearly and complete each matching recovery step. This decision rule does not depend on recognizing a perfect fake. It prevents the sender from controlling both the alarming claim and the supposed solution. ## Sources and further reading - [Bank of America: report suspicious activity](https://web.bankofamerica.com/en/security/report-suspicious-activity) - [Federal Trade Commission: How to recognize and avoid phishing scams](https://consumer.ftc.gov/articles/how-recognize-avoid-phishing-scams) - [RFC 9989: Domain-based Message Authentication, Reporting, and Conformance](https://www.rfc-editor.org/rfc/rfc9989.html) - [Palisade phishing reporting guide](/learning/report-email-phishing-scams) - [Palisade phishing email examples](/learning/phishing-email-examples) ## Frequently asked questions ### Does a masked account number prove the email is from Bank of America? No. Compare the claimed event with the independently opened account and contact the bank through the number on your card if needed. ### Should I call the fraud number in the email? No. Call the number printed on your card or a statement you already trust, or use the bank app you opened independently. ### What if the transaction in the email really appears in my account? Handle it through the account's official fraud or transaction process. Do not return to the email's link or phone number. ### Is changing my banking password enough after sharing a code? Not always. Contact the bank and review sessions, recovery details, transfer recipients, and account changes because a shared code may have authorized access. ### Can reporting the email stop a bank transfer? No. Contact the bank or payment provider through a verified channel. Mailbox reporting and financial recovery are separate actions. --- # Docusign phishing email: verify an envelope safely Canonical: https://www.palisade.email/learning/docusign-phishing-email > Never use the link in a suspect Docusign email. Open Docusign independently if you have an account, verify the envelope there, then report the message. Treat an unexpected Docusign envelope email as unverified until the person or organization named as the sender confirms it through a channel you already trust. Do not use the email's review button, attachment, reply address, or phone number. Open Docusign independently if you have an account, and never enter email, Microsoft, Google, or banking credentials merely to inspect an unexpected document. ## Quick takeaways - Confirm who sent the envelope and why before opening it. - Use a known phone number, existing conversation, or independently opened account. - Preview the real destination behind the review button without visiting it. - Treat requests for passwords, payment, or identity documents as a separate high-risk step. - Report the message through your mailbox and current official Docusign help path. - Secure any account used on the linked page if you already entered credentials. ## What does a Docusign phishing email look like? The message often starts with a plausible business event: a contract needs a signature, a completed agreement is ready, an envelope will expire, a vendor updated payment details, an invoice needs approval, or a human-resources document is waiting. The reader is asked to click a review button and act quickly. Some lures copy the idea of an electronic signature but send the reader to a general login page. Others attach a document, ask for identity records, present new bank details, or request payment after the document opens. A fake may also name a real coworker, supplier, lawyer, property transaction, or hiring process. These are pattern shapes. They do not imply that Docusign was breached or caused the message. An attacker only needs the recipient to recognize the brand and accept the signature workflow without confirming the sender's business context. CISA's [phishing guidance](https://www.cisa.gov/secure-our-world/recognize-and-report-phishing) advises people to avoid suspicious links and verify unexpected requests through a known contact method. With an electronic-signature email, that means confirming the document with the named sender before using the envelope route. The [phishing email examples page](/learning/phishing-email-examples) covers more general lures. This guide focuses on the relationship among the email, the envelope, the signer, and the underlying transaction. ## Which Docusign clues matter most? Start with expectation. Did you recently discuss a document with the named sender? Does the subject match that conversation? Are you the right signer, and is the timing plausible? A completely unexpected envelope needs confirmation even when the message looks polished. Read the complete sender and Reply-To addresses. A Docusign display name does not show who controls the address. A sender may use extra words, spelling substitutions, or an unrelated domain. However, a familiar domain alone is not enough because the important question is whether the named person authorized this envelope. Preview the review button's destination. Do not infer ownership because `docusign` appears somewhere in a longer hostname or URL path. Compare the complete destination with the service route you reached independently, then confirm the business request with the named sender. Look at the requested authentication. An unexpected page asking for Microsoft, Google, email, or bank credentials introduces another party and another identity claim. Stop and open the relevant account separately. Do not enter credentials just to reveal the document. ## How do I verify a Docusign envelope without the email? Contact the supposed sender using a phone number, known email address, existing chat, ticket, or case record that predates the envelope. Ask for the document name, purpose, and intended signer without quoting details that came only from the suspicious email. If you already use a Docusign account, open it through your saved app, bookmark, or typed address and use whatever envelope evidence the account exposes. If nothing is visible or the workflow is unfamiliar, confirm the document with the named sender through a pre-existing channel. For a business document, compare it with the underlying workflow: - A contract should match a known deal, counterparty, and approval owner. - A payroll or human-resources form should match an established internal process. - A vendor bank change should receive separate payment-control verification. - A property or legal document should match the known professional and matter. - A hiring document should match a role and recruiter you already confirmed. If the sender confirms the envelope, use the independently opened service or a newly supplied trusted route. Do not return to a questionable link merely because the business event is real. ## Can a real envelope still carry a harmful request? Yes. Even after you locate an envelope through an independently opened signing service, you still need to verify who initiated it and whether the document matches a known transaction. Treat service access, sender identity, and business approval as separate checks. Read the document as a business commitment. A security check alone cannot approve it. Confirm names, entities, amounts, dates, payment destinations, and approval scope against your own records. Do not let an urgent signature deadline bypass normal legal, purchasing, payroll, or finance review. If the document asks you to download another file, continue on a different site, call a new number, or provide a password or verification code, stop again. Each new channel requires its own verification. Trust does not carry automatically from the brand name in the original email. For a workplace, involve the process owner. A security team can assess the message and links; it cannot approve a contract or bank change on behalf of finance or legal. ## How do I report a Docusign phishing email? Docusign routes the two cases differently, and using the wrong one wastes the report. For an email **impersonating** Docusign, or one you are simply unsure about, forward the entire message **as an attachment** to `verify@docusign.com` and delete the original. For a suspicious envelope you received **on the Docusign platform**, use the built-in Report Abuse feature or the "Report this email" link in the envelope notification's footer instead ([Docusign: incident reporting](https://www.docusign.com/trust/security/incident-reporting)). Docusign also states that its official notifications come only from `@docusign.com` or `@docusign.net`, and it names the older "DocuSign" capitalisation as a signal worth a second look, because scammers mix current and legacy branding. Check for a genuine waiting envelope by opening Docusign yourself rather than through the message. Locate the reporting process documented for the receiving mailbox. For a work account, follow the internal security path and identify the supposed sender, document topic, and whether you opened anything. Follow that process's retention or deletion instructions. To notify Docusign, open its official site or app independently and locate the current abuse, security, or support instructions. Do not guess a reporting address and do not use a form linked from the suspected envelope. If a real business contact's identity was used, tell that person through a known channel as well. Do not forward the live review button around for opinions. Send the original only through an approved reporting method. The [phishing reporting guide](/learning/report-email-phishing-scams) covers safe preservation and distinguishes a mailbox report from a report to an impersonated organization. ## What if I already opened the envelope or signed? If you only opened the page and entered nothing, close it and report the message. Record the URL and time without revisiting the destination. Follow your workplace process if the action occurred on a managed device. If you entered a password, change it through the real account and follow that account's current recovery process. If you approved a sign-in or shared a verification code, include that action in the report so the reviewer knows what occurred beyond password entry. If you uploaded identity documents, banking information, or tax records, use independently located identity and financial recovery channels. If you signed a document, notify the responsible legal or business owner and provide the document and surrounding context through its approved process. If the page delivered software or an attachment, follow the endpoint incident process. The [recovery guide after clicking a phishing link](/resources-post/what-to-do-if-you-clicked-on-a-phishing-link) separates credential, document, device, and payment exposure. ## Why did a Docusign phishing email reach me? Sender authentication answers only the domain-identity part of this decision. It cannot tell you whether the signer relationship, document, payment instruction, or approval is expected. [DMARC connects an aligned authentication pass to the domain visible in the From address and publishes a requested policy for failures](https://www.rfc-editor.org/rfc/rfc9989.html). Treat that as domain-identity evidence, then verify the signing workflow and business authorization separately. The Palisade article on [why phishing emails pass SPF and DKIM](/learning/why-do-phishing-emails-pass-spf-and-dkim) explains this limitation. The consumer decision remains grounded in the signer relationship, expected transaction, and independently confirmed sender. ## A safe Docusign decision rule Treat the email, envelope, signer identity, and business transaction as four separate checks. The email introduces the claim. The envelope shows that a signing workflow exists. The known contact confirms who initiated it. Your records and approval process determine whether the transaction is authorized. Do not let one passing check stand in for the others. A real-looking email does not prove the envelope. A real envelope does not prove the sender's authority. A known sender does not remove the need to review the document. A valid document does not make new payment details safe without financial verification. This sequence is slower than clicking "Review," but it is the right speed for a document that can expose credentials, identity data, money, or a binding signature. ## Sources and further reading - [Docusign: incident reporting](https://www.docusign.com/trust/security/incident-reporting) - [CISA: Recognize and report phishing](https://www.cisa.gov/secure-our-world/recognize-and-report-phishing) - [RFC 9989: Domain-based Message Authentication, Reporting, and Conformance](https://www.rfc-editor.org/rfc/rfc9989.html) - [Palisade phishing reporting guide](/learning/report-email-phishing-scams) - [Palisade phishing email examples](/learning/phishing-email-examples) ## Frequently asked questions ### Does a Docusign-branded email prove an envelope is real? No. Confirm the envelope with the named sender through a known channel and locate it through a service you opened independently. ### Can a real Docusign envelope still be suspicious? Yes. A real workflow does not prove that its creator is authorized or that the document, payment request, or identity claim is legitimate. ### Should I sign in with Microsoft or Google to view an unexpected document? No. Stop and verify the envelope first. Open the relevant account and Docusign through trusted routes rather than entering credentials on the linked page. ### What should I do if I already signed the document? Notify the responsible legal, finance, human-resources, or business owner promptly, then complete any account or device recovery that matches what you exposed. ### Is a mailbox phishing report enough? No. It reports the message. You may also need to notify the supposed sender, Docusign through its current official path, your workplace, or a financial institution. --- # Geek Squad phishing email: check a renewal or invoice Canonical: https://www.palisade.email/learning/geek-squad-phishing-email > Fake Geek Squad renewal invoices are the classic version of this scam. Check subscriptions in your Best Buy account, never call the number in the email. Treat an unexpected Geek Squad renewal, invoice, or refund email as unverified until you compare it with your own purchase and plan records. Do not call the number, open the attachment, reply, or use a cancellation link in the message. Check through an independently opened Best Buy account, a receipt you already have, or a contact number printed on your own plan documents. ## Quick takeaways - A large renewal charge is a reason to verify, not a reason to call the email's number. - Check whether you have the named plan and whether your own records show the amount. - Do not install remote-access software for someone who contacted you through the message. - Use the number on your receipt, card statement, or existing plan document if you need support. - Report the email through your mailbox and current official help guidance. - Contact your bank through a verified channel if you paid or shared card details. ## What does a Geek Squad phishing email look like? The usual pretext is a charge that appears urgent and expensive. The email may say a support membership or protection plan renewed automatically, an antivirus subscription is about to expire, an invoice has already been paid, or a refund is waiting. The sender then offers a phone number or button to cancel, dispute, or collect the refund. Another version begins with a supposed support problem. The message may claim that a device is infected, an account needs verification, or a technician must connect remotely. The requested action can shift from a phone call to software installation, access to online banking, a gift-card purchase, or a payment. These are pattern shapes, not a report about one campaign. They use the Geek Squad name to create a believable reason for support contact. The critical question is whether your own records show the plan, purchase, appointment, or charge described. The Federal Trade Commission's [phishing guidance](https://consumer.ftc.gov/articles/how-recognize-avoid-phishing-scams) describes impersonation messages that try to obtain money or personal information. A fake support renewal follows that pattern by turning an unfamiliar charge into a sender-controlled call or cancellation process. See the [phishing email examples guide](/learning/phishing-email-examples) for broader examples. This page stays with renewal, invoice, refund, and remote-support decisions. ## Which renewal and invoice details are suspicious? Start with the relationship. Do you have a Geek Squad plan, recent Best Buy purchase, support appointment, or renewal record that could match? Search your own receipts and card statements. Do not use an invoice number or account record attached to the email as independent evidence. Then inspect what the message asks you to do. A phone-only cancellation route, an instruction to call within minutes, a request to keep the call open, or pressure to install software places the sender in control. A refund that requires remote access to your computer or online banking deserves an immediate stop. Read the sender address and Reply-To value, but do not rely on a remembered allowlist. Geek Squad and Best Buy branding can appear in the display name while the actual address uses an unrelated domain. Extra words, misspellings, and unexpected domains support suspicion. A familiar-looking address still does not prove the charge exists. Invoice attachments add no independent proof. They can contain copied branding, a fake order number, and a large amount designed to provoke a call. Leave the file unopened and compare the claim with records you already controlled before the email arrived. ## How do I inspect the phone number and links safely? Do not call the phone number in the message to ask whether the message is fake. That connects you to the same party who supplied the claim. The person answering can use the invoice details as a script and may ask for remote access, banking access, card information, or another payment. Use a number printed on your own receipt, service-plan paperwork, card statement, or other record you trust. You can also start from a Best Buy app or website route you already use and locate the current support path there. Do not copy the URL from the email. Preview any link without visiting it. A familiar brand word inside a longer hostname or URL path is not enough to identify the destination. Compare the complete hostname with the site you reached independently. A button label such as "Cancel renewal" can hide a destination the label never shows. If an authorized reviewer needs to inspect a URL, preserve it without opening it. The [phishing link checker](/tools/phishing-link-checker) can review public signals for the destination, but a clean result does not establish that the invoice or support relationship is real. ## How do I verify a Geek Squad charge? Separate three possible records: the plan or purchase, the invoice email, and the payment-account entry. They should agree, but none should be copied from the suspected message. - Search your own email history for the original purchase or plan enrollment, using messages that predate the suspicious renewal. - If you already use a Best Buy account or app, open it through your normal route and look for the plan or purchase evidence it exposes. - Review the card or bank account independently for a matching posted or pending charge. - Ask another authorized household member whether they made the purchase. - Contact support through a number from your own records if the status remains unclear. An email can claim that a charge has occurred when no payment exists. It can also refer to a real-looking plan name that you never bought. If a genuine charge appears, dispute or manage it only through the payment provider and merchant paths you opened independently. Do not read card details to a caller merely because the caller knows the invoice number. The invoice came from the same source and cannot authenticate the person using it. ## How do I report a Geek Squad phishing email? Locate the reporting process documented for the receiving mailbox. If it arrived at work, use the organization's security process and follow its retention or deletion instructions. Do not assume a universal report button or forwarding address. To notify Geek Squad or Best Buy, open the company's site or app independently and locate its current fraud, scam, or support instructions. Do not guess a reporting address and do not use a form or number contained in the suspicious email. A renewal lure may use a different reporting path from a compromised account or fraudulent transaction. Avoid forwarding the invoice attachment to friends or coworkers. If an authorized reviewer needs the message, submit it only through the method that reviewer documents. The [phishing reporting guide](/learning/report-email-phishing-scams) explains what to preserve and how mailbox, brand, payment, and workplace reports serve different purposes. ## What if I already called or allowed remote access? End the call and do not accept further instructions from follow-up callers. If remote-access software was installed or a session was granted, disconnect according to your incident process and contact an authorized security professional. Do not let the original caller "remove" the software or demonstrate that the computer is clean. Use a trusted device for account recovery. Change any password you entered or revealed, review email and financial-account sessions, and remove unknown recovery methods or connected applications. If you logged in to online banking while someone watched or controlled the device, contact the bank through the number on your card or statement. If you paid by card, bank transfer, gift card, or another method, contact that payment provider through an independently verified route. For installed remote-access software, use the applicable device incident process. Handle the mailbox report through its own documented channel. If you only called and shared no information, end contact and block further calls where appropriate. Still report the email. The [recovery guide after a phishing click](/resources-post/what-to-do-if-you-clicked-on-a-phishing-link) covers credential, device, and payment exposure. ## Why did the Geek Squad email reach me? Delivery alone is not a trust mark. Domain authentication can provide evidence about a sending identity, but it does not establish whether you bought a plan, owe an invoice, or reached genuine support. [SPF, DKIM, and DMARC help receiving systems evaluate domain identity](https://www.rfc-editor.org/rfc/rfc9989.html). They cannot check whether you purchased a protection plan, whether an invoice is owed, or whether a phone number belongs to real support. That business context exists in your account, receipts, and payment records. The guide to [why phishing passes SPF and DKIM](/learning/why-do-phishing-emails-pass-spf-and-dkim) explains the difference between authenticated transport and an honest request. Palisade belongs only at that domain-authentication boundary, not in the consumer support or payment decision. ## A safe decision rule for renewal emails Ignore the email's cancellation process. Search for the underlying relationship in records you already possess: the original purchase, the current plan, the merchant account, and the payment account. Use a contact method from those records if you need clarification. If none of the records matches, report the message and leave it unused. If a real charge matches, manage or dispute it through the independently opened merchant and payment-provider routes. If you installed software, exposed credentials, or sent money, complete those recovery paths immediately. This rule works because it does not depend on how accurate the logo, invoice, tax line, or support language appears. It tests the one fact the sender needs you to assume: that a real commercial relationship or charge exists. ## Sources and further reading - [Federal Trade Commission: How to recognize and avoid phishing scams](https://consumer.ftc.gov/articles/how-recognize-avoid-phishing-scams) - [RFC 9989: Domain-based Message Authentication, Reporting, and Conformance](https://www.rfc-editor.org/rfc/rfc9989.html) - [Palisade phishing reporting guide](/learning/report-email-phishing-scams) - [Palisade phishing email examples](/learning/phishing-email-examples) ## Frequently asked questions ### Does a Geek Squad invoice mean my card was charged? No. Check your bank or card account independently. An invoice in an unexpected email is a claim, not evidence that payment occurred. ### Should I call the cancellation number in the email? No. Use a number from your own receipt, plan document, card statement, or an official site you opened independently. ### Can a real subscription renewal still be handled outside the email? Yes. Open the merchant account or app through your normal route and manage the plan there. Do not return to the email button. ### What if the caller installed remote-access software? End the session, follow your device incident process, and use a trusted device for account recovery. Contact financial institutions through verified channels if banking or payment data was visible. ### Is reporting the email enough after I paid? No. Contact the payment provider promptly and preserve transaction evidence. The mailbox report and payment-recovery process solve different problems. --- # Gmail report phishing steps and what happens next Canonical: https://www.palisade.email/learning/gmail-report-phishing > Follow Gmail's current report phishing steps, learn what Google receives, preserve useful evidence, and know when your security team must be involved. On a computer, open the suspicious message in Gmail, choose More next to Reply, then choose Report phishing. Do not click a link, download an attachment, reply, or call a number in the message first. A Gmail report can help Google improve protection, but it does not replace your organization's security process. Preserve the original message when policy requires it, especially after credential, payment, or device activity. ## Quick takeaways - Use Gmail's own More menu, not a link or button inside the suspicious email. - Google's current computer workflow is Open message, More next to Reply, Report phishing. - Google says it receives a copy, including attachments, when mail is manually moved into Spam and may analyze it. - Reporting phishing in Gmail may not satisfy your employer's separate incident-reporting requirement. - If you chose the action by mistake, Gmail also provides Report not phishing from the More menu. This workflow sits in the [email threats hub](/learning/threats). It is deliberately narrower than [Gmail phishing protection](/learning/gmail-phishing-protection), which explains preventive controls rather than the action for one message. ## How do I report phishing in Gmail? ### 1. Stop interacting with the message Leave links, attachments, QR codes, phone numbers, and reply fields alone. A suspicious message may be designed to move you into a site or conversation the sender controls. If you already entered credentials, approved a sign-in, installed software, or sent money, move directly to the incident steps below rather than treating reporting as the complete response. ### 2. Open the message in Gmail on a computer Google's current help instructions specify the computer experience. Open the message so Gmail's message-level controls are available. Do not open an attachment to confirm what it contains. If the organization requires evidence preservation before mailbox actions, follow that policy first. ### 3. Choose More next to Reply Use the More control in Gmail's own interface next to Reply. This matters because a phish may include a graphic that imitates a security or unsubscribe control. Gmail chrome is outside the message body; the sender does not control it. ### 4. Choose Report phishing Select Report phishing and complete Gmail's report flow. Google's help page lists these exact steps and also provides the inverse action, Report not phishing, from the same menu when a message was marked incorrectly ([Google: Avoid and report phishing emails](https://support.google.com/mail/answer/8253?hl=en)). The official page shows the current wording and menu context. ![Official Gmail Help instructions showing More and Report phishing in the computer workflow](/images/editorial/gmail-report-phishing/google-help-report-phishing.png "1728x940") *Source: Current first-party documentation from [Google Gmail Help](https://support.google.com/mail/answer/8253?hl=en), captured August 25, 2026; this is documentation evidence, not an authenticated inbox capture.* After submitting, preserve evidence required by your organization. ## What happens after I report phishing? Google's help page places an important note above the reporting workflow: when a person manually moves an email into the Spam folder, Google receives a copy of the email and any attachments and may analyze them to protect users from spam and abuse ([Google phishing-reporting help](https://support.google.com/mail/answer/8253?hl=en)). Treat that as a disclosure about Google's handling, not a promise about what one report will cause. The page does not promise that Google will remove the message from every mailbox, block the sender everywhere, notify your employer, open a case you can track, or determine criminal intent. Report success in Gmail means the Gmail action completed. Organizational containment and investigation are separate outcomes. For example, suppose a message has this fictional summary: ```text From: Payroll Access Subject: Ticket 630184 expires in 27 minutes Requested action: Scan a QR code and enter Microsoft 365 credentials Recipient: finance-team@example.com ``` Reporting it in Gmail addresses the mailbox-provider channel. The organization may still need ticket `630184`, the original headers, the displayed QR destination, sign-in logs, and confirmation of whether anyone entered credentials. The example uses `.invalid` and `.example` identifiers and does not represent a real campaign. ## Should I report spam or phishing? Use Report phishing when the message deceptively impersonates a person or organization, tries to capture information, or induces a harmful action. Use Report spam for unwanted bulk or abusive email that does not present the same deceptive security claim. The [spam versus phishing guide](/learning/spam-vs-phishing) explains the classification boundary. Google's spam help says reporting spam helps Gmail identify similar mail and that a message marked spam is moved to Spam. It also describes an unsubscribe option for eligible subscription messages ([Google: Report spam in Gmail](https://support.google.com/mail/answer/1366858)). Do not use unsubscribe inside an obviously deceptive email merely to see what happens. A message can be both bulk and phishing. Prioritize the security-reporting path when fraud, credential capture, malware, payment manipulation, or impersonation is present. The label describes the risk you are escalating, not a technical finding that you must prove before reporting. ## What evidence should I preserve? Follow the organization's policy because mailbox content can include personal, financial, customer, or employee data. Useful evidence may include the original message, sender and reply addresses, subject, delivery time, visible destination, attachment names, raw headers, and a short account of any interaction. Do not circulate the message or attachment to colleagues who do not need it. Raw headers can support domain and path analysis. However, RFC 8601 Section 1.2 explains that an `Authentication-Results` field is meaningful only inside the receiver's trust boundary. A sender can insert an untrusted lookalike field ([RFC 8601, Section 1.2](https://www.rfc-editor.org/rfc/rfc8601.html#section-1.2)). That is one reason the guide on [why phishing can pass SPF and DKIM](/learning/why-do-phishing-emails-pass-spf-and-dkim) does not treat a pass result as proof of good intent. Do not take screenshots as the only evidence when the original message remains available. Screenshots can omit addresses, destinations, routing information, and attachments. They can still help show what the user saw, but they serve a different purpose from the original message and receiver-added headers. ## When does the Gmail report not cover the whole incident? A Gmail report also does nothing for the domain being impersonated. If the message forged your own domain, the fix is on the sending side, and the [Palisade email security score](/tools/email-security-score) shows what your published records currently allow. It reads public DNS, so it cannot explain why Gmail treated one particular message as suspicious. A Gmail report is not sufficient when someone entered a password, approved a multi-factor prompt, shared a one-time code, installed software, opened a harmful attachment, changed supplier payment details, transferred money, or used a work device. Contact the authorized security, IT, finance, or fraud team through the established urgent channel. Change credentials through a trusted service surface when directed, and preserve logs and device evidence. The workflow also does not apply exactly as written when you use a third-party mail client, a mobile interface with different controls, an administrator quarantine, or a security product that captures reports through an add-in. Use the organization's supported route. Do not guess that a similar menu transmits the same evidence. If you are unsure whether a message is deceptive, review the [phishing scam email example](/learning/phishing-scam-email-example) without interacting with the suspicious content. You do not need courtroom proof before using a safe internal report channel. ## How do I correct a mistaken report? Google's current computer instructions say to open the message, choose More next to Reply, then choose Report not phishing ([Google Gmail Help](https://support.google.com/mail/answer/8253?hl=en)). Use the message state currently available in the mailbox. If an organizational case was also created, update that case separately so the security team does not treat the Gmail correction as a silent resolution. Do not reverse a correct report merely because the message passed authentication. Attackers can authenticate domains they control, and compromised legitimate accounts can send harmful mail. Correct the classification only when the message and its context have been verified. ## Sources and further reading - [Google: Avoid and report phishing emails](https://support.google.com/mail/answer/8253?hl=en) - [Google: Report spam in Gmail](https://support.google.com/mail/answer/1366858) - [RFC 8601, Authentication-Results](https://www.rfc-editor.org/rfc/rfc8601.html) ## Frequently asked questions ### Can I report phishing in the Gmail mobile app? Only the computer workflow appears on the Google help page cited here. Gmail's mobile apps do expose a reporting control in the message overflow menu, but its label and position differ by app version, so confirm it in your own app rather than following the desktop steps literally. ### Does Gmail tell the sender I reported phishing? Not according to the cited help instructions. They describe Google's receipt and possible analysis of messages moved to Spam, but they do not promise a sender notification or explain enforcement for one report. ### Can I undo a mistaken phishing report? Yes. Google's computer instructions provide Report not phishing in the More menu. If you also opened an internal security case, update that case because changing Gmail's classification does not close another system's workflow. ### Should I delete the email after reporting it? No, not automatically. Follow your organization's evidence-retention policy. A security team may need the original message, headers, attachment metadata, and delivery time before deletion or mailbox cleanup. ### Is reporting phishing the same as blocking the sender? No. Reporting supplies a classification signal and moves the message through Gmail's abuse workflow. It does not establish that every future message using the displayed address will be blocked or that the identity cannot be spoofed. ### Will a Gmail report protect an account after I entered my password? No. Report the message, then use the authorized account-compromise process immediately. Credential changes, session review, device investigation, payment controls, and internal escalation are separate actions. --- # Gmail safe sender list: what Gmail uses instead Canonical: https://www.palisade.email/learning/gmail-safe-sender-list > Gmail has no literal safe sender list. Learn how contacts, Not spam, and a Never send it to Spam filter work, plus when each option is appropriate. Gmail does not have a personal feature literally named **Safe sender list**. To keep wanted mail out of spam, add a known sender to Google Contacts, mark a misplaced message **Not spam**, or create a Gmail filter for the exact address and select **Never send it to Spam**. A filter is the closest match to an Outlook-style safe-sender entry, but it should be narrow and used only for a sender you have verified. ## Quick takeaways - Gmail uses several controls instead of one personal safe-sender list. - **Not spam** corrects a message that Gmail already placed in Spam. - A Google Contact records the sender as someone you know, but it is not a guarantee that every message will reach the inbox. - A **Never send it to Spam** filter is the strongest personal rule for a specific address. - A filter does not prove that a message is genuine or override every organization policy. - For a managed account, an administrator may control mail handling beyond your personal settings. ## What Gmail provides instead of a safe sender list The phrase “safe sender list” usually describes an Outlook control that explicitly trusts an address or domain. Personal Gmail does not present that named list. Its nearest equivalents solve different problems: Contacts records an identity you recognize, **Not spam** corrects a classification, and a filter creates an ongoing mailbox rule. Choose the least forceful control that fixes the problem. If one valid message landed in Spam, start with **Not spam**. If this is a person you genuinely correspond with, add the person to Contacts. If repeated, verified mail from one exact address continues to be classified as spam, create a narrow filter with **Never send it to Spam**. Do not treat any of these choices as proof of identity. A mailbox rule acts on fields such as the visible From address. It does not turn an unauthenticated or impersonated message into a trustworthy one. ## Mark a legitimate Gmail message as Not spam Open Gmail and go to **Spam**. Select or open the wanted message, then choose **Not spam**. Gmail moves the message out of Spam. Google’s current help page for valid mail in Spam is the source to check if the label or placement changes ([Google: Fix issues with valid emails in Spam](https://support.google.com/mail/answer/16457426)). Use this when Gmail has already made the wrong classification. It gives the service a direct correction tied to the message. It is not the same as creating a permanent exception for all mail claiming the same sender address. Before correcting the classification, check that the message is really from the organization or person you expect. Open the service through a saved bookmark or known app when the message asks for a password, payment, private document, or account change. A familiar display name is not enough. ## Add a verified sender to Google Contacts For a person or organization you know, open Google Contacts from the Google apps menu, choose **Create contact**, and save the sender’s exact address. You can also open a Gmail message, point to the sender’s identity card, and use the available contact action when Gmail shows one. Contacts is useful when the address belongs to someone you expect to hear from. It also helps Gmail recognize the relationship, but it should not be described as an absolute delivery rule. Spam classification can still consider the message, its authentication, its content, and account-level or organization-level controls. Copy the address from a message you have independently verified or from the sender’s official site or directory. Do not add an address merely because a message asks to be allowlisted. A phisher can put a familiar name in the display-name field or use a lookalike address. ## Create a Never send it to Spam filter In Gmail on the web, open **Settings**, choose **See all settings**, then open **Filters and Blocked Addresses**. Choose **Create a new filter**. Put the exact verified address in the **From** field, continue with **Create filter**, select **Never send it to Spam**, and create the filter. This is the closest personal Gmail equivalent to a safe-sender entry because it applies a continuing rule to messages that match the filter. It is also the option with the greatest risk if the match is too broad. Prefer a complete address such as `billing@example.com` over a display name or loose text fragment. Gmail’s mobile apps can correct an existing message with **Not spam**, but filter creation is a web-setting task. If you are using a phone, open Gmail on a computer before trying to reproduce the filter path. ![Decision map showing when to use Not spam, Contacts, or a Never send it to Spam filter in Gmail](/images/editorial/gmail-safe-sender-list/gmail-safe-sender-list-control-map.svg "1200x676") *Source: Palisade deterministic control map based on [Google's Gmail spam guidance](https://support.google.com/mail/answer/16457426). It is not a Gmail interface capture.* ## Make the filter narrow enough to be safe Use the **From** field for one verified address whenever possible. Do not create a broad exception for an entire public email service, a common word, or a display name. Such a rule can match unrelated mail and keep it out of Spam. If one organization sends from several legitimate addresses, verify each one through a trusted source and add separate narrow rules only when necessary. A domain-wide rule shifts more risk to the recipient. It is rarely justified for a personal mailbox when an exact address solves the problem. Review the filter after creating it. Return to **Settings**, then **Filters and Blocked Addresses**, find the rule, and check its criteria and action. Remove or edit it when the relationship ends, the sender changes systems, or the rule catches mail you did not intend to trust. ## What a Gmail safe-sender substitute does not do A personal contact or filter changes handling in your mailbox. It does not fix the sender’s SPF, DKIM, or DMARC setup, improve delivery for other recipients, validate links, inspect attachments, or guarantee that a compromised sender account is safe. It also does not create an organization-wide policy. A Google Workspace administrator can apply separate controls for managed accounts, and those controls may outweigh or restrict what a user can do. If the mailbox belongs to an employer or school, ask the administrator before creating an exception for business-critical or sensitive mail. Never use **Never send it to Spam** to work around an unresolved security warning. First verify why the message is being classified and whether the visible From address matches the service’s documented sending address. An exception should follow verification, not replace it. ## If wanted messages still go to Spam Check whether the message is consistently coming from the same exact address. Look for forwarding, mailing-list, or alias behavior that changes the address you need to match. Confirm that the filter is enabled and that another filter is not deleting, archiving, or labeling the message first. Mark each legitimate example **Not spam** rather than dragging it to the inbox without the classification action. Then review your personal filter and blocked-sender settings. The [Gmail spam filter guide](/learning/gmail-spam-filter) explains the sender-side causes that a recipient rule cannot repair. If the message is suspicious, do not allowlist it just to make a warning disappear. Use Gmail’s own reporting control and follow [how to report phishing in Gmail](/learning/gmail-report-phishing). The [Gmail phishing protection guide](/learning/gmail-phishing-protection) explains how to verify a request outside the message. ## Safe sender, block, and report solve different problems A safe-sender substitute keeps verified wanted mail from being classified as spam. Blocking moves later mail from a specific address away from the inbox. Reporting supplies Gmail with a classification about unwanted or deceptive mail. One control is not a substitute for the others. If you need the opposite of allowlisting, use [how to blacklist an email address in Gmail](/learning/how-to-blacklist-an-email-address-in-gmail). Use **Report spam** for unwanted bulk mail and **Report phishing** for deceptive requests involving credentials, money, files, or impersonation. Do not create an allowlist filter for a sender you have already reported as phishing. The safest default is reversible and specific: correct one known message, verify the exact sender, then add a narrow rule only if the problem repeats. ## Sources and further reading - [Google: Fix issues with valid emails in Spam](https://support.google.com/mail/answer/16457426) - [Google: Report spam in Gmail](https://support.google.com/mail/answer/1366858) ## Frequently asked questions ### Does Gmail have a safe sender list? Not as a personal feature with that exact name. Gmail provides Contacts, **Not spam**, and filters. A filter for an exact address with **Never send it to Spam** is the closest ongoing personal rule. ### How do I add a safe sender in Gmail? Verify the exact address, add it to Google Contacts, and correct any valid message in Spam with **Not spam**. If repeated mail still goes to Spam, create a narrow web filter for the exact From address and select **Never send it to Spam**. ### Is adding someone to Contacts enough? No. It can help Gmail understand that you know the sender, but it is not an absolute inbox guarantee. Use **Not spam** to correct an existing message and a narrow filter only when a recurring classification problem remains. ### Can I add a whole domain as a safe sender? Yes, but a domain-wide Gmail filter is riskier than an exact-address rule. It can match more mail than intended. Use exact verified addresses unless an administrator has assessed a legitimate organizational need. ### Can I create the filter in the Gmail mobile app? No. Use Gmail on the web to create and review filters. The mobile app can mark an existing message **Not spam**, but it does not expose the same filter-creation settings. ### Why did Gmail still put an allowlisted message in Spam? The address may not match the filter, the sender may have changed addresses, another rule may affect the message, or an organization-level control may apply. Verify the message first, then review the exact filter criteria and ask the administrator when the account is managed. --- # Gmail SMTP settings: ports, auth, and alignment Canonical: https://www.palisade.email/learning/gmail-smtp-settings > Compare Google's three Gmail and Workspace SMTP methods, pick the right authentication model for your device, and verify SPF, DKIM, DMARC, and delivery. Google Workspace documents three device and app sending methods. Use the SMTP relay service at `smtp-relay.gmail.com` for administrator-controlled sending, the Gmail SMTP server at `smtp.gmail.com` when one mailbox can authenticate, or the restricted Gmail SMTP server at `aspmx.l.google.com` for mail addressed only to Gmail or Google Workspace recipients. [Google documents the three options and their different requirements](https://knowledge.workspace.google.com/admin/gmail/send-email-from-a-printer-scanner-or-app?hl=en). After a test connects, validate the visible From domain, SPF, DKIM, DMARC, and actual delivery. ## Quick takeaways - Google recommends the SMTP relay service for devices and apps; it authenticates messages by IP address and can send inside or outside the organization. - The Gmail SMTP server authenticates with a complete Gmail or Google Workspace address and an account-approved credential. - The restricted Gmail SMTP server uses no SMTP authentication and can send only to Gmail or Google Workspace recipients. - Google documents a `2,000`-message daily limit for the authenticated Gmail SMTP server in this device and app workflow. - Never copy another tenant's DKIM value; Google generates an account-specific TXT record. - A successful SMTP send does not prove DMARC alignment or inbox placement. This guide is part of Palisade's [ESP setup hub](/learning/esp-setup). SMTP sends mail; IMAP and POP retrieve it. The [IMAP versus SMTP guide](/learning/difference-between-imap-and-smtp) covers that protocol boundary. ## What should I check before configuring Gmail SMTP? Confirm whether the sender is a personal Gmail account or managed Google Workspace tenant, whether it must reach recipients outside Gmail and Google Workspace, and whether the application can use account credentials, a stable public IP address, TLS, or only unauthenticated port `25`. Record the visible From address, expected daily volume, message type, and whether users need to send as another address. Google's current device and app instructions name three methods: the SMTP relay service, the Gmail SMTP server, and the restricted Gmail SMTP server. They recommend relay for Google Workspace devices and apps, list `smtp.gmail.com` with the complete email address and an app password for the authenticated mailbox workflow, and reserve `aspmx.l.google.com` for messages addressed only to Gmail or Google Workspace users ([Google: Send email from a device or app](https://knowledge.workspace.google.com/admin/gmail/send-email-from-a-printer-scanner-or-app?hl=en)). An app password requires 2-Step Verification and may be unavailable under account or organization policy. Do not weaken account policy simply to make an old client connect. Estimate volume before testing. The same Google page documents a `2,000`-message daily limit for the Gmail SMTP server and explains that SMTP relay has its own limits. These are vendor limits for the described methods, not a safe bulk-mail target or a promise of inbox delivery. ## Which setup method should I use? Use Google's three methods this way: - **SMTP relay service (recommended):** Use `smtp-relay.gmail.com` on port `25`, `465`, or `587`. Google authenticates messages by IP address, so the administrator must configure relay policy and may need a static public IP address. Pick it for managed devices or applications that need to send inside and outside the organization. Google documents up to `10,000` recipients per user per day for this option. - **Gmail SMTP server:** Use `smtp.gmail.com` with TLS on port `587` or SSL on port `465`, then authenticate with the complete Gmail or Google Workspace address and an account-approved credential. Pick it when one application sends as one mailbox. Google documents a `2,000`-message daily limit for this option. - **Restricted Gmail SMTP server:** Use `aspmx.l.google.com` on port `25`. It does not require SMTP authentication or TLS, but it can send only to Gmail or Google Workspace recipients. Google instructs administrators to verify and allowlist the device or application IP address. Pick it only for older devices that cannot meet the other methods' authentication or TLS requirements and do not need to reach other recipients. These settings and limits come from [Google Workspace Admin Help](https://knowledge.workspace.google.com/admin/gmail/send-email-from-a-printer-scanner-or-app?hl=en). Do not swap endpoints while leaving the surrounding authentication, recipient, and policy assumptions unchanged. Google's current documentation separates the choices and their values. ![Official Google documentation comparing SMTP relay, Gmail SMTP server, and restricted Gmail SMTP server settings](/images/editorial/gmail-smtp-settings/google-smtp-settings-docs.png "1050x1750") *Source: Current first-party configuration documentation from [Google Workspace Admin Help](https://support.google.com/a/answer/176600?authuser=2&hl=en), captured August 25, 2026; this is documentation evidence, not an authenticated settings screen.* Choose the method from the account and sending pattern, not the port alone. If the software supports a current Google OAuth flow, use the product's official Google integration instructions rather than translating an app-password example into OAuth parameters. OAuth clients, scopes, consent, and tokens are account-specific and are outside a generic host-and-port table. ## How do I configure the Gmail SMTP server? ### 1. Fix the test identity and scope Use one controlled mailbox and one visible From address. For a worked example, suppose the application sends from `alerts@example.com`, authenticates as `alerts@example.com`, sends fewer than `300` transactional notices per day, and will deliver one test to a Gmail recipient and one mailbox the organization controls. Do not start with a production mailing list. ### 2. Enter the endpoint and transport values For authenticated submission, enter host `smtp.gmail.com`, port `587`, and STARTTLS or the client's equivalent TLS-upgrade setting. If the client specifically requires implicit SSL, use port `465`. Require authentication and enter the full account address as the username. Do not use port `25` for this worked authenticated-submission example. ### 3. Use an approved account credential Follow the account's current authentication policy. If Google and the application explicitly support an app password, create it for that application after 2-Step Verification is enabled and store it as a secret. Never paste a normal Google password into an unsupported device, commit an app password to a repository, or include it in a screenshot. If policy blocks the method, stop and select a supported integration or relay design. ### 4. Authorize the visible sender Keep the authenticated mailbox and visible From address the same for the first test. A different From identity may require a verified alias, delegation, relay policy, or application-specific authorization. A `235` authentication success or SMTP `250` acceptance does not grant Send As permission for an arbitrary domain. ### 5. Send one traceable message Use a subject such as `SMTP validation 2026-08-25 14:30 UTC` and include a non-secret run identifier such as `gmail-smtp-630184`. Record the application time, endpoint, port, From, recipient, and server response. Do not include credentials or customer data in the record. ## How does this setup affect DMARC? SMTP authentication answers whether the application may use Google's submission service. DMARC answers whether an authenticated domain aligns with the domain in the visible From address. They are different controls. If Google Workspace is the only sender for `example.com`, Google's SPF instructions give `v=spf1 include:_spf.google.com ~all` as the starting record ([Google Workspace SPF setup](https://support.google.com/a/answer/33786?hl=en-eu)). A domain with other senders must build one combined SPF policy within the lookup budget instead of publishing a second SPF record. Google Workspace DKIM uses a tenant-generated TXT value. Google's setup flow offers a `2048`-bit key by default and documents selector `google` as the default. Copy the account-generated hostname and value from your Admin console. Never reuse the example value or another account's key. Google notes that a newly activated Gmail tenant may need `24` to `72` hours before a DKIM key can be generated ([Google Workspace DKIM setup](https://support.google.com/a/answer/174124?hl=en-IE)). The current vendor-published workflow shows where the tenant generates the record. ![Google documentation showing the Admin console DKIM generate-record workflow and account-specific record fields](/images/editorial/gmail-smtp-settings/google-dkim-workflow-docs.png "1100x2050") *Source: Current first-party workflow documentation from [Google Workspace Admin Help](https://support.google.com/a/answer/174124?hl=en-IE), captured August 25, 2026; the embedded console panel is a Google schematic, not an authenticated tenant capture.* Use account-generated values. Do not copy the schematic's sample record. RFC 9989 defines relaxed and strict alignment for DKIM and SPF. DMARC passes when at least one supported mechanism authenticates and its identifier aligns with the RFC5322 From domain ([RFC 9989, Section 4.4](https://www.rfc-editor.org/rfc/rfc9989.html#section-4.4)). A Google-signed message can therefore be accepted by SMTP yet fail DMARC for `example.com` if neither the DKIM signing domain nor the SPF-authenticated domain aligns. ## How do I validate the setup? ### Check DNS values Query the SPF, DKIM selector, and `_dmarc.example.com` records from more than one public resolver. Compare the exact tenant-generated DKIM hostname and value. DNS presence alone does not prove Google is signing the test message. ### Check vendor status In the Google Admin console, confirm that the intended domain shows DKIM authentication enabled after DNS is published. Google's instructions say to use Start authentication and describe the status `Authenticating email with DKIM` ([Google DKIM validation](https://support.google.com/a/answer/174124?hl=en-IE)). Labels can change, so use current tenant guidance rather than a remembered screenshot. ### Check the delivered message headers Open the raw source of the controlled message and locate the receiver-added `Authentication-Results`. RFC 8601 Section 1.2 explains why a field added outside the receiver's trust boundary is not authoritative ([RFC 8601, Section 1.2](https://www.rfc-editor.org/rfc/rfc8601.html#section-1.2)). Confirm `spf=pass`, `dkim=pass`, and `dmarc=pass`, then compare `smtp.mailfrom`, `header.d`, and `header.from` rather than reading pass tokens alone. Use Palisade's [Email Header Analyzer](/tools/email-header-analyzer) to parse headers you supply; it cannot test the credential or guarantee placement. ### Check DMARC reporting and delivery Confirm that the authorized Google source appears in aggregate DMARC data for the From domain and that unexpected sources do not increase after launch. Then compare Gmail delivery and placement for the intended traffic. Google requires SPF or DKIM for all senders to personal Gmail accounts and SPF, DKIM, and DMARC for senders over `5,000` messages per day to Gmail accounts under its current guidelines ([Google email sender guidelines](https://support.google.com/mail/answer/81126?hl=en)). If the one-message test passes but the team still cannot see every production source, Palisade's DMARC Agent can organize aggregate DMARC evidence across the domain. Smart DNS Deployment can write only DNS changes a human has approved. It does not configure Google credentials, test an unsent application, or guarantee placement. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=esp_setup&utm_content=gmail-smtp-settings) after the controlled header test establishes that ongoing visibility is the remaining problem. ## Troubleshooting ### Authentication is rejected Confirm the full account address, approved credential type, 2-Step Verification and app-password eligibility, and any Workspace policy. Do not repeatedly retry a locked or policy-blocked credential. ### TLS negotiation fails Match port `587` with STARTTLS and port `465` with implicit SSL. Update a client that cannot support the required transport security rather than disabling certificate or TLS verification. ### The message sends but DMARC fails Compare the visible From domain with `header.d` and `smtp.mailfrom`. Repair signing, alias authorization, or sender configuration at the actual source. The [Gmail authentication guide](/learning/authenticate-email-for-gmail) covers DNS controls. ### The server accepts mail but delivery degrades Check rate and daily limits, complaints, sending changes, and Google Postmaster evidence. Server acceptance is not a placement promise. Do not rotate ports or rewrite content randomly while leaving the sending source unexplained. ## When does this setup not apply? The worked procedure covers the authenticated Gmail SMTP server. This guide compares the relay and restricted methods, but it does not provide a complete tenant relay-policy deployment, generic unauthenticated direct-to-MX delivery, high-volume marketing architecture, inbound Gmail settings, or consumer account recovery. A device that cannot meet the authenticated method's policy may need the administrator-controlled relay or the restricted internal-recipient path, not a weaker Gmail account. ## Sources and further reading - [Google device and app SMTP options](https://support.google.com/a/answer/176600?authuser=2&hl=en) - [Google Workspace SPF setup](https://support.google.com/a/answer/33786?hl=en-eu) - [Google Workspace DKIM setup](https://support.google.com/a/answer/174124?hl=en-IE) - [Google email sender guidelines](https://support.google.com/mail/answer/81126?hl=en) - [RFC 9989, DMARC](https://www.rfc-editor.org/rfc/rfc9989.html) - [RFC 8601, Authentication-Results](https://www.rfc-editor.org/rfc/rfc8601.html) ## Frequently asked questions ### Is smtp.gmail.com the Gmail SMTP host? Yes. Google documents `smtp.gmail.com` for authenticated Gmail SMTP submission. Google Workspace SMTP relay uses the separate host `smtp-relay.gmail.com` and an administrator-controlled configuration. ### Should I use port 587 for Gmail SMTP? Yes, when the client supports STARTTLS. Google also documents port `465` for SSL. Match the security mode to the port instead of trying both without recording the result. ### Can I use my normal Google password for SMTP? No, not as a generic workaround. Use the authentication method allowed by the account, organization, and application. An app password requires eligible 2-Step Verification, while supported OAuth integrations have their own account-specific setup. ### What are the three Google Workspace SMTP options? Google names them the SMTP relay service, Gmail SMTP server, and restricted Gmail SMTP server. Relay uses administrator policy and IP-based authentication. The Gmail SMTP server uses a mailbox credential. The restricted server has no SMTP login but can address only Gmail or Google Workspace recipients. ### Does a successful Gmail SMTP login make DMARC pass? No. SMTP login authorizes submission. DMARC requires an SPF or DKIM authenticated identifier to align with the visible From domain on the delivered message. ### Can personal Gmail use Google Workspace SMTP relay? No. The relay service is a Google Workspace administrator feature. A personal Gmail account should use a supported Gmail account submission method and remain within that account's current policy and limits. --- # Gmail spam filter: what senders can control Canonical: https://www.palisade.email/learning/gmail-spam-filter > Gmail weighs authentication, reported spam, reputation, subscription practices, content, and sending behavior. You control the records, not the verdict. Gmail's spam filter is not a published formula that a sender can score or switch off. A legitimate sender can still diagnose controllable evidence: SPF, DKIM, and DMARC results; complaint rate; domain and IP reputation; consent and unsubscribe practices; sending changes; transport errors; and the result of a comparable retest. The useful goal is to isolate one supported cause, not to guess which word triggered a private classifier. ## Quick takeaways - Gmail does not publish the weights or complete rules used by its spam systems. - Google recommends keeping the user-reported spam rate below 0.10% and avoiding 0.30% or higher. - Passing authentication is necessary for many senders, but it does not guarantee inbox placement. - Diagnose DNS, a delivered message, Postmaster data, and the same sending path in that order. - Change one cause at a time so the retest can tell you something. This is a sender-side operating guide in the [email deliverability hub](/email-deliverability). If you are asking whether one message disappeared, start with [Is Gmail filtering my emails?](/learning/is-gmail-filtering-my-emails). If it arrived under Promotions, use the [Gmail Promotions tab guide](/learning/why-emails-land-in-gmail-promotions-tab); Promotions is not Spam. ## What does the failure mean? Spam placement means Gmail accepted a message and classified it away from the inbox for that recipient. A temporary or permanent SMTP rejection is a different outcome. Google also says its systems consider signals including authentication, reported spam, reputation, subscription practices, content, and sending behavior, but it does not publish a deterministic filter recipe ([Google email sender guidelines](https://support.google.com/mail/answer/81126?hl=en)). Work at the right unit. One recipient moving a wanted message to Spam is not the same as a stream-wide change across hundreds of recipients. One clean header does not prove the rest of a campaign used the same path. Compare the same visible From domain, return path, DKIM signing domain, sending IP, recipient population, content type, and time window. ## What usually causes it? ### Authentication or alignment does not match the stream SPF can pass for the bounce domain while DKIM signs with another domain. DMARC passes only when at least one authenticated identifier aligns with the visible From domain, as specified in RFC 9989 Section 4.4 (identifier alignment) and Section 4.1 (the DMARC pass condition) ([RFC 9989](https://www.rfc-editor.org/rfc/rfc9989.html#section-4.4)). A forwarding path can also change SPF behavior. Diagnose the delivered message rather than assuming the public records describe what was sent. ### Recipients report messages as spam Google's current guidance recommends a spam rate below 0.10% and says senders should avoid reaching 0.30% or higher. Its FAQ defines a bulk sender as a primary domain that sends close to 5,000 or more messages to personal Gmail accounts in 24 hours, and says that classification does not expire once assigned ([Google sender-guideline FAQ](https://support.google.com/mail/answer/14229414?hl=en)). These are Google thresholds, not universal Internet limits. ### Reputation or volume changes abruptly A new domain, new IP, dormant list, sudden volume increase, or unexpected traffic source changes the evidence Gmail sees. A compromised credential can create the same pattern. Do not treat a volume drop as the repair before checking who sent, through which system, and with what authorization. ### Consent, unsubscribe, or targeting is weak Recipients who did not expect a message are more likely to report it. Google requires one-click unsubscribe for marketing and subscribed mail from bulk senders and expects unsubscribe requests to be honored promptly under its current guidelines. Transactional mail should not be padded with unrelated promotional content just to reuse a stream. ### Content and destinations contradict the identity Misleading display names, link domains unrelated to the visible sender, URL shorteners, attachment-heavy bursts, or a message that imitates another organization can create risk even when authentication passes. There is no reliable list of forbidden words. Evaluate the complete request and destination. ## How do I diagnose the failure? Start with reproducible evidence. ![Four-layer Gmail spam placement diagnostic ladder from DNS through a same-path retest](/images/editorial/gmail-spam-filter/gmail-evidence-ladder.svg "1200x676") *Source: Palisade deterministic workflow based on [Google Postmaster Tools dashboards](https://support.google.com/mail/answer/14668346?hl=en-GB).* Run the steps in order before changing anything. ### 1. Define the affected cohort Record the visible From domain, campaign or message type, sending system, time window, approximate Gmail volume, and observed outcome. Separate personal Gmail recipients from Google Workspace recipients because the published bulk-sender thresholds refer to personal Gmail accounts. Keep recipient addresses and message bodies redacted in shared notes. ### 2. Inspect one representative delivered message Obtain raw headers from a message that reached Spam. Read the receiver-added `Authentication-Results`, `DKIM-Signature`, `Return-Path`, and relevant `Received` fields. RFC 8601 Section 1.2 warns that an authentication header is meaningful only inside the receiver's trust boundary, so do not accept a lookalike field inserted by the sender ([RFC 8601, Section 1.2](https://www.rfc-editor.org/rfc/rfc8601.html#section-1.2)). Use Palisade's [Email Header Analyzer](/tools/email-header-analyzer) to parse headers you supply; it cannot expose Gmail's private score. ### 3. Compare Google Postmaster evidence For domains with enough traffic, Google documents dashboards for spam rate, IP and domain reputation, authentication, encryption, and delivery errors ([Postmaster Tools dashboard definitions](https://support.google.com/mail/answer/14668346?hl=en-GB)). Compare the incident period with a normal baseline. Missing data can mean the domain did not meet a dashboard's data threshold; it is not automatically a clean result. ### 4. Trace changes and unauthorized sources Compare deployment, list-source, sending-domain, IP, authentication, and volume changes against the first affected time. Use DMARC aggregate data to look for unexpected sources using the From domain. Preserve the timeline before rotating credentials or editing DNS. ### 5. Form one cause statement Write a falsifiable statement such as: "The `news.example` stream moved from 8,000 to 42,000 Gmail recipients on August 19, while its Postmaster spam rate rose from 0.04% to 0.20%." The concrete calculation is `96 / 48,000 x 100 = 0.20%` if the dashboard period shows 96 user reports across 48,000 delivered messages. Use the dashboard's own definitions rather than inventing counts it does not expose. ## How do I fix it? ### Repair authentication at the actual source If the delivered message fails or misaligns, correct the authorized sending source, return path, or DKIM signing configuration. Use [Authenticate email for Gmail](/learning/authenticate-email-for-gmail) for the DNS and signing workflow. Do not relax DMARC policy merely to make an unrelated identifier pass. ### Stop unwanted or unexplained traffic Pause a compromised or unapproved source, rotate the affected credential through its authorized owner, and remove recipients whose consent cannot be demonstrated. Preserve logs and establish a rollback before changing production systems. ### Restore predictable subscription behavior Separate transactional and marketing intent, make sender identity clear, honor unsubscribe, and reduce sharp volume changes while the underlying list and authorization problem is corrected. Lower volume is not a substitute for valid consent. ### Correct misleading content or destinations Use domains and links the recipient can recognize and verify. Remove false urgency and avoid hiding the real destination. Do not rewrite copy randomly while leaving a compromised source or misalignment unresolved. ## How do I validate the repair? Repeat the affected sending path with the same From domain, message class, authentication path, and a comparable Gmail cohort. Confirm the new header results first. Then watch Postmaster authentication, spam-rate, reputation, and delivery-error evidence over an appropriate volume and time window. Google does not publish a universal recovery period, so report the observations and dates rather than promising a number of days. A fair retest changes one diagnosed cause. If SPF or DKIM now aligns but placement does not improve, keep the authentication repair and continue with consent, reputation, traffic-source, and content evidence. Do not undo a valid security control because another layer still needs work. If the repair exposes several authorized and unknown sources using the domain, Palisade's DMARC Agent can organize aggregate DMARC evidence across those streams. Smart DNS Deployment can write only DNS changes a human approves. It cannot reveal Gmail's private classifier or guarantee inbox placement. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=deliverability&utm_content=gmail-spam-filter) after the same-path retest shows that cross-source monitoring is the remaining gap. ## When does this not apply? This workflow does not apply to a consumer trying to train their own inbox, to a single missing message with no sender access, or to Promotions placement. It also cannot explain Gmail's private model or guarantee a particular folder. A clear SMTP rejection should be diagnosed from its exact enhanced status code before using a spam-placement workflow. ## Sources and further reading - [Google email sender guidelines](https://support.google.com/mail/answer/81126?hl=en) - [Google sender-guideline FAQ](https://support.google.com/mail/answer/14229414?hl=en) - [Google Postmaster Tools dashboards](https://support.google.com/mail/answer/14668346?hl=en-GB) - [RFC 9989, DMARC](https://www.rfc-editor.org/rfc/rfc9989.html) - [RFC 8601, Authentication-Results](https://www.rfc-editor.org/rfc/rfc8601.html) ## Frequently asked questions ### Does Gmail publish a spam-word list? No. Google does not publish a universal list that determines placement. Evaluate authentication, consent, reputation, traffic changes, destinations, and the actual request rather than swapping words until one test reaches the inbox. ### Is the Promotions tab the same as Spam? No. Promotions is an inbox category, while Spam is a separate classification. Diagnose the observed destination before changing anything because category placement and spam placement answer different recipient and sender questions. ### Should my Google Postmaster spam rate be below 0.10%? Yes. Google currently recommends staying below 0.10% and avoiding 0.30% or higher. Those figures are Google sender-guideline thresholds and should be read with the dashboard's scope and traffic qualifications. ### Can SPF and DKIM guarantee Gmail inbox placement? No. Authentication establishes technical identity evidence; it does not prove consent, reputation, useful content, or recipient engagement. Passing and aligned results remove one class of failure but do not control Gmail's final classification. ### Will Gmail placement recover immediately after a repair? No. Google does not publish one recovery time for every cause. Retest the same path, record message-level authentication, and monitor the relevant Postmaster period without making several unrelated changes at once. --- # How do I avoid phishing emails and what habits keep me safer? Canonical: https://www.palisade.email/learning/how-to-avoid-phishing-emails > Verify every urgent request through a channel the message did not supply, keep MFA on every account, and report suspicious mail rather than deleting it. To avoid phishing emails, do not let the message control how you verify it. Pause on unexpected requests, inspect the full sender and destination, then open the claimed service through a bookmark, app, typed address, or known contact route. Keep passwords and one-time codes out of email-driven conversations. Report suspicious messages through your provider or organization, and switch to recovery steps immediately if you already clicked, signed in, opened a file, or paid. ## Quick takeaways - Verify the request outside the message before acting. - Treat urgency as a reason to pause, not proof of fraud by itself. - Check the full address and real destination, not the display name or logo. - Never share a password or one-time code because an email asks. - Use the normal reporting route instead of replying or testing a suspicious link. - If you interacted, contain the account, device, or payment risk first. ## Why recognition starts with the requested action Phishing is defined by deception and the action the sender wants, not by bad grammar or one visual clue. The National Institute of Standards and Technology describes phishing as deceptive communication intended to obtain sensitive information or induce an unsafe action ([NIST phishing guidance](https://www.nist.gov/itl/smallbusinesscyber/guidance-topic/phishing)). Read the message as a request. Is it asking you to sign in, send money, change payment details, open a file, scan a QR code, call a number, approve a prompt, share personal information, or bypass a normal process? That request tells you what needs independent verification. A polished message can be malicious. A clumsy message can be legitimate. Logos, signatures, conversation history, and familiar writing are context, not proof. A compromised real account may have authentic history and a valid sender address. A lookalike domain may be one character away from the real one. The useful question is not "Does this look professional?" It is "Can I confirm this request without using the path the message supplied?" ## Verify the claim outside the email The Federal Trade Commission advises people to contact the supposed organization using a website or phone number they know is real, rather than contact details in an unexpected message ([FTC phishing guidance](https://consumer.ftc.gov/articles/how-recognize-avoid-phishing-scams)). Apply that rule literally. If the message claims there is an account problem, open the provider's app or type its address yourself. If it claims a purchase, compare the claim with independently opened order or transaction history. If a colleague requests a payment change, call them on a known number or use an established business process. If a bank appears to contact you, use the number on your card or statement. Do not return to the email after finding a real issue. A genuine account alert can coexist with a fake email that guessed or reused public information. Continue inside the trusted app, site, or conversation you opened yourself. Use this compact decision record when the request matters: ```text Claim in the message: account, payment, file, login, or business change Requested action: what the sender wants you to do Independent route: app, typed site, known phone, or existing conversation Verified event: found, not found, or still uncertain Next action: continue in trusted route, report, or escalate ``` ## Inspect addresses and destinations without trusting them alone Expand the full sender address. Compare the domain with one you already know belongs to the organization. Watch for extra words, substituted letters, unexpected subdomains, and reply addresses that differ from the visible From address. Inspect the actual link destination without visiting it when the mail client exposes that information. The visible text can name a trusted site while the destination belongs elsewhere. A padlock or `https` only describes the connection to the destination; it does not establish that the destination is the organization named in the email. These checks find contradictions. They do not prove safety. A real account can be compromised, and an attacker can register a plausible domain with a valid encrypted connection. Independent verification remains the decision point. ![Decision flow moving from a suspicious request to an independent route, verified event, and safe next action](/images/editorial/how-to-avoid-phishing-emails/how-to-avoid-phishing-emails-verification-flow.svg "1200x676") *Source: Palisade deterministic workflow based on [FTC phishing guidance](https://consumer.ftc.gov/articles/how-recognize-avoid-phishing-scams) and [NIST phishing guidance](https://www.nist.gov/itl/smallbusinesscyber/guidance-topic/phishing).* ## Protect the accounts a phish is trying to reach Use a unique password for each important account and store it in a reputable password manager. A password manager also adds friction on a lookalike site because it should not offer the saved credential for a different domain. Do not override that mismatch simply because the page looks familiar. Turn on multi-factor authentication. Prefer a phishing-resistant method such as a passkey or hardware security key when the service offers it. Codes and approval prompts are still sensitive. Never read a code to someone who contacted you or approve a sign-in you did not start. Keep recovery email addresses, phone numbers, backup codes, and trusted devices current. Protect the email account especially carefully because password resets for other services often arrive there. Review unexpected recovery or sign-in alerts through the account's security area, not the alert link. Account protection limits damage when a message gets through, but it does not make a request legitimate. A second factor is strongest when you refuse to approve an event you did not initiate. ## Handle attachments, QR codes, and phone numbers carefully An attachment can be harmful even when its filename resembles an invoice, scan, voicemail, or shared document. Do not open an unexpected file to determine whether it is safe. Verify with the sender through a separate route first, and use the organization's approved analysis process for work messages. A QR code is a link that hides its destination from the normal hover check. Do not scan one from an unexpected message merely to inspect it. A phone number can also keep you inside the attacker's channel. Search results and caller ID can be manipulated, so use contact information from a statement, card, official app, or known directory. CISA advises recipients not to click links or open attachments in suspicious messages and to report them through a trusted process ([CISA phishing guidance](https://www.cisa.gov/secure-our-world/recognize-and-report-phishing)). That same restraint applies to unsubscribe links in a message you believe is deceptive. ## Build habits that work when the message feels urgent Phishing often creates a deadline because speed reduces verification. Use a personal rule that high-impact requests slow down. Payment changes, password resets, payroll updates, gift-card purchases, recovery-code requests, and requests to install software should always move to a second channel. For work, learn the organization's exact reporting and urgent-escalation routes before an incident. Know who owns suspicious payment requests, account access, endpoint security, and mail investigation. A reporting button helps only when people know what happens after they use it. Do not shame someone who reports after clicking. Fast disclosure gives the response team a better chance to revoke a session, stop a payment, isolate a device, or remove related messages. A culture that punishes mistakes teaches people to hide the evidence. Mailbox controls reduce exposure but belong to a separate task. Use [how to block phishing emails](/learning/how-to-block-phishing-emails) when you need filters and rules. For one Microsoft client workflow, see [how to report phishing in Outlook](/learning/how-to-report-a-phishing-email-in-outlook) and [Microsoft's documentation of the built-in Report button](https://learn.microsoft.com/en-us/defender-office-365/submissions-outlook-report-messages). If the destination is unclear, use [where to send a phishing email](/learning/report-email-phishing-scams) or the broader [phishing-reporting decision guide](/learning/report-email-phishing-scams). ## What to do if you already interacted Stop interacting and record what happened. The response depends on the action, not on whether you have proven the message was malicious. If you entered a password, change it through the real service and review sessions, recovery details, and security events. If you shared a one-time code or approved a prompt, treat the account as exposed even if the password was not typed. If you opened a file or installed software on a work device, contact the security team and avoid destroying evidence. If you sent money or changed bank details, contact the financial institution through a trusted route immediately. Report the message after starting containment. The FTC points people who disclosed personal information to IdentityTheft.gov and accepts fraud reports at ReportFraud.ftc.gov ([FTC phishing guidance](https://consumer.ftc.gov/articles/how-recognize-avoid-phishing-scams)). Your employer, bank, service provider, insurer, or local authority may have a separate process for the specific loss. ## Sources and further reading - [NIST: Phishing guidance for small businesses](https://www.nist.gov/itl/smallbusinesscyber/guidance-topic/phishing) - [FTC: How to recognize and avoid phishing scams](https://consumer.ftc.gov/articles/how-recognize-avoid-phishing-scams) - [CISA: Recognize and report phishing](https://www.cisa.gov/secure-our-world/recognize-and-report-phishing) - [Microsoft: Report suspicious email messages with the Report button in Outlook](https://learn.microsoft.com/en-us/defender-office-365/submissions-outlook-report-messages) ## Frequently asked questions ### What is the safest first response to a suspicious email? The safest first response to a suspicious email is to stop and verify the claim outside the message. Open the service through a bookmark, app, or typed address, or contact the person through a known channel. Do not use the email's link, attachment, phone number, reply address, or QR code for that verification. ### Can good spelling mean an email is legitimate? No. Good spelling does not make an email legitimate, because writing quality is not an identity check. Treat spelling and layout as weak context, then inspect the request, full address, real destination, and independently verified event. A professional message can still be deceptive. ### Should I reply to ask whether the email is real? No. A reply keeps you in a channel the sender may control. Contact the person or organization through an address, account, phone number, or conversation you already trust. ### Does multi-factor authentication stop every phishing attempt? No. It can reduce account takeover, especially when the method is phishing resistant, but people can still be tricked into sharing codes, approving prompts, opening files, or sending money. Verify the request before using any authentication factor. ### What if I clicked but did not enter information? Close the page and do not download or approve anything. Review the relevant account and device through trusted surfaces. For a work device, report the event because security staff may need the URL, time, browser evidence, or endpoint logs even when no credential was entered. --- # How do I blacklist an email address in Gmail? Canonical: https://www.palisade.email/learning/how-to-blacklist-an-email-address-in-gmail > Use Block Sender to route one address to spam, or a filter to delete it on arrival. Blocking one address will not stop a spoofer who rotates addresses. To blacklist an email address in Gmail, open a message from the sender, open the message’s **More** menu, choose **Block “sender”**, and confirm. Gmail calls the action **Block**, not blacklist, and later mail from that address is directed to Spam. Use a delete filter when you need a stricter rule, and report spam or phishing when the message itself should be classified for Google. ## Quick takeaways - Gmail’s personal control is named **Block**, not blacklist. - Blocking acts on the sender address shown by Gmail and routes later messages to Spam. - A filter can automatically delete mail that matches an exact address. - **Report spam** and **Report phishing** send a classification; Block is a personal mailbox rule. - One blocked address will not stop a sender who changes addresses or domains. - If the mail is threatening, fraudulent, or tied to account access, preserve evidence before cleanup. ## What blacklist means in Gmail People use “blacklist” to mean several different actions: stop a sender from appearing in the inbox, delete matching mail automatically, report abuse, or prevent an organization from accepting a sender. Personal Gmail does not combine those outcomes in one blacklist screen. The built-in **Block** action is the closest answer for one address. A filter is more forceful because it can delete matching messages. **Report spam** and **Report phishing** are classification actions. A managed Google Workspace account can also be subject to administrator controls that are separate from personal Gmail settings. Pick the action from the outcome you want. Do not use a broad filter merely because the word blacklist sounds stronger. ## Block an address from an open Gmail message Open a message from the address you want to block. In the message header, open **More**, the menu shown with three vertical dots, then choose **Block “sender”** and confirm. On Gmail’s mobile apps, open the message and use the sender-specific More menu rather than the app-wide menu. After you block the address, later messages from it are sent to Spam. The current message does not become evidence of phishing merely because you blocked it. If it is unwanted or deceptive, use the appropriate report action as well. Check the full address before confirming. Gmail displays a friendly sender name prominently, but two messages with the same display name can come from different addresses. Blocking `notices@example.com` does not block a lookalike address or every address used by the same person. ## Use a filter to delete mail from an exact address If sending future matches to Spam is not strict enough, create a Gmail filter. In Gmail on the web, open **Settings**, choose **See all settings**, then **Filters and Blocked Addresses**. Choose **Create a new filter**, put the complete address in **From**, continue, select **Delete it**, and create the filter. This rule sends matching future messages to Trash instead of leaving them in the inbox or Spam. Use it cautiously. Trash is easier to overlook, and an overly broad match can hide legitimate mail. Prefer an exact address. Do not filter on a common display name, company word, or public mail domain. If a harasser or scammer rotates addresses, a broad personal rule can create more false matches without solving the underlying problem. ## Block, filter, report spam, or report phishing? Use **Block** when you do not want later messages from one address in the inbox. Use a delete filter when exact matching mail should go to Trash. Use **Report spam** for unsolicited or unwanted bulk mail. Use **Report phishing** when the sender is impersonating someone or trying to obtain credentials, money, files, codes, or another unsafe action. Google documents its spam-reporting control and what to do with incorrectly classified mail in its Gmail help pages ([Google: Report spam in Gmail](https://support.google.com/mail/answer/1366858); [Google: Fix issues with valid emails in Spam](https://support.google.com/mail/answer/16457426)). Reporting and blocking can both be appropriate for the same message because they have different jobs. Do not click an unsubscribe link in a message you believe is phishing. Report it through Gmail’s interface. For legitimate commercial mail, the service’s normal unsubscribe control may be more suitable than blocking. ![Decision map separating Gmail Block, delete filters, Report spam, and Report phishing](/images/editorial/how-to-blacklist-an-email-address-in-gmail/how-to-blacklist-an-email-address-in-gmail-control-map.svg "1200x676") *Source: Palisade deterministic control map based on [Google's Gmail spam guidance](https://support.google.com/mail/answer/1366858). It is not a Gmail interface capture.* ## Why blocking one address may not stop the mail A block matches an address, not a person’s intent. Bulk senders can use several legitimate sending addresses. Abusive senders can rotate accounts, change domains, or place a familiar name over a different address. A forged visible address can also make unrelated messages appear connected. When the address keeps changing, report each deceptive message through Gmail and look for a stable, narrow pattern before adding a filter. A filter based on a precise subject, address, and other consistent field can be safer than a rule based on one broad word, but it still needs review. For an employer or school account, tell the security team when the messages target several people, imitate an internal sender, or continue after reporting. Organization controls and investigation can address a campaign that one user’s block cannot. ## How to review or remove a block You can unblock from a later message by opening the sender menu and choosing the unblock action. On Gmail on the web, you can also review personal blocks under **Settings**, **See all settings**, and **Filters and Blocked Addresses**. Review the exact address before removing it. If a legitimate sender was blocked accidentally, unblock it and mark a valid message **Not spam** when necessary. If wanted messages continue to be misplaced, the [Gmail safe sender list guide](/learning/gmail-safe-sender-list) explains Contacts and the **Never send it to Spam** filter. Review delete filters separately. A blocked address and a filter can both exist, so removing one does not remove the other. Delete obsolete rules and check Trash or Spam for unintended matches after a change. ## Preserve evidence when the message is more than annoying Do not rush to delete a message tied to threats, fraud, payment instructions, account access, identity information, or workplace compromise. Preserve the original in the approved mailbox process and record the receipt time, full sender address, subject, requested action, and what anyone did. For a managed account, report through the organization’s security route. If credentials were entered, a file was opened, or money was sent, begin the relevant account, device, or financial recovery through a known channel. Blocking the address only changes later mailbox handling. The [Gmail phishing-reporting guide](/learning/gmail-report-phishing) covers Gmail’s report action. Do not forward a live attachment or link to coworkers for informal review. ## If recipients are blocking mail you send A recipient block is a symptom, not a sender-side setting you can reverse. Do not ask recipients to allowlist mail until you have confirmed that they consented to receive it, the list is current, and the sending identity is authenticated. Check SPF, DKIM, and DMARC for the domain you use, remove invalid or unengaged recipients according to your mailing policy, and make unsubscribe handling clear for legitimate bulk mail. The [Gmail spam filter guide](/learning/gmail-spam-filter) explains the broader delivery signals, and [how to authenticate email for Gmail](/learning/authenticate-email-for-gmail) covers the sender-side setup. This sender-side issue is separate from the recipient instructions above. You cannot remove a block in someone else’s Gmail account. ## Sources and further reading - [Google: Block an email address in Gmail](https://support.google.com/mail/answer/8151) - [Google: Report spam in Gmail](https://support.google.com/mail/answer/1366858) - [Google: Fix issues with valid emails in Spam](https://support.google.com/mail/answer/16457426) ## Frequently asked questions ### Does Gmail have a blacklist? No. Gmail does not label its personal sender control “blacklist.” Use **Block** for one address, or create a narrow filter when you want matching mail deleted automatically. ### What happens when I block an email address in Gmail? Later messages from that address are directed to Spam. Blocking is a personal mailbox action. It does not report every message as phishing or prevent the sender from using another address. ### Will the sender know I blocked them? No. Gmail does not send the person a block notification through the normal Block action. The sender may infer that you are not responding, but the mailbox control does not announce the setting to them. ### Can I blacklist a whole domain in Gmail? Yes, but a filter that matches a domain is broader and riskier than one matching an exact address. It may delete legitimate mail from other people at the domain. Use the narrowest reliable match. ### Is Block the same as Report spam? No. Block changes where later mail from an address goes in your account. Report spam sends Google a classification about the selected message. Use both when both outcomes are needed. ### How do I undo a Gmail block? To undo a Gmail block, open a message from the sender and choose the unblock action, or review blocked addresses under **Settings**, **See all settings**, and **Filters and Blocked Addresses** on the web. Check for a separate delete filter too. --- # How to block phishing emails: filters, rules, and limits Canonical: https://www.palisade.email/learning/how-to-block-phishing-emails > Sender blocks, mailbox rules, and spam reports stop known senders. None stop a spoofed domain, which needs DMARC enforcement at the organization level. To block phishing emails, use the controls at the layer you manage: report the message as phishing, block the displayed sender, create a narrow mailbox rule for a repeat pattern, and ask your mail administrator to investigate organization-wide campaigns. No single personal block stops phishing as a category. Attackers can change addresses, domains, accounts, links, and message wording, so blocking works best as a set of controls rather than one permanent list. ## Quick takeaways - Report phishing when the message is deceptive, not merely unwanted. - A sender block usually affects one mailbox and one displayed address. - Use rules only when the matching condition is specific and verified. - Organization-wide filtering belongs with the mail or security administrator. - Blocking a message does not secure an account after someone has interacted with it. - Recognition habits are still needed because filters do not catch every attempt. ## What does blocking a phishing email actually change? "Block" can mean several different actions. A personal sender block tells your mailbox how to handle later messages associated with one address. A spam or phishing report gives the provider a classification signal about the message. A mailbox rule applies conditions you choose. An organization-wide mail rule, gateway policy, or quarantine action affects a wider group of recipients. Those actions do not have the same scope. Blocking `billing-alert@example.invalid` does not automatically block a new address, a compromised real account, a lookalike domain, or a message sent through a different channel. The Federal Trade Commission notes that spam filters keep many phishing messages out, but attackers keep trying to bypass them, so recipients still need a safe verification habit ([FTC phishing guidance](https://consumer.ftc.gov/articles/how-recognize-avoid-phishing-scams)). Start by identifying the outcome you want: - Stop later mail from the same displayed address in your own mailbox. - Teach the provider that the message is deceptive or abusive. - Move a stable, repeat pattern away from the inbox. - Protect a workplace or school from a campaign reaching several people. - Contain an incident after someone clicked, signed in, opened a file, or paid. The correct control follows from that outcome. It should not follow from the message's preferred instructions. ## Block the displayed sender for repeat mail Use the mailbox provider's sender-blocking control when one address repeatedly sends unwanted mail. Open the provider's own message menu, not a button inside the message. Confirm that the command names the sender you intend to block before submitting it. A sender block is narrow by design. It can reduce repeat messages from that address without creating a broad rule that catches unrelated mail. That makes it a reasonable response to persistent nuisance mail. It is weaker against phishing campaigns because the attacker can rotate addresses or send from an account that was taken over. Do not block an entire domain merely because one message looks suspicious unless you administer the mailbox and have verified that the domain has no legitimate use. A broad block can hide password resets, invoices, support messages, or security alerts that people still need. For a work mailbox, collect the original message and ask the mail administrator to decide whether the condition should apply to one address, a domain, a link, an attachment, or another campaign indicator. Blocking also differs from recognition. If the main problem is deciding whether a request is deceptive before acting, use the separate guide on [how to avoid phishing emails](/learning/how-to-avoid-phishing-emails). ## Report phishing instead of treating it as ordinary junk Use the provider's phishing report when the message impersonates a person or organization, asks for credentials or money, directs you to a suspicious site, or tries to cause another harmful action. The Cybersecurity and Infrastructure Security Agency tells recipients not to click links or attachments in suspicious messages and to use a trusted reporting route ([CISA phishing guidance](https://www.cisa.gov/secure-our-world/recognize-and-report-phishing)). A report and a block can happen together, but they answer different questions. The block changes how your mailbox treats the displayed sender. The report classifies the message for the provider or your organization. Neither action proves who sent it, guarantees removal from other inboxes, or closes an incident after credentials or money were exposed. For Outlook-specific mechanics, including the differences among current clients, follow [how to report a phishing email in Outlook](/learning/how-to-report-a-phishing-email-in-outlook). If you are deciding which organization should receive the report, use [where to send a phishing email](/learning/report-email-phishing-scams). The broader [phishing-reporting decision guide](/learning/report-email-phishing-scams) explains how to verify a route before submitting evidence. ## Build a narrow rule for a stable pattern A mailbox rule is useful when you can describe a recurring pattern without relying on a guess about intent. Good conditions are observable: a verified sending address, a domain your organization has decided to block, a specific recipient alias that should never receive external mail, or a campaign marker confirmed by the security team. Weak conditions create collateral damage. Do not filter on a common word such as "invoice," "security," or "password." Legitimate messages use those words. Do not create a rule that deletes mail silently while you are still investigating. Route uncertain matches to a review folder or quarantine controlled by the responsible team. Use a written rule record before changing a work mailbox: ```text Owner: mailbox user or mail administrator Observed pattern: exact address, domain, header, link, or attachment marker Evidence: original message and related reports Action: report, move, quarantine, reject, or delete Scope: one mailbox, group, or organization Exception: known legitimate sender or business process Review date: date the rule should be reassessed ``` The record makes a broad condition visible before it hides legitimate mail. It also gives the administrator a way to remove a temporary campaign rule later. ![Control map separating sender blocks, phishing reports, mailbox rules, and organization-wide filtering by scope](/images/editorial/how-to-block-phishing-emails/how-to-block-phishing-emails-control-map.svg "1200x676") *Source: Palisade deterministic control map based on [FTC phishing guidance](https://consumer.ftc.gov/articles/how-recognize-avoid-phishing-scams) and [CISA phishing guidance](https://www.cisa.gov/secure-our-world/recognize-and-report-phishing).* ## Use organization controls for organization-wide campaigns If several people received related messages, a personal rule is too small. Send the original message through the organization's reporting path. The security or mail team can search for related recipients, compare sender and link indicators, remove or quarantine matching mail, block known infrastructure, and review whether anyone interacted. Administrators should use the evidence available in their own environment. A copied screenshot may omit the sender address, reply address, link destination, attachment details, and routing headers. Preserve the original message according to policy. Do not forward a live attachment around the company to ask whether it looks dangerous. An organization-wide block should have an owner, scope, exception process, and removal condition. A rushed rule that rejects a supplier's whole domain can interrupt business. A condition tied only to visible From text can also miss a lookalike or catch mail the organization actually requested. ## Know what a sender block cannot stop A sender block cannot prevent a new address from contacting you. It cannot stop the same request over text message, chat, phone, or social media. It cannot make a link safe, undo a download, revoke a session, recover a payment, or determine whether a real account was compromised. It also cannot validate a business claim. An email may come from an authenticated service and still contain a fraudulent request because a real account was taken over or a legitimate platform was abused. Conversely, an unexpected message may be legitimate. Verify the claimed event through an account, website, phone number, or person you reach independently. This boundary is why blocking and avoiding are separate tasks. Blocking changes message handling. Avoidance changes what you trust and how you verify a request. ## If someone already interacted with the message Do not treat a block as incident recovery. If someone entered a password, shared a one-time code, approved a sign-in, opened a suspicious attachment, installed software, changed payment details, or sent money, escalate through the relevant account, security, finance, or fraud process. Use a trusted service surface to change credentials or review account activity. Contact a bank or payment provider through known contact information when money is involved. Preserve the message, time, destination, and the action taken. A report can still help, but containment now comes first. The FTC directs people who disclosed personal information to its identity-theft recovery service and accepts fraud reports through ReportFraud.ftc.gov ([FTC phishing guidance](https://consumer.ftc.gov/articles/how-recognize-avoid-phishing-scams)). Follow the process that matches what was exposed rather than repeating the pre-click advice. ## Sources and further reading - [FTC: How to recognize and avoid phishing scams](https://consumer.ftc.gov/articles/how-recognize-avoid-phishing-scams) - [CISA: Recognize and report phishing](https://www.cisa.gov/secure-our-world/recognize-and-report-phishing) ## Frequently asked questions ### Can I permanently block all phishing emails? No. You can block addresses, report deceptive messages, create narrow rules, and use organization filtering, but attackers can change identities and channels. Treat blocking as exposure reduction. Keep independent verification, strong account protection, reporting, and incident response in place for messages that still arrive. ### Is blocking a sender the same as reporting phishing? No. A sender block changes handling for later mail associated with that address in your mailbox. A phishing report submits the suspicious message to the provider or organization for classification and review. Use the action that matches the risk, and use both when the interface and policy support it. ### Should a phishing rule delete matching messages automatically? Only when the condition is verified, the scope is understood, and the responsible owner accepts the risk. During an investigation, quarantine or a review folder is safer because silent deletion can hide legitimate mail and remove evidence the security team needs. ### Why do phishing emails return after I block one address? Because the block usually matches that address, while a campaign can rotate addresses, domains, sending services, or compromised accounts. Report the new message and look for a stable, verified campaign indicator before broadening a rule. ### Does blocking protect me after I clicked? No. Blocking may change future mail handling, but it does not revoke credentials, close sessions, remove software, recover funds, or inspect a device. Start the recovery or incident process for the action you took, then report and block the message as separate steps. --- # How do I report a phishing email in Outlook? Canonical: https://www.palisade.email/learning/how-to-report-a-phishing-email-in-outlook > Use Report, then Report phishing in new Outlook and on the web, or the Report Message add-in in classic Outlook. Tell IT if you clicked or entered data. To report a phishing email in Outlook, select or open the suspicious message and use Outlook's Report control, then choose Report phishing. The location differs by client: new Outlook and Outlook on the web use the message toolbar or More actions, while classic Outlook may show Report, Report Message, or Report Phishing on the ribbon depending on its build and your organization's configuration. Use your employer's security route as well when policy requires it. ## Quick takeaways - Use Outlook's own Report control, not a button inside the message. - New Outlook and Outlook on the web share a similar toolbar-based workflow. - Classic Outlook can show a built-in command or a deployed reporting add-in. - A phishing report is different from Block sender and Report junk. - Managed Microsoft 365 reporting depends on tenant configuration. - Reported mail does not replace account, device, or payment recovery. ## Before you report the message Do not click a link, open an attachment, scan a QR code, reply, call a listed number, or use an unsubscribe link in a message you suspect is phishing. Microsoft's phishing guidance advises checking the full sender address and examining links before selecting them, then reporting suspicious messages rather than interacting with their content ([Microsoft phishing guidance](https://support.microsoft.com/en-us/windows/protect-yourself-from-phishing-0c7ea947-ba98-3bd9-7184-430e1f860a44)). For a work or school account, follow the organization's evidence policy before moving or deleting the message. Some teams want the original message preserved in place until the report action captures it. Others use a separate add-in that creates a security case and removes the message. Do not forward an active attachment to colleagues for informal review. Write down whether anyone interacted. A report is the correct mailbox action for the message, but it is not enough after credential entry, an approved sign-in, a file launch, software installation, payment, or bank-detail change. ## Report phishing in new Outlook for Windows Select or open the message. Look for **Report** on the message toolbar and choose **Report phishing**. If the toolbar is condensed, open **More actions** and find the reporting command there. Complete the confirmation that Outlook presents. Microsoft's current Outlook support page describes phishing and suspicious-message reporting in Outlook and is the source to check when labels move ([Microsoft: Phishing and suspicious behavior in Outlook](https://support.microsoft.com/en-us/outlook/mail/phishing-and-suspicious-behavior-in-outlook)). The sender cannot control Outlook's application toolbar. That is why the application command is different from an image or link inside the email that says "Report," "Secure message," or "Unsubscribe." Do not choose **Block sender** as a substitute for the report. Blocking addresses later mail from one displayed address in your mailbox. Reporting phishing submits the deceptive message through Outlook's reporting workflow. You may use both when appropriate, but the report should carry the security classification. ## Report phishing in Outlook on the web Open Outlook on the web in a browser through your organization's normal Microsoft 365 sign-in route. Select the suspicious message, choose **Report** from the message toolbar, then choose **Report phishing**. If the visible toolbar does not show Report, check **More actions** for the same command. The web app can change independently from desktop Outlook, and an administrator can customize the reporting experience. Follow the control visible in the Outlook interface and the current Microsoft page linked above. Do not assume a third-party mail client connected to the same mailbox sends the same report data. After reporting, note whether the message moved, disappeared, stayed selected, or generated an organization-specific confirmation. Those observations help the help desk distinguish a completed provider action from a report that never reached the intended security workflow. ## Report phishing in classic Outlook for Windows Classic Outlook has more variation. With the message selected, look on the **Home** ribbon for **Report** and choose **Report phishing**. Some organizations and older deployments instead expose a **Report Message** or **Report Phishing** add-in. Its button may appear in the ribbon or the message's additional actions. Do not claim the command is missing until you confirm which Outlook client and build you are using. The **New Outlook** switch, ribbon layout, add-in policy, and organization settings can change what you see. If there is no supported reporting command, stop and use the security route documented by your employer or school. Do not guess at an external forwarding address. An add-in can submit to a different destination than Microsoft's built-in control. The label alone does not tell you whether the report goes to Microsoft, an internal mailbox, or a security product. Ask the administrator what the deployed control does before documenting it for other users. ![Outlook reporting path separating new Outlook, Outlook on the web, and classic Outlook before the shared security escalation step](/images/editorial/how-to-report-a-phishing-email-in-outlook/how-to-report-a-phishing-email-in-outlook-client-paths.svg "1200x676") *Source: Palisade deterministic client map based on [Microsoft's documentation of the built-in Report button](https://learn.microsoft.com/en-us/defender-office-365/submissions-outlook-report-messages), which lists availability client by client. It is not an Outlook interface capture.* ## Report phishing on Mac, iOS, and Android The built-in Report button is not Windows-only. Microsoft documents it in Outlook for Mac version 16.89 (24090815) or later, Outlook for iOS version 4.2511 or later, and Outlook for Android version 4.2446 or later, alongside the new Outlook for Windows and Outlook on the web. On the mobile clients the control sits in the message's own overflow menu rather than a toolbar: open the message, use the ellipsis at the top of the message, and choose the report option. On Mac it follows the desktop pattern and appears in the message toolbar. Two conditions apply everywhere. The build has to meet the minimum above, and your administrator has to have user reporting turned on. If the option is missing on one device but present on another, check the build number before assuming the tenant blocks it. On the versions marked by Microsoft, the built-in button also supports reporting from a shared or delegated mailbox, provided the delegate holds Send As permission. ## What happens to the message after reporting? Microsoft documents the outcome plainly: a message reported as phishing **is deleted**, and a message reported as junk is moved to the Junk Email folder with the sender added to your Blocked Senders list ([Microsoft: report messages in Outlook](https://learn.microsoft.com/en-us/defender-office-365/submissions-outlook-report-messages)). Plan for that before you report: if someone needs the original preserved, capture it first, because the Report button removes it from view. Deletion is a mailbox outcome, not proof that the sender is blocked everywhere or that copies were removed from other mailboxes. Microsoft's reporting behavior and your organization's behavior can be separate. A consumer Outlook.com account uses Microsoft's service workflow. A managed Microsoft 365 tenant may also route user reports according to administrator settings. A deployed security add-in may create its own case, attach the original message, or ask the user for additional context. Do not promise a specific investigation, takedown, sender notification, or response time. Microsoft's public guidance explains how to recognize and report suspicious behavior, but one report does not establish what enforcement will follow. Keep the confirmation or case number if the organization provides one. ## What does the Microsoft 365 administrator see? The honest answer is configuration-dependent. A tenant can use Microsoft's reporting experience, an organization reporting mailbox, a security product, or a combination. The administrator should document which user button is supported, where the report arrives, what message content and metadata it includes, who triages it, and which actions close the case. For a useful handoff, include the mailbox, subject, receipt time, displayed sender, reported time, and whether the user clicked, opened, replied, approved, paid, or entered information. The original message contains more evidence than a screenshot because it can preserve addresses, destinations, attachment names, routing headers, and authentication results. An Outlook report does not automatically tell the administrator whether credentials were entered on another site or whether a device executed a file. The user still needs to say what happened. The administrator should separate message triage, account containment, endpoint response, and payment response rather than treating the report button as all four. ## Report phishing, junk, or block sender? Choose **Report phishing** when the message impersonates someone, requests credentials or money, leads to a suspicious login, carries a harmful attachment, or tries to cause another deceptive action. Choose the junk or spam action for unwanted mail without that deceptive security request. Use **Block sender** when you want later mail associated with one address handled away from your inbox. A message can be both bulk and phishing. Use the phishing classification when the deceptive action is the important risk. You do not need a forensic conclusion before using the safe reporting route your organization provides. If you are trying to change future handling rather than submit this message, read [how to block phishing emails](/learning/how-to-block-phishing-emails). To improve recognition before any click, use [how to avoid phishing emails](/learning/how-to-avoid-phishing-emails). For destinations outside Outlook, use [where to send a phishing email](/learning/report-email-phishing-scams). The general [phishing-reporting decision guide](/learning/report-email-phishing-scams) covers route verification. ## When Outlook reporting is not enough Escalate immediately when someone entered a password, shared a verification code, approved a sign-in, opened an unexpected file, installed software, disclosed personal data, changed payment instructions, or sent money. Use trusted account and financial channels, not contact details from the message. For a work device or account, contact the authorized security or IT team and follow its instructions before deleting mail, browser history, files, or logs. For a payment event, contact the bank or payment provider through a known route. For a personal Microsoft account, open account security through a typed Microsoft address or saved app, then review activity and sessions. You can still submit the Outlook report. It helps route the message, while recovery addresses the harm that may already have occurred. ## Sources and further reading - [Microsoft: report phishing and suspicious emails in Outlook](https://learn.microsoft.com/en-us/defender-office-365/submissions-outlook-report-messages) - [Microsoft: Phishing and suspicious behavior in Outlook](https://support.microsoft.com/en-us/outlook/mail/phishing-and-suspicious-behavior-in-outlook) - [Microsoft: How to spot and report phishing emails](https://support.microsoft.com/en-us/windows/protect-yourself-from-phishing-0c7ea947-ba98-3bd9-7184-430e1f860a44) ## Frequently asked questions ### Where is the Report phishing button in new Outlook? It is normally under **Report** on the message toolbar, with **Report phishing** as the action. If the toolbar is condensed, check **More actions**. Organization policy and interface updates can change placement, so use Microsoft's current Outlook guidance when the visible labels differ. ### Is the Outlook web workflow the same as classic Outlook? No. Outlook on the web uses a toolbar-based Report action similar to new Outlook. Classic Outlook may expose Report on the ribbon or a separately deployed Report Message or Report Phishing add-in. Confirm the client before giving someone a menu path. ### Does reporting phishing block the sender? No. Reporting submits the suspicious message through the configured reporting workflow. Blocking is a separate mailbox action tied to later mail from an address. One report also does not guarantee organization-wide removal or future blocking. ### Will my administrator receive the report? Only if the tenant's reporting configuration or deployed add-in routes it to an organizational destination. The administrator should document whether reports go to Microsoft, an internal mailbox, a security platform, or more than one destination. ### Can I report phishing after I clicked? Yes, you can still report phishing after you clicked, but the report is no longer the complete response. Tell the security team or account provider what you did and begin the relevant credential, device, or payment recovery through a trusted channel. ### Should I delete the email after reporting it? Not automatically. Delete the email only after following the mailbox or organization evidence policy. A security team may need the original message, headers, attachment details, delivery time, and report confirmation before deletion. --- # How do I spot a phishing email before I click? Canonical: https://www.palisade.email/learning/how-to-spot-a-phishing-email > Check what the message asks for, whether the sender domain really matches, where its links point, and whether you expected it. Verify outside the message. To spot a phishing email, check what it wants before judging how polished it looks. Treat unexpected links, attachments, phone numbers, payment demands, passwords, and verification-code requests as reasons to stop. Then verify the claimed event through an app, website, statement, or contact method you open independently. A logo, familiar display name, or urgent subject line cannot replace that check. ## Quick takeaways - Start with the requested action, not the logo or writing quality. - Do not click, call, reply, download, or sign in while the message is unverified. - Read the complete sender address and the real destination behind each link. - Compare the claim with an account or record you open separately. - Report the message through your mailbox and the impersonated organization's current official path. - If you already interacted, protect the affected account before doing more analysis. ## What are the clearest signs of a phishing email? The clearest sign of a phishing email is a message that tries to keep the entire decision inside channels chosen by the sender. It gives you a button to fix the problem, a number to call, a reply address to contact, or an attachment to open. If every route back to safety comes from the same unverified message, you have no independent confirmation. Common phishing patterns include a claimed account lock, failed payment, unfamiliar purchase, refund, shared document, voicemail, tax notice, delivery problem, or security alert. Each pretext creates a reason to act. The requested action may be entering a password, sharing a one-time code, paying an invoice, installing software, opening a document, calling a fake support desk, or changing bank details. [CISA's guidance on recognizing and reporting phishing](https://www.cisa.gov/secure-our-world/recognize-and-report-phishing) advises people to resist urgent requests, avoid suspicious links or attachments, and use a known contact method to verify the message. The point is not that urgency proves fraud. Urgency tells you to slow the process down and obtain evidence elsewhere. Spelling mistakes can support suspicion, but clean grammar does not make a message genuine. Modern templates can copy branding, legal footers, personal names, and transaction details. The decision should survive even when the message looks professional. For a broader gallery of patterns, use the [phishing email examples guide](/learning/phishing-email-examples). This page focuses on the checks you can apply to the message in front of you. ## How do I check the sender without trusting the display name? Expand the sender details and read the complete address. A display name such as "Account Security" or the name of a company is chosen text. The domain after the final `@` matters more than the name before it, but it is still only one clue. Look for substitutions, extra words, unexpected domains, and familiar words placed inside a longer hostname or URL path. Do not infer ownership from one recognizable word. Compare the complete hostname with a destination you reached independently through the organization's app, a trusted bookmark, or a typed address. Do not turn one familiar sender domain into a permanent allowlist. Organizations can use several authorized services, and a compromised account can send harmful content through a legitimate system. An unfamiliar domain should trigger caution, while a familiar one should still be checked against the request and the independently verified account event. The reply address also matters. If Reply-To sends the conversation somewhere different from the visible sender, record the mismatch. Do not test it by replying because that keeps you in the sender's chosen channel. ## How do I inspect a link without opening it? Use the preview your mail client exposes, such as hovering on a desktop or a long press on a mobile device, without navigating. Compare the displayed label with the actual destination. Shortened links, encoded redirects, unrelated domains, and misspelled hostnames all justify stopping. Be careful with buttons. A large "Review activity" button can hide a destination that would be obvious in plain text. The visible company name, a padlock icon, or `https` does not establish that the destination belongs to the organization named in the email. Do not open a suspicious link merely to inspect the page. If an authorized security team needs the URL, preserve it without visiting it and follow the team's evidence-handling process. The [phishing link checker](/tools/phishing-link-checker) can inspect public URL signals without requiring you to visit the destination. A clean result is not proof that the message or account claim is legitimate, so keep the independent verification step. ## How do I verify the claim without touching the email? To verify the claim without touching the email, leave the message open only as a reference. Start a new browser window, use a saved bookmark, open the established app, consult a statement you already possess, or call a number printed on a card or prior document. Do not copy a contact method from the suspicious message. Match a specific claim with specific evidence: - For a purchase or payment, look for the transaction in the independently opened account and in your own payment records. - For a password or sign-in alert, open the account's security area and review recent activity. - For a shared file, contact the supposed sender through a known channel and ask what they sent. - For an invoice or bank-detail change, confirm it with the known person or organization using an established number. - For a delivery or subscription issue, open the relevant service directly and look for the same status. A real issue can exist alongside a malicious email. If your card was declined or your password needs attention, finish the task only through the independent session. Do not return to the email button once you have confirmed the underlying event. ## How should I report a phishing email? Report a phishing email through the reporting process documented for the mailbox that received it. The available control, forwarding method, and deletion guidance depend on the provider or organization, so do not assume that every mailbox uses the same button. If the message reached a work account, follow the organization's security process as well. To alert the impersonated organization, find its current security or fraud guidance from an official site or app you opened yourself. Do not use a reporting address, form, or number supplied by the suspected email. Reporting routes change, and different message types may have different paths. Do not forward active attachments or links to coworkers for informal opinions. If a reviewer needs the message, use the approved reporting workflow. The [guide to reporting email phishing scams](/learning/report-email-phishing-scams) covers evidence preservation and reporting destinations without turning the suspicious email into a new distribution path. ## What if I already clicked, replied, or entered information? If you already clicked, replied, or entered information, the response depends on what left your control. Close the page, stop further interaction, and use a trusted device if you think the current one may have downloaded or installed something. - If you entered a password, change it through the real account and change any other account that reused it. - If you shared a verification code or approved a sign-in, review sessions, devices, recovery details, and recent account changes. - If you supplied card or bank details, contact the financial institution through the number on the card or another verified channel. - If you installed software or opened an unexpected attachment, disconnect only when your incident procedure calls for it and contact the security team. - If you sent money, contact the payment provider promptly and keep receipts, timestamps, and message evidence. Do not spend time proving the message was phishing before protecting the affected account. Recovery is time-sensitive even when attribution remains uncertain. The [recovery guide for a clicked phishing link](/resources-post/what-to-do-if-you-clicked-on-a-phishing-link) separates password, payment, device, and workplace response paths. ## Does passing authentication mean the email is safe? Delivery does not make the sender's claim true, and an authentication pass does not make the message honest. Treat inbox placement and domain-authentication results as separate from the account, payment, document, or support claim you still need to verify. [DMARC connects a passing authentication result to the domain visible in the From address and publishes a domain owner's requested handling policy for failures](https://www.rfc-editor.org/rfc/rfc9989.html). That result is domain-identity evidence. Verify the message's payment, document, support, or account claim through the separate process described above. The Palisade guide on [why phishing emails can pass SPF and DKIM](/learning/why-do-phishing-emails-pass-spf-and-dkim) explains that boundary. For the person holding a suspicious message, independent account verification remains the decisive step. ## A repeatable phishing decision rule Use the same sequence whenever an unexpected email demands action: - Name the claim in one sentence. - Name the requested action in one sentence. - Identify which parts of the verification path came from the message. - Stop using those parts. - Open a trusted account, record, app, site, or contact method separately. - Compare the claimed event with the independent evidence. - Report the message through current official paths. - Start recovery immediately if credentials, money, codes, or device access were exposed. This rule is more dependable than memorizing logos, templates, or old sender addresses. It also works when the message mixes a genuine account fact with a fraudulent instruction. ## Sources and further reading - [CISA: Recognize and report phishing](https://www.cisa.gov/secure-our-world/recognize-and-report-phishing) - [Federal Trade Commission: How to recognize and avoid phishing scams](https://consumer.ftc.gov/articles/how-recognize-and-avoid-phishing-scams) - [RFC 9989: Domain-based Message Authentication, Reporting, and Conformance](https://www.rfc-editor.org/rfc/rfc9989.html) - [Palisade phishing email examples](/learning/phishing-email-examples) - [Palisade guide to reporting phishing](/learning/report-email-phishing-scams) ## Frequently asked questions ### Can a phishing email have perfect spelling and branding? Yes. A phishing email can carry perfect spelling and branding, because writing quality and brand design are weak identity evidence that both can be copied. Judge the requested action, full sender address, real link destination, and independently verified account event instead. ### Does an email from the right domain have to be safe? No. A familiar domain can strengthen the identity evidence, but it cannot prove that a payment, document, phone number, or account claim is honest. Verify the event outside the email. ### Is it safe to click a link if I do not enter a password? No. Clicking a link is not made safe by skipping the password field, and opening the destination is unnecessary when you can reach the same account independently. Use a saved app, bookmark, typed address, or verified contact method instead. ### Should I reply and ask whether the email is real? No. A reply stays inside the sender's chosen channel. Contact the person or organization through an address or number you already trust. ### Is deleting a phishing email enough? Deleting a phishing email is not always enough. Report it through your mailbox or workplace process first when possible, then remove it according to that process. If you already interacted, complete account, payment, or device recovery as well. --- # IRS phishing email: how to verify and report it Canonical: https://www.palisade.email/learning/irs-phishing-email > The IRS does not open contact by email about a refund or a debt. Verify any tax claim through official government channels, then report the message. Treat an unexpected IRS email as unverified until you confirm its tax claim through a federal government site or contact method you found independently. Do not use the message's link, attachment, reply address, payment instructions, or phone number. A government seal, case number, refund amount, or threat of a deadline cannot prove that the sender is the IRS. ## Quick takeaways - Stop if the email asks you to pay, sign in, open a tax document, or provide personal data. - Do not use a phone number or reporting link contained in the message. - Verify the notice through a government destination you open independently. - Separate a refund claim from a demand for money or identity information. - Report the email through your mailbox and current official government guidance. - Protect tax, financial, and account information promptly if you already shared it. ## What does an IRS phishing email look like? An IRS impersonation email usually gives a tax-related reason for immediate action. The claim may involve a refund waiting for confirmation, unpaid tax, an audit, a corrected return, a transcript, identity verification, a penalty, or a notice that supposedly expires soon. The email then asks the reader to follow a link, open a document, call a number, pay, or submit personal information. Those are pattern shapes, not a description of one campaign. The details can change while the decision problem stays the same: the sender is using tax authority and time pressure to keep you inside the message. The Federal Trade Commission's [phishing guidance](https://consumer.ftc.gov/articles/how-recognize-and-avoid-phishing-scams) describes messages that impersonate familiar organizations and try to obtain money or personal information. An IRS-themed message fits that general model when it uses the agency's identity to direct the recipient into a sender-controlled action. Do not approve a message because it includes your name, partial tax data, a plausible filing year, or an official-looking signature. Personal details can make a pretext more convincing, but they do not establish who sent it. For examples across other organizations, use the [phishing email examples page](/learning/phishing-email-examples). This guide stays with the tax-specific verification and recovery choices. ## Which IRS email clues matter most? Start with the request. A demand to send money, buy a payment instrument, provide a Social Security number, upload tax records, disclose bank details, or enter account credentials creates immediate risk. Do not comply through the email, even if the tax issue sounds plausible. Read the complete sender address rather than stopping at "IRS" in the display name. Look for misspellings, extra words, unrelated domains, and a Reply-To address that differs from the visible sender. Do not treat any address as a permanent allowlist. A familiar-looking address does not validate the notice or the destination behind a button. Preview links without opening them. Do not infer that a site is official merely because `irs`, `refund`, or another government word appears somewhere in a long hostname or URL path. Compare the complete destination with a federal government site that you reached independently through your own bookmark, records, or typed navigation. Attachments deserve the same caution. A file named like a notice, transcript, or refund form can still be a lure. You do not need to open it to verify whether your tax account or records contain the claimed issue. ## How can I verify an IRS claim safely? Leave the email unused and open a new browser session. Navigate to the federal government destination you normally use for tax matters by typing it yourself or using a trusted bookmark. If you rely on a tax professional, contact that person through the number or address already in your records. Match the message's claim with evidence you control: - For a claimed refund, check the status through an independently opened government service and compare it with your filed return. - For tax owed, review your own return, prior notices, account records, and known payment history. - For an audit or identity question, locate current official instructions without following the email. - For a transcript or document, confirm that you requested it and find the corresponding activity through a trusted route. - For a payment change, stop and verify the obligation and payment method separately. If a real issue exists, continue only through the independent session or verified professional. A phishing email can refer to a subject that genuinely matters. Confirming the issue does not make the email's link or contact details safe. Do not use a search advertisement as automatic proof of an official destination. Check the hostname carefully and begin from a federal government site you recognize from your own records. If uncertainty remains, use contact information on a prior genuine notice rather than the email in question. ## How do I report an IRS phishing email? The IRS publishes a reporting address for suspicious email: send it to `phishing@irs.gov` ([IRS: report phishing](https://www.irs.gov/privacy-disclosure/report-phishing)). The IRS states it will never initiate contact with you by email ([IRS: privacy guidance about email contact](https://www.irs.gov/privacy-disclosure/irs-privacy-guidance-about-email-contact)), so treat any emailed request for personal or financial information as fraudulent, so treat any such request as fraudulent regardless of how the message looks. First, locate the reporting process documented by the provider or organization responsible for the receiving mailbox. Do not assume that every mailbox has the same button or forwarding address. A work mailbox may also require an internal security report, especially if the email involved employee, payroll, or managed-device access. To report the impersonation to the IRS, forward the message to `phishing@irs.gov` with `IRS` in the subject line, or `Treasury` if the message claims to be from Treasury. Send it **as an attachment** rather than a plain forward: the IRS notes that forwarding normally strips the header data it needs to identify the sender. Never use a reporting form linked from the suspected message itself. Follow the documented process for retention, deletion, or submission of the original message. Avoid broadly forwarding it. If another person needs to assess it, use the organization's approved security process. The [report-email-phishing-scams guide](/learning/report-email-phishing-scams) explains what evidence to keep and why mailbox reporting is different from notifying the impersonated organization. ## What if I already clicked or sent tax information? Move from message analysis to recovery. Record what you exposed, when it happened, and which account or device was involved. Do not continue answering the sender in hopes of correcting the mistake. - If you entered a password, change it through the real account and replace it anywhere else you reused it. - If you supplied a Social Security number, tax document, or identity record, follow independently located government identity-theft guidance. - If you shared bank or card information, contact the financial institution through the number on the card or a known statement. - If you sent money, contact the payment provider and preserve receipts and transfer details. - If you opened an attachment or installed software, contact your security team and follow the endpoint incident process. - If the message involved a work tax, payroll, or benefits account, notify the responsible internal team without sending the suspicious file around. Treat password recovery, payment response, identity recovery, and device response as separate tasks. Complete each path that matches the information or access you disclosed. The [clicked-phishing-link recovery guide](/resources-post/what-to-do-if-you-clicked-on-a-phishing-link) provides a fuller decision tree. ## Why did an IRS phishing email reach me? An email reaching the inbox is not proof that the sender is genuine. The visible From address can also differ from the identities that SPF or DKIM evaluated, so a recipient still has to verify the tax claim outside the message. [DMARC helps a domain owner connect authentication with the domain shown to the reader and publish a requested policy for failures](https://www.rfc-editor.org/rfc/rfc9989.html). That makes it relevant to direct domain spoofing. It does not examine tax records, confirm a refund, validate a payment request, or identify the person controlling a reply address. The explanation of [why phishing can pass SPF and DKIM](/learning/why-do-phishing-emails-pass-spf-and-dkim) covers authenticated lookalike domains, compromised accounts, and the limits of transport evidence. For an IRS-themed message, the safe answer still comes from independently verified tax records and government channels. ## A safe IRS email decision rule Write down the claimed tax event and the action the sender wants. Then remove every link, number, address, attachment, and payment method supplied by the email from your verification path. Open a trusted tax account, locate an official government site separately, consult your filed records, or contact a known tax professional. If no independent evidence matches, report the email as suspected impersonation. If evidence does match, handle the real issue through the trusted route and keep the email unused. This process avoids two common errors: trusting a fake because the topic is plausible, and ignoring a real tax issue because the message carrying it was fraudulent. The email and the underlying tax question are separate objects. ## When does this guidance change? An expected message tied to a tax action you just took still deserves normal link and sender checks. Expectation improves context, but it does not turn the message into an identity guarantee. Open your known account or records to complete sensitive steps. An authorized workplace simulation may also use IRS-style language. Employees should still use the standard reporting control. The training team can confirm the exercise through its established channel after the report arrives. This guide does not decide whether the IRS sent a particular message and does not supply an official sender allowlist. Message templates and sending systems can change. Independent verification avoids relying on a static list that may be incomplete or stale. ## Sources and further reading - [Federal Trade Commission: How to recognize and avoid phishing scams](https://consumer.ftc.gov/articles/how-recognize-and-avoid-phishing-scams) - [RFC 9989: Domain-based Message Authentication, Reporting, and Conformance](https://www.rfc-editor.org/rfc/rfc9989.html) - [Palisade guide to reporting phishing](/learning/report-email-phishing-scams) - [Palisade phishing examples](/learning/phishing-email-examples) ## Frequently asked questions ### Does a tax refund amount prove an IRS email is real? No. A plausible amount is message content, not sender proof. Compare the refund claim with your filed return and an independently opened government service. ### Should I call the phone number in an IRS email? No. Use a contact method from a prior genuine notice, your trusted tax records, or an official government site you opened separately. ### Can I open an attached tax notice just to inspect it? No. Verify the claimed notice through a trusted account or contact first. An unexpected attachment should remain unopened unless an authorized security process handles it. ### What if the tax problem mentioned in the email is real? Handle it through the independently opened government account, verified professional, or trusted notice. Do not return to the email's link, attachment, or payment instructions. ### Is reporting the email enough after I shared my Social Security number? No. Reporting addresses the message. Identity, account, payment, and device recovery are separate tasks and should begin through independently located official channels. --- # Microsoft phishing email: how to check it safely Canonical: https://www.palisade.email/learning/microsoft-phishing-email > Microsoft will not ask for your password or MFA code by email. Check sign-in activity at account.microsoft.com, then use Report phishing inside Outlook. Treat an unexpected Microsoft email as unverified until you check the claimed event through a Microsoft account or work portal you open independently. Do not use the message's sign-in button, attachment, QR code, reply address, or phone number. A Microsoft logo, familiar service name, or real-looking security alert does not prove who controls the requested action. ## Quick takeaways - Open your Microsoft account or work portal separately to check the claim. - Do not approve a sign-in, share a code, or enter a password from an unexpected message. - Read the full sender address and preview link destinations without visiting them. - Confirm shared files and admin requests with the named person through another channel. - Report the email through your mailbox and your organization's security process. - Revoke exposed sessions and protect the account quickly if you already signed in. ## What does a Microsoft phishing email look like? Microsoft impersonation can borrow the language of products people already use. A message may claim that a Microsoft account was locked, a password will expire, storage is full, a subscription payment failed, a shared document awaits review, a voicemail is available, or an administrator needs an urgent action. It may also present a Teams invitation, a security alert, or a notice about an unfamiliar sign-in. Each pretext leads to a controlled action. The sender wants the recipient to sign in, scan a QR code, open an Office file, enable content, call a support number, approve a notification, or send payment. These are recurring pattern shapes, not evidence about a specific campaign or a fault in Microsoft's systems. [Microsoft's phishing guidance](https://support.microsoft.com/en-US/security/protect-yourself-from-phishing) tells recipients to examine suspicious messages and report them instead of interacting with their content. The safe response begins before the login screen: open the relevant Microsoft service yourself and look for the claimed event there. Do not assume a message is fake only because you did not expect it. A coworker may have shared a real file, or a real account event may need attention. The email remains an untrusted route until another source confirms the request. Use the [phishing email examples page](/learning/phishing-email-examples) for general patterns. This guide focuses on Microsoft account, document, and workplace contexts. ## Which Microsoft sender and link clues matter? Expand the sender details. A display name such as "Microsoft 365 Security" can be chosen by anyone sending the message. Inspect the address after the final `@`, any Reply-To value exposed by the client, and the actual destination behind each button. Do not infer ownership from `microsoft`, `office`, or another familiar word appearing somewhere in a longer hostname or URL path. Compare the complete destination with the Microsoft account or work portal you reach through your normal route. Logos, page titles, and a padlock do not replace that comparison. Even after you independently confirm a Microsoft destination, confirm the business context with the person or team named in the request. The destination check and the authorization check answer different questions; neither substitutes for the other. Treat QR codes like buttons whose destination has not been verified. Do not scan an unexpected sign-in or document code. Open the account or application through your normal route instead, then look for the event named in the email. ## How do I verify a Microsoft security alert? Open a fresh browser window or a trusted app and sign in through your normal route. For a personal account, use whatever security or sign-in evidence the independently opened account exposes. For a work or school account, use the established Microsoft 365 entry point or ask the internal IT team through a known channel. Match the alert with a fact outside the email: - For an unfamiliar sign-in, review account activity and active sessions. - For a password warning, check the account or the organization's stated password policy. - For a subscription or invoice, review billing in the independently opened account and compare it with purchasing records. - For a shared file, contact the supposed sender using an existing chat thread, directory entry, or known address. - For an admin request, verify the ticket or change through the organization's normal approval path. If the account shows a real warning, complete the security action there. Do not return to the email button. A real alert can be copied into a phishing lure, and a fake message can arrive at the same time as a real but unrelated account issue. ## How do I handle a shared document or voicemail lure? Do not open the document or voicemail attachment to see whether it is genuine. The message may link to a credential page, request application consent, deliver a file, or ask you to enable active content. Verification should happen with the person and the account, not inside the document. Ask the supposed sender what they shared and why, using a channel you already had before the email arrived. If the item should exist, open the established Microsoft app or portal and locate it there. An item that appears in a real collaboration service still needs business-context verification when the request is unusual. For workplace mail, use the organization's documented security process before forwarding or downloading anything. Tell the reviewer whether you clicked, signed in, approved a prompt, opened a file, or installed software. Do not collect extra evidence by interacting with the message. ## How do I report a Microsoft phishing email? In Outlook or Outlook.com, select the message and use **Report** then **Report phishing**. Microsoft notes that this reports the sender but does not block them from sending you more mail, so treat reporting and blocking as separate actions. If you use a different email client, Microsoft asks for the message as an attachment in a new email to `phish@office365.microsoft.com`, and specifically not as a plain forward, because the original is needed intact ([Microsoft: protect yourself from phishing](https://support.microsoft.com/en-US/security/protect-yourself-from-phishing)). Follow the current process documented for Outlook or for whichever mailbox received the email; do not rely on a copied interface path that may not match your account. If the email reached a work or school account, follow the organization's incident channel as well. Do not assume that reporting to the mailbox provider creates an internal ticket. Keep the original available until the security team confirms that it has the evidence it needs. For a message received outside Microsoft mail, use that provider's phishing control and independently locate Microsoft's current security guidance. The [general phishing reporting guide](/learning/report-email-phishing-scams) explains the difference between provider reporting, brand notification, and workplace escalation. ## What if I already entered my Microsoft password? Use a trusted device and an independently opened Microsoft account surface. Change the exposed password, then use the security and account-recovery options that surface provides. In a managed tenant, notify the IT or identity team and state exactly what you entered, approved, opened, or installed. If you approved a sign-in prompt, supplied a one-time code, scanned a QR code, or granted application consent, say so explicitly in the incident report. Those actions are distinct from typing a password and need to be included in the recovery review. If you opened an attachment, enabled content, or installed software, follow the endpoint incident process. Do not upload a work file or raw mailbox evidence to an unapproved public service. Preserve the original message, URL, time, and any alerts you received. Payment or subscription fraud needs a separate financial response. Contact the payment provider using a verified statement or card number, not the email. The [clicked-phishing-link recovery guide](/resources-post/what-to-do-if-you-clicked-on-a-phishing-link) covers account, device, and payment branches in more detail. ## Why did a Microsoft phishing email reach me? Mailbox delivery and sender authentication do not turn a message into a verified business request. The recipient still has to confirm the sign-in, file, invoice, or administrator action through an independently opened account or a known person. [DMARC checks whether an SPF or DKIM pass aligns with the domain shown in the From address and publishes a requested policy for failures](https://www.rfc-editor.org/rfc/rfc9989.html). Treat that result as domain-identity evidence, then separately confirm the document, invoice, or sign-in action through the trusted Microsoft or workplace route. Read [why phishing emails can pass SPF and DKIM](/learning/why-do-phishing-emails-pass-spf-and-dkim) for the technical boundary. This is the only point where domain authentication answers part of the consumer question: it can help receivers assess the sending identity, but the recipient still verifies the request outside the email. ## A safe Microsoft email decision rule Separate the Microsoft service named in the message from the route the sender gave you. Open the service through your normal bookmark, app, or organizational portal. Then compare the claimed sign-in, file, billing event, or admin request with evidence visible there. If nothing matches, report the email and leave its content unused. If something matches, continue within the independently opened service and confirm any unusual request with the responsible person or team. If you already exposed credentials, codes, consent, money, or device access, begin the matching recovery path before analyzing the message further. This approach does not depend on recognizing Microsoft terminology or a remembered template. It tests the missing piece directly: whether the action connects to a request you recognize and intended. ## Sources and further reading - [Microsoft Support: How to spot and report phishing emails](https://support.microsoft.com/en-US/security/protect-yourself-from-phishing) - [RFC 9989: Domain-based Message Authentication, Reporting, and Conformance](https://www.rfc-editor.org/rfc/rfc9989.html) - [Palisade phishing reporting guide](/learning/report-email-phishing-scams) - [Palisade phishing email examples](/learning/phishing-email-examples) ## Frequently asked questions ### Can a real Microsoft sign-in page be part of a phishing attempt? Yes. A request can misuse a legitimate sign-in or consent flow. Start only from a Microsoft account or work portal you opened independently, and confirm that you initiated the action. ### Should I approve a Microsoft Authenticator prompt after an email asks me to? No. Approve only a sign-in you started and can match to your device, location, and account activity. Report an unexpected prompt through your established account or workplace process. ### Does a Microsoft logo prove a shared document email is genuine? No. Confirm the file with the supposed sender through a known channel, then locate it in the independently opened collaboration service. ### Is changing my password enough after I signed in through the email? Not always. Review sessions, recovery details, sign-in activity, forwarding rules, and connected applications, and involve the tenant administrator for a managed account. ### Can I report a Microsoft phishing email without opening it? Yes. Use the reporting control in the mailbox that received it and follow any workplace process. Do not open its links or attachments to collect more proof. --- # Netflix phishing email: verify billing and account alerts Canonical: https://www.palisade.email/learning/netflix-phishing-email > Netflix will not ask for card details by email. Check billing and account status by signing in at netflix.com directly, then report and delete the message. Treat an unexpected Netflix email as unverified until you check the claimed billing, plan, or account event in the Netflix app or a browser session you open independently. Do not use the message's payment-update button, reply address, attachment, or phone number. A familiar logo, show artwork, masked card number, or threat that streaming will stop cannot prove the request is genuine. ## Quick takeaways - Open Netflix independently and check the account and billing state. - Do not enter a password or payment card after following an unexpected email link. - A failed-payment or suspension notice is a claim until the account confirms it. - Ask other household members whether they changed the plan or account. - Report the message through your mailbox and Netflix's current official help path. - Contact the card issuer through the number on the card if payment data was exposed. ## What does a Netflix phishing email look like? Netflix impersonation usually turns access to the service into a deadline. A message may claim that a payment failed, a subscription is paused, an account will close, a new device signed in, the plan changed, or billing information must be updated. Other lures promise a refund, free viewing period, gift, or account upgrade. The requested action can be signing in, entering card details, confirming identity information, calling a support number, or opening an invoice. The email may use current-looking entertainment artwork and a plausible billing date to make the action feel routine. These are pattern shapes, not descriptions of one campaign or evidence that Netflix was breached. The brand is being impersonated. The relevant facts live in the independently opened account and the payment records, not in the design quality of the email. The Federal Trade Commission's [phishing guidance](https://consumer.ftc.gov/articles/how-recognize-and-avoid-phishing-scams) describes messages that impersonate organizations to obtain information or money. A streaming-payment lure applies that pattern to a service people do not want interrupted. Use the [phishing email examples page](/learning/phishing-email-examples) for patterns that apply across brands. This guide stays with Netflix billing and account-access decisions. ## Which Netflix email clues matter most? Start with the account relationship. Do you have a Netflix subscription, and is the message addressed to the email account used for it? Did you or another household member change the plan, payment method, or account details? An unexpected message can be a mistake, but it should not control the verification route. Read the full sender address and Reply-To value. A "Netflix" display name is only chosen text. Extra words, spelling substitutions, and unrelated domains support suspicion. A familiar-looking address still does not confirm the billing claim or link destination. Preview buttons without opening them. Do not infer ownership because `netflix` appears somewhere in a longer hostname or URL path. Compare the complete destination with the service route you opened independently. Payment forms are especially sensitive. Do not provide a full card number, security code, bank login, verification code, or identity document merely to keep streaming active. Open the account separately and inspect the payment state there. ## How do I verify a Netflix billing email? Open the installed Netflix app or use a trusted bookmark or typed address. Sign in through that independent route and use whatever subscription, payment, or access evidence the account exposes. Compare the email's claim with evidence outside the message: - Check whether the account shows a payment problem or interruption. - Review your card or bank account for a matching Netflix charge. - Ask other authorized household members whether they changed the plan or credentials. - Compare the account email with the address that received the message. - Review whether a new device or location matches recent household activity. If the account shows no issue, report the message and leave its link unused. If a real billing problem appears, correct it inside the account you opened independently. Do not return to the email button after confirming the issue. A real charge does not automatically validate an email. Match the amount and date, and handle any dispute through the card issuer or account route you trust. ## How do I handle a new-device or plan-change alert? Check whether someone authorized to use the account made the change. Shared household access can create activity that looks unfamiliar at first. Confirm through a known channel rather than replying to the email. If no one recognizes the change, use the security and recovery options available through the independently opened account. Change an exposed or reused password from the trusted session and follow the service's current account-recovery instructions. Do not approve a sign-in, share a code, or scan a QR code because the email says it will secure the account. Leave the message route unused and begin from the service session you opened independently. If the account email or recovery path has already changed, locate Netflix's current account-recovery support through an official site you opened yourself. Do not use the phone number or form inside the suspicious message. ## How do I report a Netflix phishing email? Locate the reporting process documented for the receiving mailbox. If it reached a work mailbox, follow the internal security path too and explain whether you exposed workplace credentials or used a managed device. Netflix publishes a reporting address: forward the message to `phishing@netflix.com`. Netflix also states its own boundary plainly — it will never ask you to share personal information in a text or email, naming credit or debit card numbers, bank account details and Netflix passwords, and it will never ask for payment through a third-party vendor or website ([Netflix: how to tell if an email is from Netflix](https://help.netflix.com/en/node/65674)). Reach that page by opening Netflix yourself rather than through a link in the message. Do not trust a help link contained in the email. Different account and payment problems may require different routes. Follow the documented retention or deletion instructions and avoid forwarding an active payment button or attachment to friends. The [phishing reporting guide](/learning/report-email-phishing-scams) explains how a mailbox report, brand report, and payment dispute differ. ## What if I already entered payment or account details? Use a trusted device and open Netflix independently. Replace the exposed password, including on any other account where you reused it. Follow the account-recovery options exposed by the service, and ask other household members about changes that might explain the alert. If you supplied card or bank information, contact the issuer through the number on the card or a trusted statement. Tell it what information was exposed and whether any charge appears. A Netflix account password change does not protect a card number entered on another site. If you shared a verification code or approved a sign-in, report that detail. If you installed software or opened an unexpected attachment, follow the device incident process. Preserve the URL, time, message, and payment records. The [recovery guide after clicking a phishing link](/resources-post/what-to-do-if-you-clicked-on-a-phishing-link) separates credential, payment, and device actions. ## Why did a Netflix phishing email reach me? Delivery is not proof that Netflix sent a message. Domain-authentication results answer a narrower identity question and cannot validate a private billing or subscription claim. [DMARC connects an aligned authentication result to the domain visible in the From address and publishes a requested policy for failures](https://www.rfc-editor.org/rfc/rfc9989.html). Treat that as domain-identity evidence, then verify the billing problem or support request through the independent account route. The Palisade guide on [why phishing passes SPF and DKIM](/learning/why-do-phishing-emails-pass-spf-and-dkim) explains that limit. The recipient still resolves the question through the account and payment records opened independently. ## A safe Netflix email decision rule Name the claimed event: payment failure, suspension, refund, new device, plan change, or account update. Remove the email's button, number, attachment, and reply address from the verification path. Open Netflix and the relevant payment account separately. If neither shows the event, report the email. If the event is real and expected, no email action is needed. If it is real and unauthorized, begin account or payment recovery through the independent routes. If credentials, card details, codes, or device access were exposed, complete each recovery step that matches. This rule does not require an exact sender-address allowlist or a remembered Netflix template. It tests the subscription and payment facts the message is trying to borrow. ## Sources and further reading - [Federal Trade Commission: How to recognize and avoid phishing scams](https://consumer.ftc.gov/articles/how-recognize-and-avoid-phishing-scams) - [RFC 9989: Domain-based Message Authentication, Reporting, and Conformance](https://www.rfc-editor.org/rfc/rfc9989.html) - [Palisade phishing reporting guide](/learning/report-email-phishing-scams) - [Palisade phishing email examples](/learning/phishing-email-examples) ## Frequently asked questions ### Does a Netflix payment-failed email mean my subscription stopped? No. Open Netflix independently and check the account state. The email alone cannot establish whether a payment failed. ### Should I update my card through a Netflix email button? No. Open the app or site through your normal route and make any needed billing change inside that account. ### Can a real Netflix charge make the email genuine? No. Match the amount and date, but manage the charge and account only through independently opened Netflix and payment-provider routes. ### What if another household member changed the plan? Confirm with that person through a known channel. Then review the account directly and leave the email link unused. ### Is changing my Netflix password enough after sharing card details? No. Contact the card issuer through a verified number as well. Account credentials and payment-card exposure require separate recovery steps. --- # Is noreply@email.apple.com legitimate? Canonical: https://www.palisade.email/learning/noreply-email-apple-com > Apple documents noreply@email.apple.com for some Business Manager notices, but the address alone proves little. Learn how to verify a message safely. Apple documents `noreply@email.apple.com` as the sender for device order progress report messages, which go to users holding the Administrator, Site Manager, or Device Enrollment Manager role. That narrow official use does not prove that every message displaying the address is legitimate. The visible From field can be forged, and an authentic message can still be misunderstood or contain a link you should verify. Check trusted receiver-added authentication and confirm the claimed event in an Apple surface you open independently. ## Quick takeaways - Apple has documented `noreply@email.apple.com` for Apple Business Manager administrator notifications. - That documentation is not a complete Apple sender-address allowlist. - A visible From address is a message claim, not receiver-verified authentication evidence. - An aligned DMARC pass can support domain identity but cannot prove the message's business claim. - Verify the event independently and report suspicious Apple mail to `reportphishing@apple.com`. This page answers one exact sender-address question in the [email threats hub](/learning/threats). For broader impersonation patterns, use the [Apple phishing email guide](/learning/apple-phishing-email). For generated address privacy, use the [Private Relay Apple ID guide](/learning/private-relay-apple-id). ## What has Apple actually documented about the address? Apple's published Apple Business Manager guide says administrator email messages from Apple Business Manager use `noreply@email.apple.com` ([Apple Business Manager guide, PDF](https://support.apple.com/guide/apple-school-manager/get-device-order-progress-reports-axm51fc0ee8b/web)). That is direct evidence for a specific product and recipient role. It is not evidence that every consumer receipt, support case, security alert, or Apple Account notification should use the same address. The distinction matters because community answers often turn one observed sender into a universal allowlist. Apple's own security guidance does not instruct recipients to trust a message because its visible sender matches a memorized address. It tells people to examine mismatches and suspicious requests, avoid following suspicious links, and contact Apple directly when uncertain ([Apple social-engineering guidance](https://support.apple.com/en-us/102568)). So the precise answer is conditional. The address has a documented legitimate use. The individual message still needs its own evidence. ## What should I verify in a worked header example? Suppose an Apple Business Manager administrator receives a notice displaying this envelope information: ```text From: Apple Business Manager Subject: Managed Apple Account update 630184 Date: Tue, 25 Aug 2026 13:42:10 +0000 ``` The administrator then obtains the original message headers from the receiving mailbox. The following is an illustrative result, not a header copied from an Apple message: ```text Authentication-Results: mx.recipient.example; dkim=pass header.d=email.apple.com; spf=pass smtp.mailfrom=bounce.email.apple.com; dmarc=pass header.from=email.apple.com ``` Start by asking who added that field. RFC 8601 Section 1.2 describes an authentication service's trust boundary and warns that the mere presence of `Authentication-Results` is not enough. A sender can insert a lookalike field before delivery. Use the field added by a receiver you trust ([RFC 8601, Section 1.2](https://www.rfc-editor.org/rfc/rfc8601.html#section-1.2)). Next, read the identifiers. RFC 8601's registered properties map a DKIM result to `header.d` and an SPF result to `smtp.mailfrom` or `smtp.helo` ([RFC 8601, Section 2.7.2](https://www.rfc-editor.org/rfc/rfc8601.html#section-2.7.2)). In this hypothetical result, both authenticated identifiers sit under `email.apple.com`, and the reported DMARC result passes for the visible From domain. DMARC alignment compares the authenticated identifier with the RFC5322 From domain. RFC 9989 Sections 4.4.1 and 4.4.2 define DKIM and SPF alignment, and Section 4.1 says a message passes DMARC when at least one supported mechanism both authenticates and aligns ([RFC 9989, Section 4.4](https://www.rfc-editor.org/rfc/rfc9989.html#section-4.4)). The example reports both, but one aligned pass would be enough for DMARC. Read receiver-added results and compare identifiers with visible From. ![Three-stage identity chain separating visible From, receiver authentication, and independent Apple account context](/images/editorial/noreply-email-apple-com/apple-sender-identity-chain.svg "1200x676") *Source: Palisade deterministic interpretation of [RFC 8601](https://www.rfc-editor.org/rfc/rfc8601.html) and [RFC 9989](https://www.rfc-editor.org/rfc/rfc9989.html).* Verify the event outside the message even when authentication aligns. ## What does that header evidence prove? The hypothetical result supports a limited conclusion: the trusted receiver reports authentication and alignment for the same domain shown in From. It does not prove that update `630184` exists, that the recipient expected it, or that every URL in the body is safe. It also cannot be reused to validate a different message. The opposite needs care too. An SPF failure does not automatically prove phishing because forwarding can change the SMTP path. A DKIM failure can reflect message modification. A missing result may reflect how the receiving system exposes headers. Security teams should analyze the actual path instead of inventing a verdict from one token. If raw headers are available, the [Email Header Analyzer](/tools/email-header-analyzer) can parse the supplied authentication fields. It cannot access private Apple Account or Business Manager activity, establish the sender's intent, or inspect a destination merely because it appears in a header. ## How do I verify the message safely? ### Match the recipient and product context Ask whether the mailbox belongs to an Apple Business Manager administrator and whether the subject relates to activity that product performs. A consumer who has never administered Apple Business Manager should not use the product guide as proof that an unrelated receipt or account alert is genuine. ### Open the expected Apple surface independently Use a bookmark, a typed official address, or the relevant Apple app or device Settings. Do not use the message link. Match the claimed update, device, purchase, role, or case number. If nothing matches, contact Apple through an independently obtained support route. ### Review the complete request Apple says support will never ask for a password, device passcode, or two-factor authentication code. Its guidance also says support will not ask a person to tap Accept in a two-factor prompt or disable security controls ([Apple social-engineering guidance](https://support.apple.com/en-us/102568)). A message or follow-up caller making one of those requests should be treated as suspicious regardless of the displayed address. ### Preserve and report suspicious evidence Apple asks people to forward suspicious email purporting to be from Apple to `reportphishing@apple.com`. Work mail may also need an internal security report. Preserve the original message and headers under the organization's handling rules, and redact personal data before sharing beyond the authorized team. ## What does "noreply" mean here? `noreply` is the local part before the `@`. It signals that the mailbox is not intended for a conversation. It does not authenticate the domain, prevent delivery, or guarantee that a reply will bounce. Different systems may discard a response, route it to an unmonitored mailbox, or generate an automated notice. Do not reply as a verification test. A reply stays inside the channel chosen by the message and can confirm that your address is active. Use the product's documented support or account route instead. ## When does this answer not apply? The documented Apple Business Manager use does not apply to every Apple service, every country, or every kind of notification. It does not prove that Apple will always use the address, and it does not justify blocking every Apple message that uses another address. Vendor sending systems change, and a complete allowlist would require current product-specific evidence from Apple. This page also cannot validate a forwarded screenshot. Screenshots omit routing and authentication fields and can be edited. Obtain the original message from the receiving mailbox when header analysis is warranted. Nor does a saved contact settle the question. Mail clients can display an address-book name beside a newly received message, which may make the sender look familiar without adding authentication evidence. Verify the original message and the claimed activity each time. If the request concerns a product you do not use or an administrator role you do not hold, that mismatch is important context for escalation. ## Sources and further reading - [Apple Business Manager guide](https://support.apple.com/guide/apple-school-manager/get-device-order-progress-reports-axm51fc0ee8b/web) - [Apple: Recognize and avoid social engineering](https://support.apple.com/en-us/102568) - [RFC 8601, Authentication-Results](https://www.rfc-editor.org/rfc/rfc8601.html) - [RFC 9989, DMARC](https://www.rfc-editor.org/rfc/rfc9989.html) ## Frequently asked questions ### Is noreply@email.apple.com a real Apple address? Yes, in a narrow documented context. Apple's Business Manager guide identifies it as the sender for administrator messages. That does not authenticate an individual email or make it a universal address for every Apple service. ### Can I trust a message because DMARC passes? No. An aligned DMARC pass supports the domain identity reported by a trusted receiver. It does not prove that the claimed event happened, that the recipient expected it, or that every request and destination is safe. ### Should I reply to noreply@email.apple.com? No. The local part indicates that replies are not the intended support path, and a reply is not a useful authenticity test. Open the relevant Apple product or support route independently. ### Does Apple publish a complete email sender list? Not in the sources supporting this page. The official evidence confirms one Business Manager use, not a complete cross-product allowlist. Verify the product context and the individual message instead of relying on a memorized list. ### Can a forged message display the exact address? Yes, the visible From field can be forged, but exact-domain forgery of this address is the case DMARC handles. `email.apple.com` publishes `v=DMARC1; p=reject`, and `apple.com` publishes `p=quarantine; sp=reject`, so a receiver honouring those policies rejects mail that fails authentication while claiming the domain. That pushes real attacks toward lookalike domains and display-name spoofing instead, neither of which DMARC evaluates. A pass still says the domain authorised the message, never that its claim is true. Use receiver-added authentication as supporting evidence and verify the claimed activity in an Apple surface opened independently. ### Should I report a suspicious message using this address? Yes. Apple asks recipients to forward suspicious mail purporting to be from Apple to `reportphishing@apple.com`. Work recipients should also follow their organization's security-reporting process. --- # Office 365 SMTP settings and authentication Canonical: https://www.palisade.email/learning/office-365-smtp-settings > Use current Office 365 SMTP settings, choose OAuth and mailbox policy safely, then validate SPF, DKIM, DMARC, safe sending limits, and delivery. Office 365 has three SMTP sending methods. Prefer OAuth-capable client SMTP submission at `smtp.office365.com` on port `587` when an application sends as a mailbox. Use direct send for devices that only address recipients in your Microsoft 365 organization. Use SMTP relay when a connector can identify the sender and the application must reach external recipients. [Microsoft documents the three methods and their different requirements](https://learn.microsoft.com/en-us/troubleshoot/exchange/email-delivery/fix-issues-with-printers-scanners-and-lob-applications-that-send-email-using-off). ## Quick takeaways - Client SMTP submission authenticates as a mailbox; direct send and SMTP relay do not use a mailbox sign-in. - Direct send is limited to recipients in your Microsoft 365 organization, while SMTP relay can reach external recipients through an approved connector. - Tenant security policy and the mailbox's Authenticated SMTP setting can block otherwise correct values. - Prefer OAuth. Any Basic-authentication exception for Client Submission (SMTP AUTH) needs an expiry because Microsoft is retiring that path. - Exchange Online documents `30` messages per minute and `10,000` recipients per day for a mailbox. - SMTP acceptance does not prove DMARC alignment or inbox placement. This guide is part of Palisade's [ESP setup hub](/learning/esp-setup). It compares Exchange Online client submission, direct send, and SMTP relay, then works through OAuth-capable client submission in detail. It does not cover an on-premises Exchange receive connector or a consumer Outlook.com recovery flow. ## What should I check before configuring Office 365 SMTP? Confirm whether the application must send outside the organization, whether it can authenticate as an Exchange Online mailbox, and whether its network has a stable identity for a connector. For client submission, confirm that the application supports STARTTLS and an approved authentication method. Record the visible From address, expected recipient volume, message type, and any Send As requirement. Microsoft's current client-submission guidance lists `smtp.office365.com`, port `587` recommended or port `25`, TLS/STARTTLS enabled, and mailbox credentials. It also says the application should send from the same address used to authenticate unless the account has Send As permission ([Microsoft: Client SMTP submission](https://learn.microsoft.com/en-us/troubleshoot/exchange/email-delivery/fix-issues-with-printers-scanners-and-lob-applications-that-send-email-using-off)). Check policy before changing the application. Microsoft says SMTP AUTH supports modern OAuth, can be disabled at the organization level, and can be enabled for mailboxes that still require it. Security defaults can disable SMTP AUTH, while authentication policies can block basic authentication ([Microsoft: Enable or disable authenticated client SMTP submission](https://learn.microsoft.com/en-us/exchange/clients-and-mobile-in-exchange-online/authenticated-client-smtp-submission)). Do not disable a tenant-wide security control merely to make a legacy client connect. ## Which setup method should I use? Microsoft's three methods are not interchangeable: - **Client SMTP submission (SMTP AUTH):** The application signs in as a licensed mailbox and submits through `smtp.office365.com`, normally with STARTTLS on port `587`. Pick it for a mailbox-scoped sender that supports OAuth and fits the documented mailbox limits. - **Direct send:** The device or application sends to the tenant's Microsoft 365 MX endpoint on port `25` without a mailbox sign-in. It can address recipients in the same Microsoft 365 organization, but it cannot relay to external recipients. Pick it for internal-only notifications from a device that cannot use SMTP AUTH. - **SMTP relay:** The device or application sends to the tenant's Microsoft 365 MX endpoint on port `25` without a mailbox sign-in. An inbound connector identifies the source by a static public IP address or TLS certificate and permits relay to internal or external recipients. Pick it for an application-wide sender that needs external delivery and can meet the connector requirements. These requirements come from [Microsoft's printer, scanner, and line-of-business application guidance](https://learn.microsoft.com/en-us/troubleshoot/exchange/email-delivery/fix-issues-with-printers-scanners-and-lob-applications-that-send-email-using-off). SMTP relay and direct send avoid mailbox credentials, but they do not bypass connector, recipient-scope, anti-abuse, or Exchange Online service controls. Microsoft also says legitimate bulk commercial email should use a specialized provider rather than Exchange Online mailboxes ([Exchange Online limits](https://learn.microsoft.com/en-us/office365/servicedescriptions/exchange-online-service-description/exchange-online-limits)). The current Microsoft settings table anchors the endpoint and transport values. ![Microsoft Learn table showing the Microsoft 365 client SMTP submission endpoint, port, TLS, and authentication requirements](/images/editorial/office-365-smtp-settings/microsoft-365-client-submission-settings-docs.png "650x212") *Source: Current first-party configuration table from [Microsoft Learn](https://learn.microsoft.com/en-us/troubleshoot/exchange/email-delivery/fix-issues-with-printers-scanners-and-lob-applications-that-send-email-using-off), captured August 25, 2026; this is documentation evidence, not a tenant screen.* Confirm client submission is the intended method before changing SMTP AUTH. A working test at low volume does not make a mailbox, direct-send path, or connector suitable for a marketing platform. ## How do I configure Office 365 SMTP? ### 1. Define one controlled sender For a worked example, suppose `alerts@example.com` is an Exchange Online mailbox. The application will send `240` transactional alerts per day, use visible From `alerts@example.com`, and send one test to Microsoft 365 plus one mailbox outside the tenant. Run identifier `o365-smtp-630184` contains no customer data. ### 2. Enter the endpoint and transport Set server `smtp.office365.com`, port `587`, and STARTTLS. Require certificate validation. Do not choose implicit SSL merely because another provider uses port `465`; Microsoft's client-submission table specifies TLS/STARTTLS for this workflow. ### 3. Configure OAuth or an approved credential Use the application's documented Microsoft OAuth flow when supported. Tenant ID, application registration, client identifiers, scopes, secrets, certificates, and tokens are account-specific. Never copy a registration from another tenant or store a client secret in source control. Do not treat Basic authentication as a permanent Client Submission design. Microsoft's current timetable, published in January 2026, is specific: behaviour is unchanged until December 2026, and **at the end of December 2026 SMTP AUTH Basic authentication is disabled by default for existing tenants**. Tenants created after December 2026 do not get it at all. Microsoft will announce the final removal date in the second half of 2027 ([Microsoft: updated Exchange Online SMTP AUTH Basic authentication deprecation timeline](https://techcommunity.microsoft.com/blog/exchange/updated-exchange-online-smtp-auth-basic-authentication-deprecation-timeline/4489835)). Read "disabled by default" precisely, because the distinction decides how much time an application really has. It is not removal. A tenant can still re-enable SMTP AUTH after December 2026, and OAuth-based SMTP AUTH is unaffected throughout ([Microsoft: Basic authentication deprecation in Exchange Online](https://learn.microsoft.com/en-us/exchange/clients-and-mobile-in-exchange-online/deprecation-of-basic-authentication-exchange-online)). What disappears on that date is the assumption that a Basic-auth client keeps working without anyone deciding to keep it working. So give any Basic-auth exception an owner, an OAuth migration target, and an expiry no later than **December 2026** — the date the default flips, not the date support ends, because that is the point at which an unattended exception starts failing silently after a tenant change. ### 4. Limit SMTP AUTH to the required mailbox If organization-level SMTP AUTH is disabled but the approved application requires it, an authorized administrator can enable Authenticated SMTP for the specific mailbox. Microsoft documents the Microsoft 365 admin center path through Users, Active users, the user, Mail, Manage email apps, then Authenticated SMTP ([Microsoft SMTP AUTH controls](https://learn.microsoft.com/en-us/exchange/clients-and-mobile-in-exchange-online/authenticated-client-smtp-submission)). Tenant security defaults or authentication policy can still take precedence. The first-party Admin Center capture shows the material control in a sample mailbox. ![Microsoft 365 admin center Manage email apps panel showing the Authenticated SMTP mailbox control](/images/editorial/office-365-smtp-settings/microsoft-365-authenticated-smtp-docs.png "688x528") *Source: Microsoft-published Admin Center capture in [Microsoft Learn](https://learn.microsoft.com/en-us/azure/sap/workloads/exchange-online-integration-sap-email-outbound), captured August 25, 2026; the sample mailbox is SAP-specific and does not establish the right policy for another tenant.* Apply account-specific authorization only to the required mailbox. ### 5. Confirm the From identity and Send As permission Keep From equal to `alerts@example.com` for the first test. If the application authenticates as `service@example.com` but sends as `alerts@example.com`, grant the narrow Send As permission through the authorized Exchange workflow. Microsoft says the service returns `5.7.60` when the authenticated account lacks that permission in this client-submission scenario ([Microsoft client submission](https://learn.microsoft.com/en-us/troubleshoot/exchange/email-delivery/fix-issues-with-printers-scanners-and-lob-applications-that-send-email-using-off)). ### 6. Send one traceable test Use subject `SMTP validation 2026-08-25 14:30 UTC` and include `o365-smtp-630184` in a non-secret diagnostic line. Record connection time, server response, authenticated mailbox, From, recipient, and application version. Never record a password, access token, client secret, or private message body. ## How does the setup affect DMARC? SMTP AUTH controls application access to Exchange Online. DMARC evaluates whether SPF or DKIM authentication aligns with the visible From domain. One can succeed while the other fails. Microsoft's SPF guidance says most Microsoft 365 organizations that send only through the service use an SPF policy containing `include:spf.protection.outlook.com`. The full illustrative value is `v=spf1 include:spf.protection.outlook.com -all`, but a domain with other senders must combine all authorized sources into one SPF record and remain within the `10`-lookup limit ([Microsoft SPF configuration](https://learn.microsoft.com/en-us/defender-office-365/email-authentication-spf-configure)). Do not publish a second SPF record or copy a policy that omits real senders. Microsoft 365 DKIM uses two selector CNAMEs so one selector can sign while the other supports rotation. Current Microsoft documentation tells administrators to retrieve tenant-specific CNAME targets from Defender or Exchange Online PowerShell and warns against copying the example values because newer domains can use a different target format ([Microsoft DKIM configuration](https://learn.microsoft.com/en-us/defender-office-365/email-authentication-dkim-configure)). Never use another tenant's targets. RFC 9989 Section 4.4 define alignment and the DMARC pass condition: at least one supported mechanism must authenticate and align with the RFC5322 From domain ([RFC 9989](https://www.rfc-editor.org/rfc/rfc9989.html#section-4.4)). A message accepted from `alerts@example.com` can still fail DMARC if the observed SPF and DKIM identifiers do not align with `example.com`. ## How do I validate the setup? ### Check DNS values Query the single SPF record, both Microsoft DKIM selector CNAMEs, and `_dmarc.example.com` from public resolvers. Compare tenant-specific targets exactly. DNS presence does not prove the application used the intended path or that Microsoft signed the message. ### Check vendor and mailbox status Confirm the approved mailbox exists, SMTP AUTH state matches the documented exception, tenant policy permits the chosen method, and Send As permission exists only where required. For any basic-authentication exception, record who approved it, which OAuth-capable replacement will take over, and the expiry date from Microsoft's verified current retirement timetable. ### Check the delivered message headers Open the raw source and use the receiver-added `Authentication-Results`. RFC 8601 Section 1.2 explains the receiver trust boundary; do not trust a field merely because it is present ([RFC 8601, Section 1.2](https://www.rfc-editor.org/rfc/rfc8601.html#section-1.2)). Confirm the actual `smtp.mailfrom`, DKIM `header.d`, visible `header.from`, and reported DMARC result. Use Palisade's [Email Header Analyzer](/tools/email-header-analyzer) to parse supplied headers; it cannot inspect Entra credentials or tenant policy. ### Check DMARC reporting and delivery Confirm the authorized Microsoft source appears in aggregate DMARC data for the visible From domain. Send the same controlled test to an external mailbox and examine acceptance, authentication, folder placement, and any enhanced status code. The [Office 365 DMARC setup guide](/learning/how-do-you-enable-dmarc-for-microsoft-365) covers policy deployment, while [DKIM for Office 365](/resources-post/dkim-for-office-365) covers signing in more depth. If the message-level test works but the tenant still lacks source-wide visibility, Palisade's DMARC Agent can organize aggregate DMARC evidence for the domain. Smart DNS Deployment can write only DNS records a human approves. It does not change Exchange, Entra, mailbox, or SMTP AUTH settings and cannot guarantee placement. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=esp_setup&utm_content=office-365-smtp-settings) after the controlled send establishes that monitoring is the next gap. ## Troubleshooting ### The server rejects authentication Confirm the server and STARTTLS settings, then determine whether security defaults, organization-level SMTP AUTH, mailbox state, or authentication policy blocks the chosen method. Do not repeatedly retry a secret or weaken tenant policy without an approved exception. ### Send As returns 5.7.60 Keep the From equal to the authenticated mailbox or grant the narrow Send As permission to the required identity. Do not grant broad impersonation rights to solve one sender mismatch. ### The client is throttled Microsoft documents `30` messages per minute, `10,000` recipients per day, and up to `3` concurrent SMTP connections for client submission. Its SMTP improvements page shows `432 4.3.2 Concurrent connections limit exceeded` for excess concurrency and a `SubmissionQuotaExceededException` after the recipient limit ([Microsoft SMTP submission limits](https://learn.microsoft.com/en-us/troubleshoot/exchange/send-emails/smtp-submission-improvements)). Queue and pace mail rather than opening more connections. ### The message sends but DMARC fails Compare the From domain with `header.d` and `smtp.mailfrom`. Verify the Microsoft DKIM selectors and the actual return path. Do not relax DMARC policy as a substitute for repairing an unaligned sender. ### The message is accepted but does not land as expected Check the exact recipient outcome, service responses, authentication, reputation, consent, and message purpose. Exchange acceptance is not an inbox guarantee, and changing the port will not repair reputation or targeting. ## When does this setup not apply? The worked procedure covers client SMTP submission. A production SMTP relay still needs a deliberately scoped Exchange Online connector, and direct send still needs a controlled internal-recipient test. This guide does not cover on-premises Exchange connectors, high-volume email architecture, consumer Outlook.com accounts, or software that cannot meet the tenant's transport and authorization policy. ## Sources and further reading - [Microsoft client SMTP submission settings](https://learn.microsoft.com/en-us/troubleshoot/exchange/email-delivery/fix-issues-with-printers-scanners-and-lob-applications-that-send-email-using-off) - [Microsoft SMTP AUTH controls](https://learn.microsoft.com/en-us/exchange/clients-and-mobile-in-exchange-online/authenticated-client-smtp-submission) - [Exchange Online limits](https://learn.microsoft.com/en-us/office365/servicedescriptions/exchange-online-service-description/exchange-online-limits) - [Microsoft SPF configuration](https://learn.microsoft.com/en-us/defender-office-365/email-authentication-spf-configure) - [Microsoft DKIM configuration](https://learn.microsoft.com/en-us/defender-office-365/email-authentication-dkim-configure) - [RFC 9989, DMARC](https://www.rfc-editor.org/rfc/rfc9989.html) - [RFC 8601, Authentication-Results](https://www.rfc-editor.org/rfc/rfc8601.html) ## Frequently asked questions ### Is smtp.office365.com the Office 365 SMTP server? Yes. Microsoft documents `smtp.office365.com` for authenticated client SMTP submission to Exchange Online. Other Microsoft sending methods use different endpoints and authorization models. ### Should Office 365 SMTP use port 587? Yes. Microsoft recommends port `587` with STARTTLS for client submission and also lists port `25`. Match the documented method and transport rather than substituting port `465` from another provider. ### Can Office 365 SMTP use OAuth? Yes. Microsoft documents OAuth support for SMTP AUTH. The tenant registration, permissions, and token flow are account-specific, so follow the application's current Microsoft integration instructions. ### Does enabling Authenticated SMTP override security defaults? No. Microsoft says security defaults can disable SMTP AUTH, and authentication policies can block basic authentication. A mailbox checkbox does not silently override every tenant control. ### What are the three Office 365 SMTP sending methods? Microsoft documents client SMTP submission, direct send, and SMTP relay. Client submission authenticates as a mailbox. Direct send has no mailbox sign-in and is limited to recipients in the organization. SMTP relay uses an approved connector instead of a mailbox sign-in and can send to external recipients. ### Can I send as a shared mailbox after authenticating as a user? Yes, when the authenticated account has the required Send As permission and the method is supported. Validate the delivered From, SPF, DKIM, and DMARC results rather than assuming permission creates alignment. --- # Phishing email examples: ten patterns to inspect Canonical: https://www.palisade.email/learning/phishing-email-examples > Review ten realistic phishing email examples, compare their warning signs, and learn how to verify suspicious requests without using the message. Phishing email examples are most useful when they teach you what to verify, not which phrases to memorize. The ten fictional messages below use different pretexts, but each exposes evidence you can check safely: the sender identity, the requested action, the real destination, and whether the request matches activity you can confirm elsewhere. None of the examples includes a live domain, working credential form, or malicious attachment. ## Quick takeaways - A familiar display name or logo does not authenticate the person or company behind a message. - Urgency matters when it pressures you to bypass a normal approval or verification channel. - Inspect the destination separately from the visible link text, but do not visit a suspicious destination. - Confirm invoices, account alerts, file shares, and support requests through a channel you already trust. - Report suspected phishing through your organization's process instead of replying to the sender. The [email threats learning hub](/learning/threats) covers related threats. This page stays with the narrower question: what do phishing attempts look like when the pretext changes? ## How should I read these phishing examples? Treat each example as a small evidence exercise. The wording is not a detection rule. Good writing can be malicious, and awkward writing can be legitimate. The US National Institute of Standards and Technology describes phishing as deceptive messages designed to obtain sensitive information or induce harmful action. Its current guidance highlights unexpected requests, urgency, suspicious sources, and requests for sensitive information as useful signals ([NIST phishing guidance](https://www.nist.gov/itl/smallbusinesscyber/guidance-topic/phishing)). The sender line and the message body are claims. They become more credible only when independent evidence supports them. That may include a purchase visible in an account you opened yourself, a colleague reached through a known directory number, or trusted receiver-added authentication results. Even then, authentication does not prove that every request or link is safe. For a line-by-line walkthrough of one message, use the existing [phishing scam email example](/learning/phishing-scam-email-example). ## Ten worked phishing email examples All names, domains, ticket numbers, and amounts below are invented. Domains ending in `.invalid` cannot be registered for normal Internet use. ### Invoice bank-change example ```text From: Northline Supply Subject: Updated remittance instructions for invoice 48172 The USD 18,740 balance is due today. Our bank changed this morning. Use the attached instructions and confirm by reply before 3:00 PM. ``` The concrete values make the message feel operational, but they also give the recipient something to verify. The sender domain differs from the established supplier domain. A same-day bank change and reply confirmation bypass the procurement record. The safe action is to call the supplier using the number already stored in the vendor system and compare invoice `48172`, the amount, and approved bank details. Do not use a number in the email. ### Account suspension example ```text From: Storage Security Subject: Your account will close in 27 minutes We blocked a sign-in from 192.0.2.44. Review activity now: https://files-login.invalid/session/7391 ``` This example combines a countdown, an unfamiliar domain, and a sign-in claim. `192.0.2.44` is in a documentation address range here, so it does not identify a real attacker. Open the service from a bookmark or a typed official address, then review its security activity. The Federal Trade Commission advises contacting the company using a phone number or website you know is real rather than the contact details in an unexpected message ([FTC phishing guidance](https://consumer.ftc.gov/articles/how-recognize-avoid-phishing-scams)). ### Executive gift-card example ```text From: Maya Chen, CEO Subject: Need a private favor before the board call Buy eight USD 200 gift cards. Send the codes to me and do not involve Finance. ``` The decisive clue is not the executive title. It is the attempt to remove the normal approver and move value through a hard-to-reverse channel. Verify the request using the corporate directory, and follow the organization's payment policy. This is also an example of spear phishing because the message targets a role and imitates a named leader rather than sending a generic account alert. ### Shared-file example ```text From: Priya shared "Q4 Compensation Draft" Reply-To: access@document-share.invalid Open secure document Visible label: company.share.example Actual destination shown by the mail client: document-share.invalid ``` The pretext uses confidentiality to discourage questions. The visible label and actual destination disagree, and the unexpected document asks the recipient to sign in. Contact Priya in the normal collaboration tool or open the organization's approved file service directly. Do not test the suspicious link. A padlock would only describe the connection to that destination, not whether the destination belongs to the expected company. ### Fake support-call example ```text From: Apple Account Support Subject: Case 630184 requires phone verification Call +1 202-555-0147 and read the six-digit code sent to your device. ``` The message asks the recipient to transfer an authentication factor to an unsolicited caller. The brand name does not make that safe. Open the vendor's official support route independently and check whether case `630184` exists. Never provide a password or one-time code because an inbound message claims support needs it. The [Apple phishing email guide](/learning/apple-phishing-email) applies that verification pattern to current Apple guidance. ### Package redelivery-fee example ```text From: Parcel Updates Subject: Delivery held: pay USD 1.82 by 6:00 PM We could not deliver package PR-48172. Pay the redelivery fee now: https://parcel-redelivery.invalid/PR-48172 ``` The small fee makes the request easy to dismiss as harmless, but the payment form can collect card and address details. The tell is the missing connection to an order you can confirm, paired with an unfamiliar destination and a same-day deadline. Open the retailer or carrier from your real order history and compare the tracking number there. Do not enter the number from this message into its link. ### Payroll tax-document example ```text From: People Operations Subject: Reissue your tax statement before payroll closes Upload your tax ID and banking details to receive the corrected statement: https://hr-documents.invalid/reissue ``` This pretext asks for identity and bank data through a new portal instead of the normal payroll system. The tell is the process change: a tax-statement correction should match an existing HR notice, case, or employee-portal task. Open the payroll portal from a saved address or contact HR through the corporate directory. Do not use the form or reply with personal information. ### Unsolicited job-offer example ```text From: Recruitment Desk Subject: Remote analyst offer: onboarding required today You were selected without an interview. Upload photo ID and banking details: https://remote-careers.invalid/onboarding ``` The giveaway is the missing hiring history. There was no application, interview, named recruiter, or offer inside a hiring system the recipient already used. The message jumps straight to high-value identity and banking data. Look up the employer's careers page independently and contact its published recruiting channel. Do not send documents to the reply address or upload them through the message. ### Email-quarantine release example ```text From: Mail Security Subject: Three messages will be deleted from quarantine Release held messages before 4:15 PM: https://message-release.invalid/quarantine ``` The message imitates a security control to create urgency around a credential prompt. The tell is that the release destination is outside the organization's known mail-security service, and the claimed held messages are not visible anywhere else. Open the approved quarantine portal from the normal bookmark or ask the mail administrator to verify the notice. Do not sign in through the email. ### Required software-update example ```text From: IT Operations Subject: Critical VPN update required before your next login Install VPN_Update.zip and disable endpoint protection if prompted. ``` The attachment and the request to weaken endpoint protection give this example away. Real update notices should match the organization's managed software channel, change record, or service-status notice. Check the device-management portal or contact IT through the help desk address already published inside the organization. Do not open the attachment or disable a security control to make it run. Compare the evidence instead of memorizing one phrase. ![Matrix comparing ten fictional phishing pretexts across sender, request, destination, and urgency evidence](/images/editorial/phishing-email-examples/phishing-pattern-matrix.svg "1200x1036") *Source: Palisade deterministic summary based on [NIST phishing guidance](https://www.nist.gov/itl/smallbusinesscyber/guidance-topic/phishing).* Use the matrix to choose a safe verification step. When an example turns on a link, the [Palisade phishing link checker](/tools/phishing-link-checker) inspects that URL before you open it. It reports public threat signals for the destination; it cannot prove a site is safe, and it cannot inspect the message itself. ## What evidence deserves the most weight? A single misspelling deserves less weight than a request that conflicts with known business context. Start with facts the sender cannot control inside the message: an existing purchase record, a supplier's stored bank details, the security activity visible after you open an account independently, or a known colleague reached outside email. ![Four-step flow for verifying a suspicious email outside the message by checking independent records, known services, trusted channels, and the reporting path](/images/editorial/phishing-email-examples/phishing-verification-flow.svg "1200x760") *Source: Palisade deterministic workflow based on [NIST phishing guidance](https://www.nist.gov/itl/smallbusinesscyber/guidance-topic/phishing).* Header evidence can help a security team determine which domain authenticated the message, but it has limits. RFC 8601 Section 1.2 explains that an `Authentication-Results` field is meaningful only within the receiver's trust boundary; a sender can insert an untrusted lookalike field ([RFC 8601, Section 1.2](https://www.rfc-editor.org/rfc/rfc8601.html#section-1.2)). A message can also pass SPF or DKIM for an attacker-controlled domain. That is why [phishing can pass SPF and DKIM](/learning/why-do-phishing-emails-pass-spf-and-dkim) without becoming legitimate. ## When do these examples not apply? These patterns do not establish that every urgent request, changed invoice, shared file, or support email is malicious. Real teams sometimes change banks, systems send genuine alerts, and colleagues share sensitive documents. The correct conclusion is "unverified," followed by independent verification, not an automatic accusation. The examples also do not replace an incident-response process. If someone entered credentials, disclosed a code, opened an attachment, changed payment details, or sent money, stop the example comparison. Contact the authorized security or finance team using the established emergency path. Preserve the original message and relevant device or account evidence. Do not forward an active attachment to people who do not need it. ## What should I do with a suspicious example in my inbox? Stop interacting with the message. Capture the observable details your organization requests, such as sender, subject, time, claimed transaction, and visible destination. Then use the mail provider's phishing report control and the organization's security channel. The FTC also accepts reports at ReportFraud.ftc.gov and directs suspicious email to the Anti-Phishing Working Group at `reportphishing@apwg.org` ([FTC reporting guidance](https://consumer.ftc.gov/articles/how-recognize-avoid-phishing-scams)). Do not reply to challenge the sender. A reply can confirm that the address is active and keeps the conversation inside the attacker's chosen channel. If the message is merely unsolicited bulk advertising without deception, the [spam versus phishing guide](/learning/spam-vs-phishing) explains why the reporting path can differ. ## Sources and further reading - [NIST phishing guidance](https://www.nist.gov/itl/smallbusinesscyber/guidance-topic/phishing) - [FTC: How to recognize and avoid phishing scams](https://consumer.ftc.gov/articles/how-recognize-avoid-phishing-scams) - [RFC 8601, Authentication-Results](https://www.rfc-editor.org/rfc/rfc8601.html) ## Frequently asked questions ### Are phishing emails always badly written? No. Some are polished, localized, and copied from real messages. Grammar is weak evidence by itself. Give more weight to an unexpected request, an independently observed domain mismatch, an attempt to bypass procedure, or activity that you cannot confirm in the real account. ### Can a phishing link use HTTPS? Yes. HTTPS can encrypt the connection to a malicious site. It does not prove that the destination belongs to the company named in the email. Verify the hostname and open the expected service independently rather than visiting the message's link. ### Is the executive request an example of spear phishing? Yes. It targets a particular role and imitates a named executive with a request shaped around organizational context. The safe response is still evidence-based verification through a known channel and the normal payment or approval process. ### Should I forward a phishing email to a coworker for a second opinion? No. Use the organization's approved reporting method so the original message and headers are preserved safely. Ordinary forwarding can change context, spread a dangerous attachment, or expose information to someone who does not need it. ### Can a spam filter stop every phishing example? No. Filters reduce risk but cannot determine the truth of every business request or stop every newly created domain and compromised account. People still need a trusted verification path for unusual payments, credential prompts, account alerts, and confidential file shares. --- # What is a phishing email? Meaning and safe response Canonical: https://www.palisade.email/learning/what-is-a-phishing-email > A phishing email impersonates someone you trust to make you act: click, pay, or hand over credentials. Verify the request outside the message first. A phishing email is a deceptive message that impersonates a person, organization, or service to make the recipient take an unsafe action. The action may be clicking a link, opening an attachment, entering credentials, sharing a verification code, calling a phone number, changing payment details, or sending money. The safest response is to stop and verify the claim through a separate channel you already trust. ## Quick takeaways - Phishing describes the deceptive request; a malicious link is only one possible method. - The message usually borrows trust, urgency, or an expected workflow. - A polished design or authenticated sender does not prove the request is honest. - Verify the claimed event through an app, account, record, or person reached separately. - Report the message through your mailbox and the impersonated organization's current path. - Begin account, payment, or device recovery if you already interacted. ## What does phishing email mean? The meaning of a phishing email comes from its purpose: it tries to move the recipient from a believable claim into an action that benefits the sender. The claim might be an account problem, payment, shared file, refund, security alert, tax notice, delivery issue, job opportunity, or request from a manager. CISA defines phishing as an online scam that entices users to share private information using deceitful or misleading tactics ([Malware, Phishing, and Ransomware](https://www.cisa.gov/topics/cyber-threats-and-advisories/malware-phishing-and-ransomware)). In practice the action a phishing email asks for is often broader than disclosure: approving a payment, opening a file, or entering a one-time code. Email is one delivery channel. Similar deception can arrive by text, phone, social media, or a collaboration platform. The definition is broader than "an email with a bad link." A phishing email can ask for a reply, payment, phone call, attachment, software installation, QR-code scan, approval prompt, or change to financial details. It can also send the recipient into a real service while misrepresenting who initiated the request. The sender does not need to copy a brand perfectly. It only needs to create enough confidence or urgency for the recipient to skip independent verification. The [phishing email examples page](/learning/phishing-email-examples) shows how different pretexts appear. The broader [what is phishing guide](/learning/what-is-phishing) covers non-email channels and attack types. This page stays with what the email term means and how to classify the message in front of you. ## What makes a message a phishing email? A phishing email has two essential parts: a deceptive claim and a requested action. The claim gives the recipient a reason to trust the sender or feel responsible for an event. The action moves the recipient toward disclosing information, granting access, sending money, or opening an unverified destination. The trust cue may be a known display name, brand logo, existing email thread, service notification, invoice format, signature, or personal detail. Typical pressure cues include a deadline, threatened closure, unfamiliar charge, or request from someone with authority. None of those details can verify the sender because they all came from the same message. Classify the action rather than the tone. A message can be calm and still ask for a password. It can contain no link and still request a fraudulent payment by reply. It can describe a genuine event and still direct the response to a different number or destination. The unsafe action, not poor grammar or dramatic wording, is the useful boundary. Use channel separation to test it. If an email says a bank transaction occurred, open the bank app. If it says a coworker shared a file, contact the coworker through an established channel. If it says an account changed, open the account through a saved bookmark. The email can state the claim, but it cannot authenticate itself. ## What does the term not prove? A phishing-email label describes the message's deceptive purpose. It does not, by itself, prove which person sent the message, whether a particular account was compromised, whether malware ran, or whether money left an account. Those questions require separate evidence. A suspicious email is not automatically confirmed phishing. It may be a legitimate message with weak context, an unwanted promotion, a mistaken recipient, or a real alert that arrived unexpectedly. Treat uncertainty as a reason to stop, then use outside evidence to decide what happened. The label also does not make every element in the email false. A listed charge, document name, or account event may be real while the reply address, phone number, or payment instruction is not verified. Handle the underlying event through the account or relationship you reached independently. That distinction matters after interaction. Clicking, entering a password, approving a prompt, sharing payment data, opening a file, and installing software are different exposures. Record what happened instead of using "I was phished" as the only incident description. ## Does phishing email require a fake sender or harmful file? No. A phishing email may imitate a sender, use a lookalike address, arrive through an abused account, or use a real service to carry an unverified request. Sender identity is one piece of evidence; the requested action and its business context still need verification. A harmful file is also optional. A message can seek a password through a form, request a verification code by reply, direct the recipient to call a number, or ask finance to replace payment details. Conversely, an unexpected attachment may be risky without being enough evidence to identify the sender's intent. Use the narrower term that matches the evidence. If the only known fact is that the mail was unwanted and sent in bulk, the [spam vs phishing guide](/learning/spam-vs-phishing) explains that boundary. If the message attempted to induce an unsafe action through deception, phishing is the useful classification. If a file executed or an account changed, describe that exposure separately as well. ## How do I recognize a phishing email? Recognition comes down to the request, not the design. A phishing email asks for a credential, a payment change, a code, or a file action, and it wants that action now. Treat the pressure itself as the signal. The full checklist, including how to read a sender address and a link destination without visiting it, is on [how to spot a phishing email](/learning/how-to-spot-a-phishing-email). ## How do I verify a suspected phishing email? Verify outside the message. Open the service yourself through its app, a bookmark, or an address you type, and check whether the claim is waiting for you there. Nothing inside a suspicious email can confirm that email. The step-by-step verification sequence is on [how to spot a phishing email](/learning/how-to-spot-a-phishing-email), and you can inspect a destination safely with the [phishing link checker](/tools/phishing-link-checker). ## How should I report and respond to phishing? Report through the control your mail client provides, then tell whoever owns the mailbox if it is a work account. If you already entered something, containment comes before reporting. Destination-by-destination guidance is on [where to report a phishing email](/learning/report-email-phishing-scams), and recovery steps are on [what to do if you clicked on a phishing link](/resources-post/what-to-do-if-you-clicked-on-a-phishing-link). ## Why can phishing pass email security checks? Email authentication answers a narrower question than phishing detection. [SPF evaluates whether a sending system is authorized for a particular envelope identity](https://www.rfc-editor.org/rfc/rfc7208). [DKIM verifies a cryptographic signature and its signing domain](https://www.rfc-editor.org/rfc/rfc6376). [DMARC checks whether an SPF or DKIM pass aligns with the domain visible in the From address and publishes a requested policy for failures](https://www.rfc-editor.org/rfc/rfc9989.html). An attacker can register a lookalike domain and authenticate it correctly. A compromised account can send through legitimate infrastructure. A real collaboration service can deliver an unauthorized document request. Authentication can provide useful identity evidence without proving that the message's content, link, or business request is safe. The Palisade guide on [why phishing emails pass SPF and DKIM](/learning/why-do-phishing-emails-pass-spf-and-dkim) explains that technical boundary. Palisade's role belongs at domain authentication, not at deciding whether a consumer transaction or private account alert is genuine. ## How should I explain the term to someone else? Use this definition when you need to explain the term: > A phishing email is a deceptive message that impersonates a trusted person or organization to make the recipient reveal information, send money, grant access, or take another unsafe action. The definition has four parts: deception, borrowed trust, requested action, and possible harm. A suspicious email may not show all four clearly at first. That uncertainty is enough to stop and verify the claim independently, but it is not evidence about who operated the sender account. For an incident report, add the observed action: "The message asked for my password," "I approved a sign-in," or "I opened the attachment." That wording is more useful than the label alone because it tells the account, payment, or device owner which recovery branch may apply. ## Sources and further reading - [CISA phishing guidance](https://www.cisa.gov/topics/cyber-threats-and-advisories/malware-phishing-and-ransomware) - [RFC 7208: Sender Policy Framework](https://www.rfc-editor.org/rfc/rfc7208) - [RFC 6376: DomainKeys Identified Mail Signatures](https://www.rfc-editor.org/rfc/rfc6376) - [RFC 9989: Domain-based Message Authentication, Reporting, and Conformance](https://www.rfc-editor.org/rfc/rfc9989.html) - [Palisade phishing email examples](/learning/phishing-email-examples) ## Frequently asked questions ### Is a phishing email always trying to steal a password? No. It may seek money, identity data, a verification code, remote access, a signature, a payment change, or an attachment open instead. ### Can a phishing email come from a real account? Yes. An abused legitimate account or service can deliver a harmful request. Verify the business context and requested action through another channel. ### Is spoofing the same as phishing? No. Spoofing imitates an identity signal. Phishing is the deceptive request. A phishing email may use spoofing, but it can also use a lookalike or compromised account. ### Does clicking a phishing link mean my account is compromised? Clicking tells you that the link was opened, but not which later action occurred. Record what you entered, approved, downloaded, or installed, then follow the matching recovery path. ### Can SPF, DKIM, or DMARC prove an email is safe? No. They provide domain-authentication evidence. They do not confirm that the message content, payment request, document, or link is honest. --- # Yahoo phishing email: how to check it safely Canonical: https://www.palisade.email/learning/yahoo-phishing-email > Yahoo will not ask for your password or account key by email. Check recent activity in Yahoo Account Security, then report the message and delete it. Treat an unexpected Yahoo email as unverified until you check the claimed sign-in, security change, or mailbox issue through a Yahoo account you open independently. Do not use the message's sign-in button, QR code, attachment, reply address, or phone number. A Yahoo logo, familiar purple design, or urgent warning that mail will stop cannot prove the request is genuine. ## Quick takeaways - Open Yahoo independently and review account activity or security settings. - Do not enter a password or verification code after following an unexpected link. - A mailbox closure, quota, or password-expiry claim should be checked in the account. - Confirm recovery-detail changes through the account rather than the email. - Report the message through your mailbox and Yahoo's current official help path. - Change exposed credentials and review sessions promptly if you already signed in. ## What does a Yahoo phishing email look like? Yahoo impersonation commonly uses the mailbox itself as the source of urgency. A message may claim that the account will close, storage is full, a password expired, a new sign-in needs review, a security method changed, or the recipient must upgrade the mailbox. It may also claim that messages are being held or that recovery details must be confirmed. The requested action is usually a sign-in, verification-code entry, QR-code scan, attachment, or form. Some messages ask the reader to reply with personal details or call a number. The topic sounds plausible because email accounts do require security and recovery management, but the message is not the right place to verify its own claim. Yahoo's [security-change help](https://help.yahoo.com/kb/account/understanding-security-yahoo-account-sln37259.html) says Yahoo sends alerts when two-step verification is turned on or off or when the verification method changes. If you receive such an alert unexpectedly, inspect the account through a separately opened Yahoo session. Do not treat the email button as the only path to that review. These patterns do not imply that Yahoo was breached or at fault. The service is being impersonated, or a real account feature may be referenced out of context. For wider examples, see the [phishing email examples page](/learning/phishing-email-examples). This guide focuses on Yahoo mailbox access and account security. ## Which Yahoo sender and link clues matter? Expand the sender details and read the complete address after the final `@`. A display name such as "Yahoo Security" is only text selected by the sender. Extra words, spelling substitutions, unrelated domains, and a different Reply-To address support suspicion. Do not turn a familiar address into a permanent allowlist. The message still needs to match a real account event, and the actual destination behind a button still needs scrutiny. An email can also contain a real Yahoo help link beside a fraudulent sign-in link, so inspect the destination tied to the action. Preview links without opening them. Do not infer ownership because `yahoo` appears somewhere in a longer hostname or URL path. Compare the complete destination with the Yahoo route you opened independently. Treat a QR code as another unverified route supplied by the message. Do not scan one to restore a mailbox or confirm a sign-in. Open the Yahoo app or account through your normal route. ## How do I verify a Yahoo security alert? Open a fresh browser window, saved bookmark, or the installed Yahoo app. Sign in only through that route. Use whatever recent-activity, security-method, recovery, or session evidence the account makes available. Compare the message with the relevant account evidence: - For a new sign-in, check whether the time, device, and location match an action you initiated. - For a security-method change, review the current two-step verification and recovery configuration. - For a password warning, use the account's own security flow rather than the email. - For a mailbox or storage claim, inspect the mailbox state after opening it independently. - For a recovery-address change, confirm the address and remove anything unfamiliar. Yahoo documents several two-step verification methods in its [current help guidance](https://help.yahoo.com/kb/add-two-step-verification-extra-security-sln5013.html). The options visible to an account can vary. That is another reason to use the live account rather than judging a screenshot or remembered template. If a real issue appears, handle it inside the independently opened account. Do not return to the email button after the claim is confirmed. ## How do I handle a mailbox closure or upgrade claim? Do not sign in through the message to prevent a supposed closure. Open Yahoo through your established route and look for an account-level notice. A sender who invents the deadline also controls the proposed fix, so the email cannot independently confirm either one. Treat claims about quota, storage, or held messages the same way. The mailbox itself should show the relevant state. An attachment or form asking for credentials is not needed to inspect that state. If the message says an administrator or support agent will call, do not rely on the supplied number. Locate Yahoo's current help path independently. Do not install remote-access software or share a code because a person claims it will restore email. If the mailbox came from an internet provider that runs its mail on Yahoo, recovery may run through that provider rather than through Yahoo directly, so start from the account you actually sign in to. ## How do I report a Yahoo phishing email? Locate the reporting process currently documented for the mailbox that received the message. Do not assume an old menu path, universal button, or forwarding address. If it arrived at a work account, follow the organization's security process too. To notify Yahoo or seek account help, open Yahoo Help independently and locate the current security or abuse instructions. Do not guess a reporting address and do not use a form linked from the suspected message. Follow the documented retention or deletion instructions and do not forward active links or attachments to friends. The [guide to reporting email phishing scams](/learning/report-email-phishing-scams) explains how to select a verified reporting route. ## What if I already entered my Yahoo password? Use a trusted device and sign in through a Yahoo route you opened independently. Change the exposed password and replace it anywhere else you reused it. Then use the current account-security and recovery options Yahoo exposes for that account. If you shared a verification code, approved a sign-in, or scanned a QR code, state that in any report. These actions are distinct from typing a password, so include them when following Yahoo's current account-recovery process. If you opened an attachment or installed software, follow the applicable device incident process. Tell the reviewer exactly what you opened or installed and which device was involved. The [recovery guide after clicking a phishing link](/resources-post/what-to-do-if-you-clicked-on-a-phishing-link) separates password, session, device, and linked-account actions. ## Why did a Yahoo phishing email reach me? Delivery does not mean the message is authentic. Domain-authentication evidence still cannot determine whether a mailbox-closure warning or security request is honest. [DMARC uses a passing SPF or DKIM result only when it aligns with the domain visible in the From address, then applies the published requested policy for failures](https://www.rfc-editor.org/rfc/rfc9989.html). Treat that as domain-identity evidence, then verify the mailbox warning or security request inside the independently opened account. The Palisade explanation of [why phishing can pass SPF and DKIM](/learning/why-do-phishing-emails-pass-spf-and-dkim) covers the boundary. The safe account decision still comes from an independently opened Yahoo session and the activity visible there. ## A safe Yahoo email decision rule Name the claimed account event: sign-in, security change, recovery update, storage problem, closure, or upgrade. Then discard the message's route to the solution. Open Yahoo through the app, bookmark, or address you normally use and look for the same event. If nothing matches, report the email and leave it unused. If the account shows a real issue, resolve it inside that account. If you already exposed credentials, a code, session approval, recovery method, or device access, complete the matching recovery steps immediately. This rule works whether the message is badly written or visually perfect. It also prevents a real but unrelated Yahoo alert from being used to legitimize a fraudulent link. ## Sources and further reading - [Yahoo Help: Understanding security changes on your Yahoo account](https://help.yahoo.com/kb/account/understanding-security-yahoo-account-sln37259.html) - [Yahoo Help: Add two-step verification for extra security](https://help.yahoo.com/kb/add-two-step-verification-extra-security-sln5013.html) - [CISA: Recognize and report phishing](https://www.cisa.gov/secure-our-world/recognize-and-report-phishing) - [RFC 9989: Domain-based Message Authentication, Reporting, and Conformance](https://www.rfc-editor.org/rfc/rfc9989.html) - [Palisade phishing reporting guide](/learning/report-email-phishing-scams) ## Frequently asked questions ### Does Yahoo send security-alert emails? Yes. Yahoo's help says it sends alerts for specified security-method changes. Review any unexpected alert through an account session you opened independently. ### Should I click a Yahoo link to stop my mailbox from closing? No. Open Yahoo through your normal app, bookmark, or typed address and check the account state there. ### Can I trust a Yahoo email if the sender address looks right? No. A familiar address is one clue, not proof that the link or account claim is safe. Verify the event in the account. ### What if I shared a Yahoo verification code? Review sessions, recovery details, and security methods through a trusted account session, change the password, and report the unexpected approval or code request. ### Is reporting the message enough after my account was accessed? No. Reporting handles the email. Account recovery, session review, linked-account protection, and device response are separate tasks. --- # Dots in Gmail Addresses: Do They Matter? Canonical: https://www.palisade.email/learning/dots-in-gmail-address > No, dots do not matter in a personal Gmail address: every dotted or period variant reaches one inbox. Work and school Gmail addresses are the exception. Dots in a personal Gmail address, also called periods, do not create a different mailbox. Google says `jane.smith@gmail.com` and `janesmith@gmail.com` go to the same inbox when the account ends in `@gmail.com`. That rule does not apply to every email provider or to Gmail addresses issued by a work, school, or other organization. Keep the address a person entered, and normalize a separate comparison key only when you need to detect duplicate personal Gmail accounts. ## Quick takeaways - Personal `@gmail.com` addresses ignore dots in the part before `@`. - A dotted and undotted personal Gmail address are not two separate Gmail accounts. - Work, school, and organization addresses hosted by Google can treat dots as meaningful. - Other email providers can assign different mailboxes to addresses that differ only by dots. - Store the original address for delivery, consent, support, and audit records. - If account uniqueness matters, compare a separate Gmail-specific normalized value. ## How Gmail handles dots in an address [Google's Gmail address guidance](https://support.google.com/mail/answer/7436150?hl=en) says dots do not matter in personal Gmail addresses. Mail addressed to dotted variants of the same characters reaches one account. Google also says another person cannot register a dotted version of an existing personal Gmail address. This is provider behavior, not a general email rule. [RFC 5322 permits dots inside an unquoted local part](https://www.rfc-editor.org/rfc/rfc5322.html#section-3.4.1), but the standard does not require every provider to merge dotted variants. The domain after `@` owns the mailbox behavior. That distinction matters when you compare the address with an [email alias](/learning/what-is-an-email-alias). A Gmail dot variant is the same personal Gmail account under Google's rule. An alias at another provider can be a separately configured address, even when it reaches the same inbox. ## When the answer changes Do not remove dots from every email address. Google limits this behavior to personal Gmail accounts and says dots can change an address used through work, school, or another organization. A provider at another domain may also treat `first.last@example.com` and `firstlast@example.com` as two different mailboxes. Use the complete domain as the first decision point: - For an address ending exactly in `@gmail.com`, a dot-insensitive comparison can help detect duplicate account records. Google's guidance covers `@gmail.com` only, so treat any other Google-hosted domain as outside the rule until its own operator confirms otherwise. - For a managed Google domain, preserve every character and follow that organization's address rules. - For any other domain, assume the dots matter unless the provider documents otherwise. - For delivery, keep using the address the person supplied. A comparison key is an internal control, not a replacement address. This rule also narrows the spoofing question. A dotted personal Gmail variant is not a second Gmail mailbox impersonating the first. A message can still misuse a display name, a different domain, or a compromised account, so investigate the complete sender and message evidence with the guidance on [whether email addresses can be spoofed](/learning/can-email-addresses-be-spoofed). ![Decision flow for preserving an email address while comparing personal Gmail dot variants](/images/editorial/dots-in-gmail-address/dots-in-gmail-address-normalization-flow.svg "1200x676") *Source: Palisade diagram based on [Google's Gmail address guidance](https://support.google.com/mail/answer/7436150?hl=en).* ## A safe comparison model for signup systems The risk appears when an application treats raw strings as separate users while Gmail delivers both strings to one inbox. That can let one person create multiple records in a system that intends to allow one account per email address. Gmail's delivery behavior is not an identity check, so it cannot be used as one. Keep two values when the business rule requires duplicate detection: ```text Original delivery address: jane.smith@gmail.com Comparison domain: gmail.com Comparison local part: janesmith Comparison key: janesmith@gmail.com ``` The original address remains the contact and consent record. The comparison key is only for an explicit uniqueness, abuse, or deduplication rule. Document that rule because changing it later can merge records that were previously separate. Do not silently rewrite historical addresses, merge user accounts, or transfer consent based on normalization alone. Confirm ownership through the application's normal verification process, then resolve conflicting records under an approved account-recovery policy. ## What to check before treating two addresses as one ### 1. Confirm the complete domain Normalize only addresses ending exactly in `@gmail.com`. Do not extend the rule to a lookalike domain, a subdomain, or a Google-hosted organization domain. ### 2. Preserve the submitted value Store the original address with its verification, consent, and account history. Use a separate comparison field so support staff can see what the person entered. ### 3. Compare existing records without merging them automatically Flag a collision for review. A matching comparison key does not tell you which account record, profile, entitlement, or consent state should win. ### 4. Test the policy with known variants Use a controlled personal Gmail account and confirm that your signup, password-reset, unsubscribe, and account-recovery paths behave consistently. This tests your application logic. It does not establish how another email provider treats dots. Address syntax and mailbox delivery are separate questions. If the input may be malformed or the domain may not accept mail, use the evidence order in [checking email address deliverability](/learning/check-email-address-deliverability). A syntax or MX check cannot decide who owns two application accounts. ## Sources and further reading - [Google: Dots don't matter in Gmail addresses](https://support.google.com/mail/answer/7436150?hl=en) - [Google: Getting someone else's mail](https://support.google.com/mail/answer/10313?hl=en) - [RFC 5322: Internet Message Format](https://www.rfc-editor.org/rfc/rfc5322.html) - [Email deliverability learning hub](/email-deliverability) ## Frequently asked questions ### Do dotted Gmail addresses go to different inboxes? No. For a personal address ending in `@gmail.com`, Google says dotted variants of the same local part reach the same inbox. ### Can someone register the dotted version of my Gmail address? No. Google says another person cannot register a dotted variant of an existing personal Gmail address. ### Should a signup form remove dots from every email address? No. Apply dot-insensitive comparison only to personal `@gmail.com` addresses. Preserve dots for managed Google domains and every other provider unless that provider documents the same behavior. ### Can dot normalization replace email verification? No. Normalization compares strings under a provider-specific rule. Verification confirms control of the address used for the account, and those are different checks. ### Why am I getting mail addressed to a dotted version of my address? Because you own every dotted variant of your personal Gmail address, so all of them land in your inbox. The usual cause is a sender mistyping someone else's address into a form. Google's guidance is to contact the sender and tell them the address was mistyped. ### Can someone sign up for services using a dotted version of my address? Yes. Google states plainly that it "can't prevent people from accidentally or maliciously using a dotted version of your address to sign up for subscription emails". The mail reaches you because the address is yours; unsubscribing or contacting the site is the remedy. ### Can Gmail dots create duplicate application accounts? Yes. An application that compares only raw address strings can treat dotted variants as separate records even though Gmail sends their mail to one inbox. That result depends on the application's own comparison logic. --- # ESMTPS: What It Means in an Email Header Canonical: https://www.palisade.email/learning/esmtps > ESMTPS in an email header means ESMTP crossed a TLS-protected hop. Learn how it differs from ESMTP, ESMTPSA, STARTTLS, and implicit TLS connections. ESMTPS in a `Received` email header means the receiving server says that message hop used Extended SMTP after a successful TLS negotiation. The final `S` means secure transport for that hop. `ESMTPA` means the client authenticated, while `ESMTPSA` records both TLS and authentication. ESMTPS is a trace keyword, not an SMTP command, a delivery verdict, or proof that every hop from sender to recipient used TLS. ## Quick takeaways - ESMTP is SMTP used with its extension framework. - ESMTPS records ESMTP over a TLS-protected hop. - ESMTPA adds client authentication without asserting TLS. - ESMTPSA records both TLS and client authentication. - The keyword describes one transfer recorded in one `Received` field. - A trace line is useful only when you trust the server that added it. ## Who is affected? Anyone reading raw headers during a delivery, security, or transport investigation can encounter ESMTPS. It commonly appears after `with` in a `Received` field, beside the servers, queue identifier, recipient, and timestamp for one SMTP handoff. The term belongs to the [email infrastructure](/learning/infrastructure) layer. It describes transport between mail systems. It does not report SPF, DKIM, or DMARC results, and it does not say whether the recipient placed the message in the inbox. ## What are the requirements? ### RFC 3848 registers the Received keywords [RFC 3848 registers seven new transmission types for the `with` clause of a Received header](https://www.rfc-editor.org/rfc/rfc3848.html#section-1). The registry already held `SMTP` and `ESMTP`; these are the four ESMTP forms worth reading: - `ESMTP`: Extended SMTP. - `ESMTPA`: Extended SMTP with successful client authentication. - `ESMTPS`: RFC 3848's wording is ESMTP "when STARTTLS is also successfully negotiated to provide a strong transport encryption layer". - `ESMTPSA`: both STARTTLS and SMTP AUTH successfully negotiated, the combination of `ESMTPS` and `ESMTPA`. These labels describe the receiving server's account of that hop. They do not replace the separate `Authentication-Results` field used for message-authentication methods. ### ESMTP begins with EHLO and advertised extensions [RFC 5321 defines EHLO and SMTP service extensions](https://www.rfc-editor.org/rfc/rfc5321.html#section-2.2). A client uses `EHLO` to identify itself and receive the server's extension list. An `ESMTP` trace label alone does not assert that TLS was used. For a protocol-level introduction, see [what SMTP is](/learning/what-is-smtp). The extra `S` in ESMTPS is the signal that narrows this particular trace to protected transport. ### TLS can be negotiated with STARTTLS [RFC 3207 defines STARTTLS for SMTP](https://www.rfc-editor.org/rfc/rfc3207.html). The server advertises the `STARTTLS` extension, the client requests it, and both sides begin a TLS negotiation. After TLS starts successfully, each side discards knowledge obtained from the earlier plaintext phase and the client sends `EHLO` again. ESMTPS records the resulting protected ESMTP hop. It does not state which cipher, certificate decision, or transport policy another server used unless the header includes separate details. ### A Received field covers one hop [RFC 5321 requires an SMTP server that accepts a message for relaying or delivery to insert a `Received` trace record](https://www.rfc-editor.org/rfc/rfc5321.html#section-4.4). Each server adds its own line, so a multi-hop message can contain several different transmission types. ```text Received: from outbound.example.net (outbound.example.net [192.0.2.25]) by mx.example.org with ESMTPS id ABC123 for ; Tue, 25 Aug 2026 00:30:00 +0000 ``` This is an illustrative header. It says `mx.example.org` recorded a TLS-protected ESMTP transfer from the named source. It does not prove that an earlier or later hop used TLS. ![Map of ESMTP, ESMTPA, ESMTPS, and ESMTPSA as combinations of TLS and client authentication](/images/editorial/esmtps/esmtps-transmission-types.svg "1200x676") *Source: Palisade diagram based on [RFC 3848 transmission types](https://www.rfc-editor.org/rfc/rfc3848.html#section-1).* ## When does the requirement take effect? RFC 3848 has registered these trace keywords since 2004. RFC 3207 defines the STARTTLS extension and RFC 5321 defines modern SMTP trace behavior. There is no mailbox-provider deadline attached to the meaning of ESMTPS. A server can still choose a different registered transmission type or add implementation-specific comments. Read the complete field and the surrounding trace chain instead of treating the keyword as the whole investigation. ## How do I implement the requirement? ### 1. Find ESMTPS inside a Received field Open the raw message source and locate the `Received` lines. The article on [what an email header is](/learning/what-is-an-email-header) explains the difference between sender-supplied message fields and server-added trace fields. ### 2. Identify the server that added the line Read the host after `by`. That server is asserting the transmission type for the connection it accepted. Decide whether it is part of infrastructure you trust before relying on the claim. ### 3. Separate TLS from client authentication Use the exact keyword. ESMTPS includes the TLS signal but not the authentication suffix. ESMTPSA includes both. Neither one is an SPF, DKIM, or DMARC result. ### 4. Compare every relevant hop Read the trace from the oldest trusted handoff upward. One ESMTPS line proves nothing about a different transfer. A message can cross a mix of protected and unprotected hops. ## How do I validate compliance? Use a controlled message sent through the production route. Export its raw source, keep the complete `Received` chain, and compare timestamps and hosts with the sending system's logs. Do not paste unredacted headers into a public ticket because they can contain email addresses, internal hostnames, IP addresses, and message identifiers. The [email header analyzer](/tools/email-header-analyzer) can structure the header for review. It cannot prove whether an untrusted trace line is truthful, inspect a TLS session that was not recorded, or guarantee that future hops will use the same transport. ## Sources and further reading - [RFC 3848: ESMTP and LMTP Transmission Types Registration](https://www.rfc-editor.org/rfc/rfc3848.html) - [RFC 3207: SMTP Service Extension for Secure SMTP over TLS](https://www.rfc-editor.org/rfc/rfc3207.html) - [RFC 5321: Simple Mail Transfer Protocol](https://www.rfc-editor.org/rfc/rfc5321.html) - [Secure email server standards](/learning/secure-email-server) ## Frequently asked questions ### Does ESMTPS mean the message used TLS? Yes. RFC 3848 defines `ESMTPS` as ESMTP "when STARTTLS is also successfully negotiated to provide a strong transport encryption layer" on that hop. Note that the registry defines the keyword in terms of STARTTLS, while common MTAs emit it for any TLS-protected ESMTP session, including implicit TLS on port 465. ### What is the difference between ESMTPS and ESMTPSA? Only the authentication half. `ESMTPS` records TLS alone. `ESMTPSA` records TLS plus successful client authentication, which RFC 3848 describes as the combination of the two keywords. ### Does ESMTPS mean the SMTP client authenticated? No. ESMTPS records TLS without the authentication suffix. ESMTPSA records both qualifying TLS and successful client authentication. ### Is ESMTPS the same as SMTPS on port 465? No. ESMTPS is a `Received` transmission-type keyword. It does not by itself identify the TCP port or say whether TLS began implicitly or through STARTTLS. ### Does one ESMTPS line prove end-to-end encryption? No. One line describes one server-to-server hop. Review every relevant trusted hop and the sending system's transport evidence. ### Can an ESMTPS Received line be forged? Yes. RFC 3848 says so itself: [these keywords "are not normally protected in transport which means they can be modified by an active attacker"](https://www.rfc-editor.org/rfc/rfc3848.html#section-3). Rely on lines added by servers you trust and compare them with server logs when the distinction matters. --- # Google Forms spam: stop it and spot it Canonical: https://www.palisade.email/learning/google-forms-spam > Google Forms spam comes two ways: junk submissions to your own form, and deceptive forms sent to you. How to stop both, and how to judge a forms.gle link. "Google Forms spam" covers two different problems. If your own form is collecting junk submissions, the fix is in the form's own settings. If a form arrived in your inbox, the problem is that a real Google-hosted form or response message can carry content supplied by an attacker. A `forms.gle` link can be a legitimate Google Forms link, but that says nothing about who created the form or whether its request is safe. Judge the form's request, destination links, and business context. Do not enter passwords, payment details, recovery codes, or other sensitive information into an unexpected form. ## Quick takeaways - Google Forms is a publishing tool, so a real Google host can display untrusted user-supplied content. - A `forms.gle` URL identifies a Google Forms link, not a trusted form owner. - Response receipts can carry a form's questions and submitted answers into email. - Authentication for a Google sending domain does not validate claims inside a form. - Preserve the form URL, message headers, timestamps, and screenshots before reporting abuse. - Verify the request through a contact route you already trust. ## How Google Forms spam works [Google's Forms sharing guidance](https://support.google.com/docs/answer/2839588?hl=en) explains that a form creator can publish and distribute a form, including through a shortened URL. The creator controls the title, description, questions, and links that a respondent sees. A malicious creator can therefore place a deceptive invoice, support notice, prize, job offer, or account warning inside a real hosted form. [Google's response-management guidance](https://support.google.com/docs/answer/139706?hl=en) is what makes the email version work. A form owner can set **Collect email addresses** to **Responder input**, and set **Send responders a copy of their response** to **Always**. An attacker then submits their own form with the victim's address typed in, and Google mails the attacker's text to that victim from a Google address. Nothing is spoofed: the mail genuinely comes from Google, which is exactly why authentication checks on it pass. The message can be technically authentic for the service that sent it while the user-supplied form content remains deceptive. This is the useful distinction: infrastructure authenticity and content safety answer different questions. [DMARC is designed to prevent unauthorized use of the domain in the visible From field](https://www.rfc-editor.org/rfc/rfc9989.html#section-2.2). RFC 9989 puts [evaluation of anything other than that field out of scope](https://www.rfc-editor.org/rfc/rfc9989.html#section-2.4), so it does not certify the truth of a form title, linked site, payment request, or support claim. ![Evidence flow showing how user-supplied form content can travel through a legitimate hosted form or response email](/images/editorial/google-forms-spam/google-forms-spam-evidence-flow.svg "1200x676") *Source: Palisade diagram based on [Google's form-sharing guidance](https://support.google.com/docs/answer/2839588?hl=en) and [response-management guidance](https://support.google.com/docs/answer/139706?hl=en).* ## If your own Google Form is getting spam submissions This is the other half of the query, and the fix is entirely in the form's settings rather than in email authentication. - **Require a sign-in.** In Settings, next to Responses, turn on [Limit to 1 response](https://support.google.com/docs/answer/2839588?hl=en). Google notes that responders "must sign in to their Google Account" for this, which removes anonymous bulk submission. - **Verify the address you collect.** Under [Collect email addresses](https://support.google.com/docs/answer/139706?hl=en), choose **Verified** rather than **Responder input**. Responder input accepts whatever is typed, which is the setting the email abuse above depends on. - **Close the form when it is done.** Google lets you [stop accepting responses](https://support.google.com/docs/answer/139706?hl=en), with a custom message, so an old form cannot keep collecting indefinitely. None of these are authentication controls, and no DMARC policy affects them. A form is a publishing surface, so the controls that matter are the publishing controls. ## When a forms.gle link is legitimate but unsafe A `forms.gle` link can point to a genuine Google Forms page. That establishes the hosting route. It does not establish the identity, authority, or intentions of the person who created the form. Use the request as the decision point: - An expected event registration shared by a known organizer can still deserve a quick domain and context check. - An unexpected password, recovery-code, banking, gift-card, cryptocurrency, or payment request should be treated as suspicious. - A form that sends you to another site needs a separate review of that destination. - A request that copies a familiar brand without a matching business process should be verified outside the form. Do not rely on a familiar logo or polished wording. Those are form content. The broader guide to [phishing](/learning/what-is-phishing) explains why the requested action and destination matter more than the page's visual polish. ## What evidence to collect Preserve enough evidence for a security team or provider abuse review without continuing through the suspicious workflow. ```text Observed form URL: https://forms.gle/ How it arrived: email, chat, text message, QR code, or website Timestamp: Claimed organization: Requested action: Linked destinations: Email evidence: User action: not opened, opened, submitted, or credentials entered ``` Do not store passwords, recovery codes, payment-card data, or complete personal records in the incident ticket. Record that sensitive information was requested or entered, then follow the organization's incident process. When the link arrived by email, save the original message and use the [email header analysis guide](/learning/analyze-email-headers-online) to distinguish message routing from the form content. A header can show which system sent that message. It cannot prove that the person named inside the form authorized the request. ## How to respond to Google Forms spam ### 1. Stop before submitting information Close the form if the request is unexpected or asks for sensitive data. Do not test a suspicious form with real or invented credentials because submission can confirm that the recipient engaged. ### 2. Verify the request outside the form Use a phone number, ticket, account portal, or conversation you already trust. Do not use contact details or login links supplied only by the suspicious form. ### 3. Check any linked destination separately Copy only the destination domain when that can be done safely. The [URL reputation checker](/tools/url-reputation) can inspect public reputation signals for a link, but a clean result does not prove ownership, content safety, or future behavior. ### 4. Report the hosted form Use [Google's process for reporting abusive content](https://support.google.com/docs/answer/2463296?hl=en) and provide the preserved form URL and context. An organization can also report the message through its normal security workflow. ### 5. Contain any exposed account If someone entered a password, recovery code, payment data, or other sensitive information, follow the relevant account or payment incident process. Use a known-good route to change credentials and notify the responsible security team. Do not revisit the form to confirm what was entered. Google Forms spam belongs in the wider [email threats](/learning/threats) model because it uses a trusted hosting surface to deliver an untrusted request. Sender authentication can help with direct domain spoofing, but it cannot make third-party hosted content truthful. ## Sources and further reading - [Google Docs Editors Help: Publish and share a form](https://support.google.com/docs/answer/2839588?hl=en) - [Google Docs Editors Help: View and manage form responses](https://support.google.com/docs/answer/139706?hl=en) - [Google Docs Editors Help: Report abusive content](https://support.google.com/docs/answer/2463296?hl=en) - [RFC 9989: Domain-based Message Authentication, Reporting, and Conformance](https://www.rfc-editor.org/rfc/rfc9989.html) ## Frequently asked questions ### Is forms.gle a legitimate domain? Yes. Google Forms uses `forms.gle` for shortened form links, but a legitimate host does not establish that the form creator or request is trustworthy. ### Is every forms.gle link safe? No. Any form owner can supply the form's title, questions, descriptions, and destination links. Verify an unexpected request outside the form before providing information. ### Does a Google-authenticated message make the form content safe? No. Authentication can show that the sending domain authorized the message. It does not validate the identity claim, link, payment request, or instructions written inside user-supplied form content. ### Should I enter fake credentials to test a suspicious form? No. Do not submit credentials or interact further. Preserve the URL and context, report the form, and use an approved incident process if real information was already entered. ### Can DMARC stop Google Forms spam? No. DMARC can address unauthorized use of a protected visible From domain. It does not block deceptive content hosted on another organization's legitimate domain. --- # Private Relay Apple ID: What the Email Address Means Canonical: https://www.palisade.email/learning/private-relay-apple-id > Private Relay Apple ID addresses end in @privaterelay.appleid.com. See what the relay means, how to spot one, and what senders must register to reach it. A Private Relay Apple ID email address is an alias Apple creates when a person uses Sign in with Apple and chooses to hide their email. The address ends in `@privaterelay.appleid.com`, and Apple forwards mail to the person's verified inbox only when it comes from an address the app registered as a source. Store and use the relay address as the user's contact address. Do not treat it as invalid, try to derive the hidden inbox, or confuse it with iCloud Private Relay for web traffic. ## Quick takeaways - A Sign in with Apple relay address ends in `@privaterelay.appleid.com`. - The relay hides the person's underlying email address from the app. - Apple requires participating developers to register the outbound email sources that use the relay, matched by envelope-sender domain under SPF or by DKIM `d=` against the header `From`. An unregistered source bounces. - iCloud Private Relay protects web traffic and is a different feature. - Preserve the relay address in the user record and send only expected, consented messages. - Diagnose failures with the exact bounce, application record, and sending-source configuration. ## What a Private Relay Apple ID address does [Apple's developer guidance for its private email relay](https://developer.apple.com/help/account/capabilities/configure-private-email-relay-service/) describes a relay between an app and the private email address attached to a person's Apple Account. The app receives and stores the relay address instead of the hidden address. Apple forwards eligible mail sent to that relay address. The relay is scoped to the app relationship. It is not a public directory entry and does not encode the destination inbox in a form the sender should reverse. Treat it like an [email alias](/learning/what-is-an-email-alias) whose forwarding rules are controlled by Apple and the user. The naming is the trap here. Apple calls this option [Hide My Email](https://support.apple.com/en-us/105078) inside Sign in with Apple, and it also calls a separate iCloud+ feature [Hide My Email](https://support.apple.com/guide/icloud/what-you-can-do-with-icloud-and-hide-my-email-mme38e1602db/icloud). They are not the same thing. An address created through Sign in with Apple is locked to the one app or website that created it, which Apple states directly: "only the app or website you created the account with can use this unique email address to communicate with you." An iCloud+ address is created ad hoc by the user for any site, app, or personal use. ## What does private relay mean in this context? The phrase is overloaded across Apple products: - **Private email relay for Sign in with Apple:** the app sees an address at `privaterelay.appleid.com` and sends eligible account mail to it. - **Hide My Email with iCloud+:** the user can create random forwarding addresses for sites, apps, and personal use. - **iCloud Private Relay:** part of an iCloud+ subscription, it [protects your privacy when you browse the web in Safari](https://support.apple.com/en-us/102602). It is not an email address at all, and never appears in an app's user table. If a support ticket says only "Private Relay," check the evidence before choosing a branch. An address suffix points to email relay. A Safari, IP address, or network-routing question points to iCloud Private Relay. Do not confuse a generated relay address with Apple's fixed sender addresses. If a received message displays `noreply@email.apple.com`, use the [exact sender-address verification guide](/learning/noreply-email-apple-com) and inspect the original message rather than applying relay rules. ![Flow showing a Sign in with Apple relay address between an app's registered sender and the user's private inbox](/images/editorial/private-relay-apple-id/private-relay-apple-id-mail-flow.svg "1200x676") *Source: Palisade diagram based on [Apple's private email relay configuration guidance](https://developer.apple.com/help/account/capabilities/configure-private-email-relay-service/).* ## How to check a private relay email ### 1. Inspect the complete stored address Check whether the account address ends exactly in `@privaterelay.appleid.com`. Do not decide from the display name, the word "Apple," or a partial screenshot. ### 2. Match it to the application user record Use the stable user identifier and account record produced by your Sign in with Apple integration. The relay address is contact data for that account, not a reliable key for joining unrelated user records. ### 3. Confirm the sending source is registered Apple tells developers to register the domains and email addresses that will communicate with users through the relay, and it checks that registration along [two different paths](https://developer.apple.com/help/account/capabilities/configure-private-email-relay-service/). Which one applies to you depends on who owns your bounce domain, so check the right field. **SPF path.** Apple requires that "the domain in the envelope sender (also known as the MAIL FROM, bounce, or Return-Path address) must be registered", must pass SPF, and must match the registered domain exactly. Note the field: this is the envelope sender, not the visible `From` header. **DKIM path.** If your email service provider owns the envelope sender, as Apple notes is the case with Amazon SES, Mailchimp and SendGrid, you must sign with DKIM instead. There the `d=` value is matched against the domain in your header `From` address, that domain must be registered, and the signature has to cover the `From:` header. This is the step most senders get wrong, because an ESP's bounce domain differs from the visible `From` domain by default. Comparing only the `From` address will show a match while the relay is failing you on the SPF path. Apple states the consequence plainly: "if you don't register all the source domains or emails that you use, email sent to the private relay service will result in a bounce message." Registration is capped at 32 email sources for an individual account and 100 for an organization. ### 4. Preserve the complete delivery result If mail fails, keep the SMTP response, timestamp, envelope sender, visible From address, recipient relay address, and sending service. A generic address check cannot show whether Apple accepted this application-to-relay path. ### 5. Retest the same application path Send one expected account message from the same production source after correcting a confirmed registration or sender mismatch. Do not test from a personal mailbox and assume that result proves the application path. This evidence order is more useful than changing the address. The [email deliverability hub](/email-deliverability) covers the broader distinction between SMTP acceptance, forwarding, and final mailbox placement. ## How senders should handle the relay address Store the exact relay address Apple returned. Use it for messages the person expects from the app, honor consent and unsubscribe state, and keep it attached to the correct application account. Do not replace it with a guessed personal address. Do not merge two user records only because one later reveals a different email. A person can change forwarding choices, and separate Apple app relationships can have separate relay addresses. If delivery fails, begin with the returned evidence. Apple's developer guidance says participating email sources must be registered for the relay. A mismatch between the actual production sender and that configuration is therefore a concrete branch to check. The final inbox provider can still make its own delivery decision after forwarding. For syntax, domain, or mailbox-level evidence outside the Apple relay, follow the steps for [checking email address deliverability](/learning/check-email-address-deliverability). That process cannot reveal the hidden destination or override Apple's forwarding rules. ## Sources and further reading - [Apple Developer: Configure private email relay service](https://developer.apple.com/help/account/capabilities/configure-private-email-relay-service/) - [Apple Support: How to use Hide My Email with Sign in with Apple](https://support.apple.com/en-us/105078) - [Apple: What you can do with iCloud+ and Hide My Email](https://support.apple.com/guide/icloud/what-you-can-do-with-icloud-and-hide-my-email-mme38e1602db/icloud) - [Apple Support: About iCloud Private Relay](https://support.apple.com/en-us/102602) - [Apple two-factor authentication email](/learning/apple-two-factor-authentication-email) ## Frequently asked questions ### Is a Private Relay Apple ID address a real email address? Yes. It is a working relay address for an eligible Sign in with Apple app relationship, though it hides the person's underlying inbox. ### Is Private Relay Apple ID the same as iCloud Private Relay? No. The email relay forwards messages to a hidden inbox. iCloud Private Relay protects Safari browsing and related internet traffic. ### Can I reply to mail sent to my Private Relay address? Yes. Apple states that the addresses "automatically forward to your personal email inbox" and that "you can read and respond directly to emails sent to these addresses" while your real address stays private. ### Why does my iPhone call this Hide My Email rather than Private Relay? Only because Apple uses "Hide My Email" for the option inside Sign in with Apple as well as for the separate iCloud+ feature. The address you get from Sign in with Apple is the one ending in `@privaterelay.appleid.com`, and it works only with the app or website that created it. ### Can a sender discover the hidden email from the relay address? No. The relay address should be treated as the user's contact address for that app. Do not try to decode, guess, or obtain the private destination outside the user's chosen account flow. ### Should an application reject addresses ending in privaterelay.appleid.com? No. Store the address as returned by Sign in with Apple and make sure the production sending source satisfies Apple's relay configuration. ### Can an ordinary email verifier prove that relay forwarding works? No. A verifier can inspect general address or domain signals, but it cannot prove that a particular app sender is registered, that the user still permits forwarding, or that the final inbox accepted the message. --- # Valid Characters for an Email Address Canonical: https://www.palisade.email/learning/valid-characters-for-email-address > Valid characters for an email address are letters, digits, and punctuation such as ! # $ % & ' * + - _ in the local part, with dots only between them. Valid characters for an email address depend on where they appear. In an ordinary unquoted local part before `@`, RFC email syntax allows ASCII letters, digits, selected punctuation, and single dots between other characters. The domain after `@` follows domain-label rules. Quoted local parts and SMTPUTF8 permit more characters, but a syntactically valid address can still be rejected by a signup form, provider, or receiving mailbox. ## Quick takeaways - The local part and domain follow different character rules. - An unquoted local part can contain more punctuation than many forms accept. - A dot cannot begin or end an unquoted local part, and two dots cannot be adjacent. - An apostrophe is valid in an unquoted local part under RFC 5322. - A quoted local part can represent spaces and other characters, but support varies. - Non-ASCII mailbox characters require SMTPUTF8 support along the delivery path. ## Who is affected? These rules affect form developers, identity teams, email senders, mailbox providers, and support staff deciding whether an address is malformed. The same address can pass the Internet Message Format grammar and still fail a product's account policy or a provider's mailbox rules. Separate three questions: - Is the string valid under the applicable email syntax? - Does the application choose to accept that valid syntax? - Does a mailbox exist and accept mail at that address? The article on [checking email address deliverability](/learning/check-email-address-deliverability) covers the third question. This page owns the syntax question. ## What are the requirements? ### An email address has a local part and a domain [RFC 5322 defines `addr-spec`](https://www.rfc-editor.org/rfc/rfc5322.html#section-3.4.1) as a local part, an `@` sign, and a domain. The local part identifies the mailbox within the domain's rules. The domain identifies the system responsible for that namespace. ```text local-part@domain ``` Do not validate both sides with one character class. A punctuation mark allowed before `@` can be invalid in a domain label. ### An unquoted local part allows letters, digits, and selected punctuation [RFC 5322 defines the `atext` character set](https://www.rfc-editor.org/rfc/rfc5322.html#section-3.2.3). An unquoted local part can use ASCII letters, digits, and these printable characters: ```text Letters: A-Z a-z Digits: 0-9 Other ASCII: ! # $ % & ' * + - / = ? ^ _ ` { | } ~ Separator: . only between non-dot elements ``` That makes addresses such as `o'connor@example.com`, `sales+ca@example.com`, and `first_last@example.com` syntactically possible. It does not require a provider to create or accept those mailboxes. ### Dots have placement rules The unquoted `dot-atom` form permits a dot only between other `atext` runs. An unquoted local part cannot start with a dot, end with a dot, or contain two adjacent dots. ```text Valid dot shape: first.last@example.com Invalid dot shapes: .first@example.com first.@example.com first..last@example.com ``` Provider-specific behavior can be narrower or different after syntax is accepted. For example, the separate guide on [dots in Gmail addresses](/learning/dots-in-gmail-address) explains how personal Gmail delivery treats dot variants. ### Quoted local parts permit a wider ASCII range RFC 5322 also allows a quoted-string local part. Quoting can represent spaces and characters that are not valid in an unquoted `dot-atom`, with escapes where the grammar requires them. ```text "customer support"@example.com ``` This is a syntax example, not a claim that every signup form or provider accepts quoted mailbox names. A production sender should test the systems that create, store, transport, and receive the address before relying on this form. ### The domain follows domain-label rules [RFC 5321's mailbox grammar](https://www.rfc-editor.org/rfc/rfc5321.html#section-4.1.2) uses domain labels made from letters, digits, and hyphens, separated by dots. A label cannot begin or end with a hyphen. An underscore is therefore not valid in an ordinary mailbox domain label, even though underscores appear in other DNS names such as `_dmarc.example.com`. ### SMTPUTF8 extends mailbox syntax beyond ASCII [RFC 6531 defines the SMTPUTF8 extension](https://www.rfc-editor.org/rfc/rfc6531.html#section-3.3), which permits UTF-8 in mailbox addresses when the SMTP systems involved support the extension. A Unicode address is not safe to downgrade by deleting or replacing characters. Preserve it exactly and confirm support on the intended delivery path. ![Decision flow for validating the local part, domain, and SMTPUTF8 requirement of an email address](/images/editorial/valid-characters-for-email-address/valid-characters-for-email-address-syntax-flow.svg "1200x676") *Source: Palisade diagram based on [RFC 5322 address syntax](https://www.rfc-editor.org/rfc/rfc5322.html#section-3.4.1), [RFC 5321 mailbox syntax](https://www.rfc-editor.org/rfc/rfc5321.html#section-4.1.2), and [RFC 6531 SMTPUTF8](https://www.rfc-editor.org/rfc/rfc6531.html#section-3.3).* ## When does the requirement take effect? RFC 5321 and RFC 5322 define the modern baseline SMTP and message-format syntax. RFC 6531 adds internationalized mailbox support through SMTPUTF8. There is no single provider effective date that makes every syntactically valid address usable everywhere. An application can adopt narrower product rules, but it should describe those as application limits instead of declaring an RFC-valid address universally invalid. Review the rule whenever an identity provider, mailing platform, or mailbox system changes. ## How do I implement the requirement? ### 1. Preserve the address exactly as entered Trim only surrounding input whitespace that is not part of the address field. Do not remove punctuation, change Unicode characters, or lowercase the stored local part as an automatic repair. ### 2. Parse the local part and domain separately Split at the structural `@` boundary with a parser that supports the address forms your product accepts. Avoid a short regular expression that silently rejects apostrophes, plus signs, or internationalized addresses without a documented product reason. ### 3. Apply a documented product policy Decide whether the product supports quoted local parts and SMTPUTF8 addresses. Return a precise error when the product accepts less than the RFC grammar. Do not call a valid but unsupported address malformed. ### 4. Verify control and test delivery separately Send a verification message through the actual production path. Syntax validation cannot prove that the domain resolves, the mailbox exists, or the person controls it. For public domain evidence, a [DNS lookup](/tools/dns-lookup) can show the domain's current records without validating the mailbox. ## How do I validate compliance? Build tests from each supported class rather than one list of familiar addresses. Include ordinary letters and digits, apostrophes, plus signs, underscores in the local part, legal dot placement, illegal dot placement, a quoted local part if supported, and a UTF-8 address if SMTPUTF8 is supported. Record three outcomes for each case: parser acceptance, account-verification behavior, and actual message delivery. A parser pass is syntax evidence. A verification click is control evidence. SMTP acceptance is delivery evidence. None of those alone proves future inbox placement. Keep this work within the broader [email infrastructure hub](/learning/infrastructure), where DNS, SMTP, message headers, and transport rules are treated as separate evidence layers. ## Sources and further reading - [RFC 5322: Internet Message Format](https://www.rfc-editor.org/rfc/rfc5322.html) - [RFC 5321: Simple Mail Transfer Protocol](https://www.rfc-editor.org/rfc/rfc5321.html) - [RFC 6531: SMTP Extension for Internationalized Email](https://www.rfc-editor.org/rfc/rfc6531.html) ## Frequently asked questions ### Can an email address contain an apostrophe? Yes. RFC 5322 includes the apostrophe in the `atext` set allowed in an unquoted local part, though an individual provider or form can support a narrower set. ### Can an email address contain a space? Only in a quoted local part under the message syntax. Many providers and forms do not support quoted mailbox names, so test the complete production path before relying on one. ### Can an email local part start or end with a dot? No. The ordinary unquoted `dot-atom` form cannot start or end with a dot, and it cannot contain adjacent dots. ### Can an email address contain Unicode characters? Only when the systems on the delivery path support the SMTPUTF8 extension defined by RFC 6531. Preserve the address exactly instead of attempting an ASCII rewrite. ### Which special characters are allowed in an email address? Only the ones RFC 5322 lists in `atext`: `! # $ % & ' * + - / = ? ^ _ ` { | } ~` alongside letters and digits, plus a dot between other characters. Anything outside that set has to be quoted to appear in a local part. ### Which characters are invalid in an email address? The `specials` set from RFC 5322 cannot appear unquoted: `( ) < > [ ] : ; @ \ , "` and the space. A dot is also invalid at the start or end of an unquoted local part, and two dots cannot sit next to each other. ### Does valid email syntax prove that the mailbox exists? No. Syntax validation checks the address form. Domain resolution, mailbox acceptance, account control, and inbox placement require separate evidence. --- # Caution: this email originated from outside of the organization Canonical: https://www.palisade.email/learning/caution-email-originated-outside-organization > "Caution: This email originated from outside of the organization" means the message is external, not that it is phishing. Here is what to check. "Caution: This email originated from outside of the organization" means the recipient's mail system classified the message as coming from outside of the organization. It is an origin label, not a finding that the message is malicious, and it does not prove that SPF, DKIM, or DMARC failed. Verify unexpected requests through a contact method you already trust, especially before opening a file, following a link, or sending sensitive information. ## Quick takeaways - The warning identifies an external origin. It does not classify the message as phishing. - Legitimate mail from customers, vendors, and personal accounts can carry the warning. - That exact sentence is always your own organization's mail flow rule. Microsoft's built-in feature adds an icon, not a sentence. - An external-origin banner and an unverified-sender warning describe different evidence. - Treat the message's request and context as the decision point, not the banner alone. ## How the external email warning works Two different mechanisms mark external mail in Outlook, and the wording tells you which one you are looking at. Microsoft's built-in feature, configured through [`Set-ExternalInOutlook`](https://learn.microsoft.com/en-us/powershell/module/exchangepowershell/set-externalinoutlook?view=exchange-ps), adds an **External icon in the area of the subject line** in supported Outlook experiences, plus a limited allow list for exceptions. It contributes no text to the message body and no sentence of its own. A sentence at the top of the message body comes from somewhere else: an Exchange Online mail flow rule. Microsoft's [organization-wide disclaimer guidance](https://learn.microsoft.com/en-us/exchange/security-and-compliance/mail-flow-rules/disclaimers-signatures-footers-or-headers) describes how a rule prepends or appends text. So the exact sentence "Caution: This email originated from outside of the organization" was written by your own organization, not by Microsoft. The two can also stack, which is why Microsoft's own documentation says to disable rules that already tag external senders before enabling the built-in feature, to avoid duplication. The practical tell: **body text at the top of the message is your organization's rule; a small External tag beside the subject line is Microsoft's built-in feature.** The banner is an origin label, so it sits alongside the other [email threats](/learning/threats) a recipient has to judge rather than replacing that judgement. Neither route makes the banner an authentication result. Outlook's separate [unverified-sender warning](/learning/outlook-unverified-sender-warning) concerns sender identity evidence. An external banner can appear on a legitimate message that authenticates correctly, while an internal-looking message without the banner can still require scrutiny if an account was compromised. Use this distinction when recording the message: ```text Observed label: Caution: This email originated from outside of the organization What it establishes: The message was classified as external to the recipient organization What it does not establish: Phishing, malware, or an SPF, DKIM, or DMARC failure Evidence to keep: Sender address, message time, request, links, attachments, and original headers ``` ## Does the warning mean the same thing for every sender? The warning's basic meaning stays the same, but the right response depends on the sender and request. - A known supplier sending an expected invoice is still external. Confirm that the sender address, amount, and payment route match the business process. - A colleague using a personal account is also external. Confirm why they used that account before sharing internal information. - An automated service may be expected even when its visible sender name resembles an internal system. Check the approved service and message purpose. - A message without the warning is not automatically safe. The absence of a banner says nothing about whether the account or sending system is trustworthy. The banner also does not show which organization feature produced it. If the wording appears in one mailbox but not another, or the treatment changed after a mail-flow update, an administrator needs to identify whether the source is Outlook external identification or an Exchange mail flow rule. ![Decision flow for responding to an external email warning by checking whether the sender and request are expected](/images/editorial/caution-email-originated-outside-organization/caution-email-originated-outside-organization-decision-flow.svg "1200x676") *Source: Palisade diagram based on [Microsoft's external-sender identification command](https://learn.microsoft.com/en-us/powershell/module/exchangepowershell/set-externalinoutlook?view=exchange-ps) and [Microsoft's phishing guidance](https://support.microsoft.com/en-us/windows/protect-yourself-from-phishing-0c7ea947-ba98-3bd9-7184-430e1f860a44).* ## What should you do when the banner appears? ### 1. Read the complete sender address Check the address, not only the display name. Look for a changed domain, extra word, substituted character, or reply address that does not match the expected contact. Do not assume a familiar name proves who sent the message. ### 2. Decide whether the request is expected Compare the request with a purchase order, ticket, calendar event, or conversation you already know. A first-time request for credentials, gift cards, bank changes, or urgent payment deserves separate verification even when the sender looks familiar. ### 3. Verify through a separate trusted route Use a phone number, chat account, or ticket record you already have. Do not use the phone number or login link supplied in the questionable message. Microsoft's [guidance on protecting yourself from phishing](https://support.microsoft.com/en-us/windows/protect-yourself-from-phishing-0c7ea947-ba98-3bd9-7184-430e1f860a44) describes messages that impersonate reputable companies or acquaintances to get you to reveal information, which is why the contact route has to come from somewhere other than the message. If the message includes a file, follow the [safe process for an unexpected attachment](/learning/how-can-you-safely-handle-malicious-email-attachments) before opening it. ### 4. Report the original message when it remains suspicious Use your organization's reporting control or security process. Preserve the original message so the security team can inspect its sender, links, attachments, and headers. Forwarding a screenshot alone removes much of that evidence. If you can export the original message, Palisade's [email header analyzer](/tools/email-header-analyzer) can organize its routing and authentication evidence for review. It cannot decide whether the sender's request is legitimate or reveal why your organization added the banner. For a plain-language explanation of the underlying attack pattern, see [what phishing is](/learning/what-is-phishing). ## What should Microsoft 365 administrators check? Identify the mechanism before changing the warning. For this sentence specifically, inspect the mail flow rules that prepend disclaimer text first, because that is where the wording lives. Then read the built-in feature's state with `Get-ExternalInOutlook`, the view counterpart to `Set-ExternalInOutlook`. Record the owner, exceptions, and reason for each configuration. An exception should reflect a documented business boundary, not a request to make a sender look internal. Removing a banner does not authenticate the sender. Adding one does not inspect links, attachments, payment requests, or account compromise. Test any change with messages from an external account, an allowed sender if one is configured, and an internal account. Confirm which messages receive the banner in every supported Outlook client your organization uses. ## Sources and further reading - [Microsoft Exchange PowerShell: Set-ExternalInOutlook](https://learn.microsoft.com/en-us/powershell/module/exchangepowershell/set-externalinoutlook?view=exchange-ps) - [Microsoft Learn: Organization-wide message disclaimers in Exchange Online](https://learn.microsoft.com/en-us/exchange/security-and-compliance/mail-flow-rules/disclaimers-signatures-footers-or-headers) - [Microsoft Support: How to spot and report phishing emails](https://support.microsoft.com/en-us/windows/protect-yourself-from-phishing-0c7ea947-ba98-3bd9-7184-430e1f860a44) ## Frequently asked questions ### Does the external email warning mean the message is phishing? No. The warning means the message was classified as coming from outside the recipient's organization. Use the sender address, request, links, attachments, and a separate verification route to decide whether it is trustworthy. ### Can a legitimate message show the warning? Yes. Expected mail from customers, suppliers, cloud services, and personal accounts is external and can carry the warning even when the sender is legitimate. ### Does the banner mean SPF, DKIM, or DMARC failed? No. The banner labels the message's organizational origin. Authentication results are separate evidence, so a correctly authenticated external message can still display it. ### Can a recipient remove the warning? Only an administrator can reliably identify and change the organization-wide feature or mail flow rule that added it. A recipient should not create a personal workaround that hides security context without approval. ### Should I trust a link when the external message was expected? Not solely because the message was expected. Confirm the sender address and destination, and use a known bookmark or official site when the message requests credentials or sensitive information. --- # What is the maximum size for an email attachment? Canonical: https://www.palisade.email/learning/max-size-for-email-attachment > There is no universal maximum email attachment size. Gmail and Outlook.com publish 25 MB, but encoding and the recipient's limit decide what lands. There is no universal maximum size for an email attachment. Gmail allows up to 25 MB of attachments and Outlook.com publishes a 25 MB file-attachment limit, but work accounts, gateways, and recipient systems can set different caps. The lowest limit on the delivery path wins. File size is also smaller than final message size because encoding, the message body, headers, and other attachments add overhead. ## Quick takeaways - Gmail publishes 25 MB for personal accounts. Outlook.com publishes 25 MB, but the Outlook client caps internet accounts at 20 MB and Exchange accounts at 10 MB by default. - Base64 encoding adds about 33%, so under a 25 MB cap measured on the encoded message, plan on roughly 18 MB of raw file. - Check both the sender's limit and the recipient system's limit. - A provider may limit total attachments, the complete encoded message, or both. - Base64 encoding expands binary data before the message travels over email. - An accepted upload does not prove the receiving gateway will accept the message. - Use a controlled file-sharing link when the file is close to a published limit. ## How attachment size and message size differ An attachment starts as a binary file, but email normally carries that file as encoded MIME content. [RFC 4648 defines Base64 encoding](https://www.rfc-editor.org/rfc/rfc4648.html) in groups that turn 3 input octets into 4 encoded characters. That makes the encoded payload about one-third larger before MIME boundaries, filenames, message headers, body text, signatures, and any other files are added. This illustrative calculation shows why the file shown in Finder or File Explorer is not the final message size: ```text Binary attachment: 18,000,000 bytes Base64 payload, approximate: 24,000,000 characters Still added by the message: MIME fields, body, signature, headers, other files Limit that decides delivery: Lowest enforced limit on the sender-to-recipient path ``` Inverted, that is the number worth remembering: **under a 25 MB cap measured on the encoded message, plan on roughly 18 MB of raw file.** The exact result depends on the sending client and message construction. Use it as a planning model, not as a promise that an 18 MB file will pass every provider. ## What limits do common providers publish? ### Gmail Google's [Gmail attachment guidance](https://support.google.com/mail/answer/6584?hl=en) sets a 25 MB total attachment limit **for personal Gmail accounts**. For work and school accounts, a Google Workspace administrator sets both the sending and receiving attachment limits, so the personal-account number is the wrong one to plan a business send around. When a file is larger, Gmail can add it as a Google Drive link instead of attaching the binary file to the message. The recipient can still have a lower limit or block the file type. A Drive link also introduces its own access permissions, so confirm that the intended recipient can open it without exposing the file more broadly. ### Outlook.com Microsoft's [Outlook.com sending-limits guidance](https://support.microsoft.com/en-us/office/sending-limits-in-outlook-com-279ee200-594c-40f0-9ec8-bb6af7735c2e) publishes a 25 MB file-attachment limit. Outlook can offer OneDrive sharing for larger files, but the file's sharing permissions still control who can retrieve it. The Outlook client enforces its own, lower cap first. Microsoft's [guidance on reducing attachment size](https://support.microsoft.com/en-us/outlook/reduce-attachment-size-to-send-large-files-with-outlook) states that for internet email accounts such as Outlook.com or Gmail the email size limit is 20 MB, and for Exchange business accounts the default is 10 MB, counting the attachment and the message together. That is a live example of this page's whole point: the service published 25 MB, and the client stops you before you reach it. ### Microsoft 365 and other work accounts Business mail can have service, organization, connector, gateway, mailbox, and recipient limits. Microsoft's [Exchange Online limits service description](https://learn.microsoft.com/en-us/office365/servicedescriptions/exchange-online-service-description/exchange-online-limits) separates message-size limits from recipient, rate, mailbox, and tenant limits. The article on [Exchange Online sending and receiving limits](/learning/how-do-exchange-online-sending-and-receiving-limits-work) explains those other counters. That service description publishes the figures worth planning against: - Default maximum message size: **35 MB sending, 36 MB receiving**, which an administrator can set anywhere between **1 MB and 150 MB**. - Ceiling: **150 MB** in Outlook, **112 MB** in Outlook on the web. - File attachments per message: **250**. - Messages routed outside Microsoft datacenters carry "an additional 33% translation encoding increase", which is why the outbound ceiling lands at 112 MB. That is the same encoding overhead this page describes, confirmed by the vendor. Ask the mail administrator for the configured message-size limit when the sender or recipient uses a managed account. Limits bind in both directions: Microsoft notes that a client may cap an individual attachment below the server's message-size limit, and a client that accepts an attachment may still submit it to a server with a lower cap. Sizing an attachment is one of the routine [email deliverability](/email-deliverability) checks that decide whether a message lands at all. ## When does the answer change? The published attachment limit changes with the complete delivery path: - The sender application may stop the upload before submission. - The sending mail server can reject a message that exceeds its configured size. - A security gateway or relay can apply another message-size policy. - The recipient provider or tenant can enforce a lower receiving limit. - A policy can block a file type even when the message is small enough. Multiple attachments matter because providers often evaluate their combined size or the final message size. Splitting a large file across several attachments in one message does not avoid a total-message cap. ![Flow showing that attachment encoding adds message overhead before sender, gateway, and recipient size limits are applied](/images/editorial/max-size-for-email-attachment/max-size-for-email-attachment-limit-flow.svg "1200x676") *Source: Palisade diagram based on [RFC 4648 Base64 encoding](https://www.rfc-editor.org/rfc/rfc4648.html), [Gmail attachment guidance](https://support.google.com/mail/answer/6584?hl=en), and [Exchange Online limits](https://learn.microsoft.com/en-us/office365/servicedescriptions/exchange-online-service-description/exchange-online-limits).* ## How should you send a file without hitting the limit? ### 1. Check the sending account's published limit Use the documentation for the actual account and client. Separate a consumer Outlook.com mailbox from a Microsoft 365 work account, since they do not share one universal configuration. ### 2. Check the recipient path Ask the recipient or their administrator about the receiving limit when the file is business-critical. Include any secure email gateway or ticketing system that receives the message before the mailbox. ### 3. Leave room for encoding and message content Do not compare the raw file size directly with a full-message limit. Account for Base64 expansion, body content, signatures, headers, and all other attachments. If the file is close to the documented cap, use an approved sharing service instead. ### 4. Share the file with controlled permissions Restrict the link to the intended recipients when the service supports it, set an appropriate expiry, and confirm access through the recipient's real account. Do not upload confidential material to an unapproved public service. If an unexpected message asks you to open a shared file, use the same [safe attachment-handling process](/learning/how-can-you-safely-handle-malicious-email-attachments) you would use for a binary attachment. ### 5. Retest the same path after a rejection Preserve the original failure, then send a small plain-text control message to the same recipient. If that succeeds, retry with a smaller approved file or a controlled link. An Outlook or Exchange NDR should be classified from its exact code and diagnostic text using the [Outlook bounce-back guide](/learning/bounce-back-email-outlook). ## What does an attachment-size rejection tell you? A size rejection describes one attempted message and path. It does not mean the recipient address is invalid, the sender is blocklisted, or email authentication failed. Keep the original NDR or SMTP response, the file size, the sender application, the recipient domain, and the time of the attempt. If the same message reaches one provider but fails at another, compare the receiving limits and gateway policies. If a small control message also fails, return to the diagnostic text instead of assuming attachment size is still the cause. When the NDR includes the original message headers, Palisade's [email header analyzer](/tools/email-header-analyzer) can organize the route and authentication results for review. It cannot show a provider's private size configuration or prove which limit rejected the message. ## Sources and further reading - [Google Support: Send attachments with your Gmail message](https://support.google.com/mail/answer/6584?hl=en) - [Microsoft Support: Sending limits in Outlook.com](https://support.microsoft.com/en-us/office/sending-limits-in-outlook-com-279ee200-594c-40f0-9ec8-bb6af7735c2e) - [Microsoft Learn: Exchange Online limits](https://learn.microsoft.com/en-us/office365/servicedescriptions/exchange-online-service-description/exchange-online-limits) - [Microsoft Support: Reduce attachment size to send large files with Outlook](https://support.microsoft.com/en-us/outlook/reduce-attachment-size-to-send-large-files-with-outlook) - [RFC 4648: Base-N encodings](https://www.rfc-editor.org/rfc/rfc4648.html) ## Frequently asked questions ### Can I send a 25 MB attachment to every email provider? No. A 25 MB raw file encodes to roughly 33 MB on the wire, so it clears no 25 MB cap that is measured on the encoded message. Gmail and Outlook.com both publish 25 MB, but the Outlook client, a gateway, or the recipient system can enforce less. ### Does compressing a file always make it small enough to email? No. Some file formats are already compressed, and the final email still includes encoding and message overhead. Check the resulting file and the complete delivery path. ### Is a cloud-storage link automatically safer than an attachment? No. A link avoids attaching the binary file, but access permissions, account compromise, phishing, and data-handling rules still apply. Use an approved service and restrict access. ### Is the published limit always per attachment? No. A provider can count all attachments together or enforce a limit on the complete encoded message. Read the rule for the actual sending and receiving services. ### Can a Microsoft 365 administrator raise the attachment limit? Only within the service and organization controls available for that tenant. A higher sending limit does not override a lower gateway or recipient limit. --- # IONOS DMARC setup Canonical: https://www.palisade.email/learning/ionos-dmarc-setup > IONOS DMARC setup: add a TXT record at _dmarc in the IONOS DNS panel, start at p=none, then confirm the policy and your mail results before enforcing. IONOS DMARC setup requires the current DMARC record instructions for your specific domain and access to the DNS zone that publishes the domain's records. IONOS offers E-Mail services, but a safe setup should use the exact record name and value shown in your account or confirmed by IONOS support. Publish nothing from a copied example until it matches the domain and sending paths you operate. ## Quick takeaways - DMARC is a DNS-published policy that depends on SPF or DKIM authentication results for real mail. - In the IONOS panel the record is a TXT entry with the host name `_dmarc`; IONOS appends the domain for you. - Start at `p=none` with an `rua` address, and move to enforcement only on report evidence. - A public DNS answer does not prove that IONOS Email or another sender uses the expected authentication settings. - Keep a rollback path before publishing or replacing a DMARC record. - Validate DNS, sender status, a delivered message, and DMARC reports as separate checks. ## Scope and prerequisites Start with one domain and one production sending path. Identify the visible From domain, every service that sends mail for it, the person responsible for each sender, and the person authorized to change DNS. DMARC evaluates the domain shown in the visible From address. Read the [DMARC learning hub](/learning/dmarc) and [what DMARC is](/learning/what-is-dmarc) if the distinction between the visible From domain and a sender's technical return path is unclear. Before changing DNS, collect: - The domain you intend to protect, such as `yourdomain.com`. - The DNS provider and account owner for that domain. - A list of current senders, including employee mail, website forms, transactional systems, and marketing platforms. - A recent delivered test message from each material sending path, with its full authentication results available to the responsible administrator. - The existing DNS record at the intended DMARC hostname, if one exists. - A rollback owner who can restore the prior known-good DNS value. > Do not replace an existing DMARC TXT record with an example from another domain. A replacement can change the policy seen by receiving mail systems and can affect legitimate mail that has not yet been checked. IONOS presents E-Mail as an offering on its [official website](https://www.ionos.com/). That does not establish which DNS interface controls your domain, which IONOS email settings apply to your account, or which services send mail under your domain. Confirm those details before implementation. ## Choose the implementation approach Use the implementation path that matches where DNS is authoritative: - If IONOS hosts the authoritative DNS zone, obtain the current record-publishing instructions from the IONOS account or support channel before editing the zone. - If another provider hosts the authoritative DNS zone, publish the confirmed DMARC record there, even if IONOS provides the mailbox service. - If a third-party sender uses the domain, obtain its current SPF and DKIM instructions separately. A DMARC policy cannot correct a sender that is not authenticated or aligned. - If an existing DMARC record is present, preserve it until you understand its current policy, reporting destinations, and any subdomain behavior. The safe policy sequence is monitor first, then consider stronger handling only after report evidence shows that legitimate sending sources authenticate and align. Do not treat a green DNS result as proof that every application sends correctly. ![IONOS DMARC implementation decision points covering DNS ownership, sender evidence, message results, and policy readiness](/images/editorial/ionos-dmarc-setup/ionos-dmarc-setup-validation-flow.webp "1200x829") *Source: Palisade.* ## How to configure DMARC for an IONOS domain ### 1. Confirm the DNS authority for the domain Find the provider that hosts the authoritative DNS zone for the visible From domain. The service that provides mailboxes and the service that hosts DNS may be different. Record the domain, DNS account, change owner, and current DNS value before making an edit. If the domain's nameservers point somewhere other than IONOS, publish the record in that zone instead; the IONOS panel only edits zones IONOS is authoritative for. ### 2. Decide the policy and reporting address IONOS documents the DMARC record as a TXT record created at the subdomain name `_dmarc`, with tags separated by semicolons. Decide two values before you open the panel. Start at `p=none`. A monitoring policy asks receivers to take no action while you collect evidence, which is what you want before any enforcement decision. Add an `rua` address so aggregate reports have somewhere to arrive. ```text Host name: _dmarc Type: TXT Value: v=DMARC1; p=none; rua=mailto:postmaster@yourdomain.com ``` Replace the reporting address with a mailbox you control. IONOS's own example uses `p=reject`, but do not publish an enforcement policy before report evidence shows every legitimate sender passes and aligns. If a DMARC record already exists at `_dmarc`, edit it rather than adding a second policy record at the same owner name. Tag meanings are defined by the DMARC standard, not by IONOS: `p` sets the domain policy, `sp` sets the subdomain policy, `rua` receives aggregate reports, `ruf` receives failure reports, and `adkim` and `aspf` set alignment mode. ### 3. Preserve the existing sender configuration Do not use a DMARC change to replace SPF or DKIM setup. Each sender needs its own approved authentication configuration. For example, a third-party sender may require a provider-generated DKIM record, while a different sender may use another authentication domain. Keep a sender inventory beside the DNS change. The inventory should identify: - The application or mailbox service. - The visible From domain it uses. - The expected SPF or DKIM authentication domain. - The owner who can provide a current test message. - The current verification state in that sender's own settings. SPF is the other half of this work on the same domain: see [IONOS SPF setup](/learning/ionos-spf-setup) for the record that authorizes your sending hosts. If a sender signs with DKIM, its selector and key come from that sender's own settings, not from IONOS. ### 4. Publish the record in the IONOS DNS panel IONOS documents this path in [Configuring a DMARC Record for a Domain](https://www.ionos.com/help/domains/configuring-mail-servers-and-other-related-records/configuring-a-dmarc-record-for-a-domain/): - Click the domain, and under **Actions** click the **gear icon**, then click **DNS**. - Click **ADD RECORD**, and under **Type** select **TXT**. - In **Host name**, enter `_dmarc`. IONOS creates `_dmarc.your-domain.com` automatically, so do not type the full domain here or the owner name ends up duplicated. - In **Value**, enter your tags separated by semicolons, for example `v=DMARC1; p=none; rua=mailto:postmaster@yourdomain.com`. - Optionally set the **TTL**, then click **Save**. For a subdomain, the host field takes the subdomain form: to protect `abc.your-domain.com`, enter `_dmarc.abc`. IONOS states the change is effective immediately at IONOS, but it can take up to an hour to become visible everywhere because of DNS caching. Preserve a copy of any previous value so the rollback owner can restore it if the change is wrong. ### 5. Record the change and wait for DNS visibility Record the change time, the intended hostname, the published value, and the person who approved it. Query the full hostname at the authoritative DNS service and at a public resolver after the change becomes visible. A public DNS answer confirms only what DNS returns. It does not confirm that IONOS Email, a marketing sender, or any other application uses the authentication domains you expect. ## How to validate the setup A working DMARC deployment needs evidence at four layers. - DNS: Confirm that the intended DMARC hostname returns the approved TXT value from the authoritative DNS source and at least one public resolver. - Sender: Check the relevant sender's current authentication or verification status. This is account-specific. A DNS answer alone cannot prove that a sender has enabled DKIM or uses the intended return path. - Message: Send a new message through the exact production path and inspect the receiving system's authentication results. Test each materially different sender separately. - DMARC: Review aggregate-report evidence after it has accumulated. Confirm which sources are sending for the domain and whether their authentication results align with the visible From domain. ![What a passing IONOS DMARC setup looks like: the authoritative TXT answer, per-sender authentication, an aligned dmarc=pass on a delivered message, and reports naming every legitimate source](/images/editorial/ionos-dmarc-setup/ionos-dmarc-setup-validation.webp "1200x524") *Source: Palisade.* Keep results in an acceptance record: ```yaml domain: yourdomain.com dns_owner: authoritative-dns-provider dmarc_dns_result: observed TXT value sender: application-or-mail-service sender_status: account-specific observed status message_path: production sender and test recipient authentication_results: redacted observed result dmarc_report_status: pending or reviewed checked_at: UTC timestamp ``` A setup is ready for the next policy decision only when the public record, sender configuration, delivered-message evidence, and report evidence agree. A passing result from one message does not prove every future message will authenticate or that a receiving system will place it in the inbox. ## Troubleshooting ### The DMARC record does not appear in public DNS Check the full record owner, the DNS provider's suffix behavior, and the authoritative DNS zone. Compare the value in the zone with the approved account-specific instruction. Do not assume a cached result is a sender failure until the authoritative answer has been checked. ### The record appears, but a sender still fails DMARC Start with a new message sent through the affected production path. Compare its visible From domain, SPF result, DKIM result, and any available authentication-result details with the sender's own configuration. The DNS record can be correct while the sender is unsigned, uses a different domain, or follows a different route than the one you tested. Work from message evidence before changing policy. ### The sender's interface looks verified, but the delivered message differs Treat the delivered message as the test of that production path. Confirm that the message was sent after the configuration change and that it came from the exact application under review. Then ask the sender owner to compare the observed result with its current account configuration. A provider status indicator and a received message answer different questions. Keep both pieces of evidence. ### You cannot find the IONOS DNS or email setting Use the current IONOS account documentation or contact IONOS support with the domain, product name, and task: publish or review a DMARC TXT record for the domain. Do not share passwords, private keys, unredacted message headers, or customer data in a support request. ## Check the public DMARC record before changing policy After you have the exact record approved for the domain, inspect the public DNS result with the [Palisade DMARC checker](/tools/dmarc). Compare its result with the value in authoritative DNS and with a fresh delivered message from the sender you are testing. [Check the DMARC record](/tools/dmarc) A public record check cannot confirm an IONOS account setting, repair sender authentication, show every production sending source, or prove a receiving system's private delivery decision. If you need an ongoing workflow after DNS is correct, Palisade can analyze DMARC aggregate-report data, identify sending sources and authentication or alignment issues, and create prioritized remediation tickets. The agent investigates every sender, drafts every fix, and proposes each policy step, and you approve before anything ships. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=dmarc&utm_content=ionos-dmarc-setup) ## Sources and further reading - [IONOS: Configuring a DMARC record for a domain](https://www.ionos.com/help/domains/configuring-mail-servers-and-other-related-records/configuring-a-dmarc-record-for-a-domain/) - [IONOS: Mail server details for IMAP, POP3 and SMTP](https://www.ionos.com/help/email/general-topics/ionos-mail-server-details-for-imap-pop3-and-smtp/) - [RFC 9989: Domain-based Message Authentication, Reporting, and Conformance](https://www.rfc-editor.org/rfc/rfc9989.html) - [Palisade guide to IONOS SPF setup](/learning/ionos-spf-setup) - [Palisade DMARC learning hub](/learning/dmarc) - [Palisade DMARC checker](/tools/dmarc) ## Frequently asked questions ### How do I set up DMARC correctly? Start by confirming the authoritative DNS provider, every sender that uses the visible From domain, and the exact record instruction approved for that domain. Then validate the published DNS answer, the sender's own status, a new delivered message, and DMARC reporting evidence before considering a stronger policy. ### What should my DMARC be set to? A DMARC value should be chosen from verified evidence about the senders that use the domain. Do not copy a policy or reporting address from another account. Begin with the account-specific instruction and keep a rollback copy of the prior DNS value. ### Do I need to set up DMARC? Only your organization's mail-sending and security requirements can determine that decision. If the domain sends mail, first inventory its senders and collect delivered-message evidence so that any DMARC policy does not disrupt legitimate mail. ### Is IONOS email POP3 or IMAP? Yes to both. IONOS Mail supports IMAP at `imap.ionos.com` on port 993 and POP3 at `pop.ionos.com` on port 995, each over SSL/TLS, with outgoing mail on `smtp.ionos.com` port 465. IONOS recommends IMAP, because POP3 usually downloads messages to one device and deletes them from the server, so nothing stays in sync. The mailbox protocol has no effect on DMARC, which the receiving system evaluates from the message and your DNS records. ### Can a DMARC checker prove that IONOS email is configured correctly? No. A public checker can inspect the DNS record that a domain publishes. It cannot prove that an IONOS account signs production mail correctly, that every sender aligns, or that a recipient will deliver a message to the inbox. --- # IONOS SPF setup Canonical: https://www.palisade.email/learning/ionos-spf-setup > IONOS SPF setup starts with your sending inventory, authoritative DNS access, and a safe validation plan before any TXT-record change in production. IONOS SPF setup means publishing or updating the SPF TXT record for a domain whose DNS you manage through IONOS, then confirming the exact production sending path uses it as intended. Start by identifying every service that sends with the domain and locating the current DNS record. Do not add a second SPF record or copy a value from another account before you have the sender-specific instructions and a rollback plan. ## Quick takeaways - SPF setup depends on the services that send mail for your domain, not on one universal IONOS value. - IONOS offers domain and email products, but the DNS settings path and field labels must be confirmed in current IONOS documentation or your authenticated account. - Record the existing DNS state before editing anything. - Keep one change scoped to one domain and one approved sending inventory. - Validate public DNS, sender status, a newly delivered message, and later DMARC reporting separately. - A public SPF lookup cannot prove that every application uses the intended production sending path. ## Scope and prerequisites This procedure applies when IONOS is responsible for the DNS zone that publishes the domain's TXT records. IONOS lists domain and email offerings on its [product homepage](https://ionos.com), but the homepage is not a DNS configuration guide. Confirm the current IONOS Help Center instructions or the authenticated DNS interface before changing records. Identify the domain that appears in the envelope sender or return-path for the sending service you are configuring. The visible From domain alone does not identify the SPF identity to inspect. If different systems send mail for the organization, document each system separately before altering the record. For the change window, assign these roles: - The application owner confirms which service sends the message and provides its current SPF setup instructions. - The DNS owner can inspect and publish records in the authoritative zone. - The mail owner can send a new production-path test and obtain its delivered headers. - The reviewer decides whether the evidence supports keeping the change or restoring the prior DNS state. Capture the current record before editing it. Keep the current TXT owner, complete value, TTL if visible, the time observed, and the person responsible for the change. If the domain already has an SPF-related TXT record, stop and compare it with the sender's official instructions. Replacing or supplementing an existing record without an approved merge plan can change authentication for unrelated mail. Use this change record as a minimum handoff: ```yaml domain: yourdomain.com dns_owner: existing_txt_records: sending_service: sender_instruction: test_recipient: rollback_record: ``` The rollback condition is any result that conflicts with the intended record, an unexpected sender failure, or missing evidence about an existing record. Restore the captured known-good DNS state only after the DNS owner and application owner agree that the new change caused the issue. For SPF concepts before making an IONOS DNS change, review [Palisade's SPF learning hub](/learning/spf) and the overview of [email authentication](/learning/email-authentication). SPF is one part of an authentication setup. It does not replace DKIM or DMARC planning. ![IONOS product overview for domain and email services](/images/editorial/ionos-spf-setup/ionos-spf-setup-shot-1.png "1600x900") *Source: https://ionos.com* ## Choose the implementation approach Choose the approach based on the sender inventory and the DNS record already published for the domain. - If no SPF record exists, obtain the exact record instruction from every approved sending service before publishing a new record. - If an SPF record already exists, treat the work as a controlled merge. Confirm how each approved sender's instruction fits into the existing value before editing. - If a service sends through a different domain, subdomain, or return-path domain, do not assume the IONOS zone for the visible From domain is the place to edit. - If ownership of the domain's DNS is unclear, identify the authoritative DNS provider before opening any IONOS setting. Do not use an IONOS email product page, another customer's DNS value, or a generic online example as the source for a production SPF value. The sending service determines the values it requires. IONOS is the DNS management location only when it is authoritative for the relevant domain. The implementation decision is simple: publish the exact approved record only after you know whether it is a new record or an edit to the one existing SPF record. If that distinction is not clear, pause the change. ![Decision flow for confirming the sending service, existing DNS state, approved SPF value, and four validation layers](/images/editorial/ionos-spf-setup/ionos-spf-setup-spf-decision-flow.webp "1200x829") *Source: Palisade.* ## How to configure an SPF record in IONOS ### 1. Confirm the sending domain and current DNS authority Start with a recent message sent through the exact application you need to authorize. Record the return-path or envelope-sender domain from the message evidence, then establish which organization controls the authoritative DNS zone for that domain. Do not rely on an old implementation note. A domain can use IONOS for email, hosting, or registration while DNS is managed elsewhere. ### 2. Obtain the sender-specific SPF instruction Open the official setup documentation for the service that sends the mail. Obtain its current SPF instruction, the domain it applies to, and any instruction about coexistence with other sending services. The sender's documentation is the required source for the record value. Do not publish a universal IONOS SPF value because no such value applies to every sender configuration. > Do not replace a current TXT record until the DNS owner has captured it and the sending-service owner has approved the proposed merged state. A DNS record that looks unrelated may support another production mail stream. ### 3. Inspect the existing TXT records in the IONOS-managed zone Use the current IONOS DNS documentation or authenticated control panel to locate the TXT records for the confirmed domain. The exact navigation path, form labels, and save behavior can change, so follow the current IONOS instructions rather than a copied screen path. Look for records at the domain name and any relevant subdomain. Record what exists before creating or editing anything. If an SPF record is present, compare its full value with the sender inventory. Do not create another SPF record merely because a sender has supplied an additional mechanism. The following is an illustrative change description, not a production DNS value: ```text Owner: yourdomain.com Type: TXT Value: ``` Replace the placeholder only with a value approved from the current documentation for the services that send your mail. Do not publish a selector, hostname, token, or include value copied from another tenant. ### 4. Apply the approved DNS change Make the smallest DNS change that implements the approved sender inventory. Keep a copy of the prior record and the exact new value entered. Record the time of the save and any TTL shown by the DNS interface. If the IONOS interface shows a warning, conflict, or record-normalization message, do not infer what it means. Compare it with current official IONOS guidance or escalate it to the DNS owner before saving. ### 5. Keep the change scoped Do not combine SPF work with DKIM, DMARC policy, MX, or mail-routing changes in the same unreviewed update. Separate changes make it possible to identify which action caused an unexpected result. When a sender also needs DKIM, use its official instructions for that configuration. For example, [Customer.io SPF and DKIM setup](/learning/how-do-i-set-up-spf-and-dkim-for-customer-io) and [HubSpot SPF and DKIM setup](/learning/how-do-i-set-up-spf-and-dkim-for-hubspot) are separate sender-specific tasks. ## How to validate the setup Treat DNS publication, sender status, delivered-message authentication, and DMARC reporting as independent checks. - DNS: Query the authoritative DNS source for the exact domain and compare the returned TXT record with the approved change. Then check at least one public resolver. Record the observed values and timestamps. - Sender: Use the sending service's own status or verification method when it provides one. A green status does not prove that a new production message used the expected path. - Message: Send a new message through the exact application, account, and route you configured. Inspect the recipient-side message headers and preserve the authentication result with sensitive data redacted. - DMARC: Once aggregate-report data accumulates, inspect the production source's SPF result and alignment outcome over time. This is the layer that shows whether the observed sender appears in reporting, rather than only in one test message. A reliable acceptance record connects each result to the same domain and sender: ```yaml domain: yourdomain.com sender: dns_result: sender_status: message_result: dmarc_result: checked_at: ``` A passing DNS lookup means the public record can be retrieved. It does not prove that the application uses the expected return path, that all mail streams are covered, or that a receiving mailbox will make a particular delivery decision. ## Troubleshooting ### I cannot find the DNS record controls in IONOS Confirm first that IONOS is authoritative for the domain's DNS. Then use current official IONOS Help Center guidance or ask the domain administrator for the documented DNS-management path. Do not use a third-party walkthrough as evidence for the current control-panel labels. ### An SPF-related TXT record already exists Do not add a second record before determining its purpose. Capture the complete record and compare it with the current sender inventory. Ask the sender owner for its official merge instructions when a new sending service must be added. ### The public result does not match the record I entered Compare the full domain name, record type, and value with the change log. Then query the authoritative DNS source and a public resolver. If the answers differ, preserve both observations and avoid further edits until the DNS owner confirms the intended state. ### DNS looks correct but a new message still has an authentication problem Check a newly delivered message from the exact production path. Confirm the application, account, return-path domain, and recipient are the ones you intended to test. A public DNS result does not establish that a sender used that record. ### The sender's documentation conflicts with the existing record Pause the change. The existing record may support a different approved source. Obtain an approved record plan from the owners of every sending system before changing DNS. ## Check the SPF record before relying on the change After the DNS owner has published the approved value, [inspect the domain with Palisade's SPF checker](/tools/spf). Compare the public result with the exact record captured in the change log, then compare both with a new message from the production sender. For an ongoing domain portfolio, Palisade is agentic DMARC software that analyzes DMARC aggregate-report data, identifies sending sources and authentication or alignment issues, and creates prioritized remediation tickets. It can propose a next DMARC policy step when the evidence supports it, while a human reviews the evidence and applies the change. That workflow does not replace IONOS DNS ownership, change DNS automatically, or guarantee receiver delivery decisions. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=vendor_setup&utm_content=ionos-spf-setup) The SPF checker inspects public DNS. It cannot prove the production sending path, continuously monitor later DNS changes, repair a sender configuration, or guarantee inbox placement. ## Sources and further reading - [IONOS homepage](https://ionos.com) - [Palisade SPF learning hub](/learning/spf) - [Palisade SPF checker](/tools/spf) - [Palisade email authentication guide](/learning/email-authentication) ## Frequently asked questions ### Can I use one SPF value for every IONOS domain? No. The SPF value must reflect the approved services that send mail for the specific domain. Obtain the value from the current documentation for those sending services. ### Should I add another SPF TXT record when a new sender needs authorization? No. First inspect the existing TXT records and obtain an approved merge plan. Adding a second SPF-related record without understanding the current state can create an ambiguous or unsupported configuration. ### Does a public SPF check prove that IONOS email is configured correctly? No. A public check can inspect DNS. It does not prove that the mail application uses the expected production path or that a delivered message receives the intended authentication result. ### Can I follow an old IONOS control-panel walkthrough? Only if it matches current official IONOS documentation or the authenticated interface you can verify. DNS paths and field labels can change, so use current first-party guidance before editing a production record. ### Do I need to test a real message after changing SPF? Yes. Send a new message through the exact production application and inspect the delivered message evidence. DNS retrieval and a sender's verification status are separate from message-level validation. --- # Email sender spoof: how to spot and stop it Canonical: https://www.palisade.email/learning/email-address-spoofing-prevention > Email sender spoofing forges the visible From field. Learn which trusted header results expose it, why SPF alone is insufficient, and how DMARC helps. An email sender spoof is a message forged to look like it came from an address you trust, because plain SMTP never verifies the visible `From:` field. To spot one, read the receiving server's authentication results in the headers. To limit it on your own domain, publish and operate DMARC with aligned SPF or DKIM, then use DMARC reports to find legitimate sources before requesting stronger handling for failures. That controls exact-domain spoofing only. It does not stop lookalike domains, deceptive display names, or mail from a genuinely compromised account. ## Quick takeaways - The visible `From:` address is the identity DMARC evaluates. - SPF or DKIM must pass with a domain aligned to the visible `From:` domain for DMARC to pass. - DMARC lets a domain owner request handling for messages that fail that validation. - A receiving mailbox provider makes the final handling decision. - DMARC aggregate reports can reveal sources using a domain, but report delivery is not guaranteed. - A DMARC pass does not prove that a message is safe or that the sender's mailbox was not compromised. ## How an email sender spoof works Email address spoofing usually concerns unauthorized use of a domain in the visible `From:` field. [RFC 9989 defines DMARC](https://datatracker.ietf.org/doc/html/rfc9989) around that author domain because SPF and DKIM alone can authenticate domains that are not directly associated with the visible `From:` domain. DMARC connects those systems through identifier alignment. A message passes DMARC when SPF or DKIM passes and the authenticated SPF or DKIM domain aligns with the author domain. With relaxed alignment, related subdomains can align through their shared organizational domain. With strict alignment, the domains must be identical. The domain owner publishes a DMARC DNS TXT record that states a requested handling policy for failures and may request aggregate reports. A receiver can use that policy when deciding how to handle incoming mail, but [the DMARC specification leaves the final decision with the receiving organization](https://datatracker.ietf.org/doc/html/rfc9989#section-1). DMARC is designed to reduce successful exact-domain spoofing. It does not directly address a lookalike domain such as `yourd0main.com`, or a message that uses a trusted display name with a different address. Those are related threats, but they are not the same control problem. See [spoofing versus phishing](/learning/phishing-vs-spoofing-whats-the-difference) for the distinction between impersonating an identity and using that impersonation to obtain information or action. ![Decision flow showing when an email using yourdomain.com in the visible From field can pass DMARC through aligned SPF or DKIM, and when a DMARC policy can request handling for failure](/images/editorial/email-address-spoofing-prevention/email-address-spoofing-prevention-decision-flow.webp "1200x829") *Source: Palisade.* ## How to tell whether a message is a sender spoof You confirm a sender spoof by reading the receiving server's own authentication results, not the visible message. Two layers of checking apply: signals a reader can see without leaving the message, and the headers underneath it. Start with what is visible, because many forgeries expose a mismatch before you open the full source: - Read the domain character by character. Look for a swapped letter, a different suffix, or the real brand name placed inside someone else's domain. - Compare the display name with the full address. A familiar name can sit beside an unrelated mailbox. - Check whether the sending domain is plausible for the claimed organization. - Inspect the destination of each link without opening it. The visible label can differ from the actual destination. - Treat changed payment details, unexpected urgency, and first-time requests as reasons to verify through a separate contact path. Then open the full headers. In Gmail that is **Show original**; in Outlook, **Message, then Properties, then Internet headers**; in Apple Mail, **View, then Message, then All Headers**. Mobile apps often omit the option, so forward the message to yourself and open it on a desktop client. ![Checklist of the header lines to read in a suspicious message: dmarc, spf, dkim, the Received chain, and a mismatched Reply-To](/images/figures/email-sender-spoof-header-checks.webp "1200x582") *Source: Palisade.* Start with the `dmarc=` result because DMARC tests alignment with the visible From domain. A message can pass SPF for the attacker's own domain and still fail DMARC for the brand it is impersonating. Two more signals sit outside the authentication results. [SMTP servers prepend `Received:` trace fields](https://www.rfc-editor.org/rfc/rfc5321.html), so read from the earliest record added by infrastructure you trust and work upward. Earlier sender-supplied lines can be forged. Also check whether `Reply-To:` points somewhere different from `From:`. That mismatch is not proof of spoofing, but it tells you where a reply would go. An [email header analyzer](/tools/email-header-analyzer) can parse these fields and authentication results for the message you provide. If the message carries a link, resolve it before opening it. A [phishing link checker](/tools/phishing-link-checker) or a [URL reputation check](/tools/url-reputation) follows redirects and tests the destination without exposing your device. ## Common issues when verifying a sender Four situations account for most of the confusion when a result does not match what the message looks like. ### Why does mail from a real contact fail SPF or DKIM? Forwarding changes the SMTP client seen by the final receiver, which can break SPF. A mailing-list server can also modify signed content and break DKIM. Do not treat one failure as proof of forgery. Read the full DMARC result and the trusted `Received:` path, then confirm through a separate channel when the request is sensitive. ### Why does a message pass authentication but still feel wrong? Mail from a genuinely compromised mailbox authenticates correctly, because it really was sent by an authorized account. Authentication cannot help here. Fall back to behavioral signals: an unusual request, manufactured urgency, a change of payment details, or a reply address that does not match. When the request involves money, verify by phone regardless of what the headers say. ### Can link text be trusted when the domain looks right? Visible link text and even a hovered domain can be disguised with redirects and shorteners. Check the destination with a tool rather than by clicking. ### How do I tell whether my own domain is being spoofed? A single message tells you about one message. For a domain-wide view, read DMARC aggregate reports, covered under "What to check next" below. ## When the answer changes The right response depends on what is being impersonated and what evidence you have. If the message uses your exact domain in the visible `From:` field, DMARC is the domain-level control that applies. Start by inventorying real sending systems and confirm that each important mail path has an aligned SPF or DKIM pass. Then use DMARC reports to identify mail sources that still fail and remediate them before moving to a stronger policy. If the message uses a similar domain or only copies a person's display name, DMARC for your domain cannot directly prevent it. [RFC 9989 explicitly limits DMARC's direct protection to specific forms of exact-domain spoofing](https://datatracker.ietf.org/doc/html/rfc9989#section-2.2). If a message came from a legitimate but compromised mailbox, it may authenticate successfully. A DMARC pass validates authorized use of the author domain for that message. It does not make a claim about the message's safety, content, or the account holder's intent. Investigate suspected account compromise through the affected mail system and identity provider. For a recipient, treat an unexpected request for money, credentials, or sensitive information as suspicious even when the sender name looks familiar. [Google's phishing guidance](https://support.google.com/mail/answer/8253?hl=en) advises people to avoid interacting with suspicious requests and verify through an established, independent contact method. ## Worked example: what DMARC can establish This illustrative example shows a message claiming to be from `yourdomain.com`. Do not copy these values into a production configuration. Your sending service generates the real authentication details. ```text From: Billing Authentication-Results: receiver.example; spf=fail smtp.mailfrom=mailer.example; dkim=pass header.d=yourdomain.com; dmarc=pass header.from=yourdomain.com ``` The message can pass DMARC because DKIM passes with `header.d=yourdomain.com`, which aligns with the visible `From:` domain. The failed SPF result does not by itself make DMARC fail when aligned DKIM passes. `Authentication-Results` is a receiver-added field that records authentication assessments. [RFC 8601 defines its syntax and trust model](https://datatracker.ietf.org/doc/html/rfc8601): use the result added by the receiving system you trust, not a similarly named header injected earlier in transit. Use this decision rule: - An exact visible `From:` domain plus an aligned SPF or DKIM pass means DMARC can pass. - An exact visible `From:` domain with no aligned SPF or DKIM pass means DMARC fails when the receiver evaluates DMARC. - A DMARC failure can trigger the domain owner's published request, but it does not prove every receiver rejected the message. - A passing result does not rule out a compromised authorized sender. For the broader protocol controls, read the [email threats learning hub](/learning/threats). Email-address spoofing is distinct from IP spoofing, which concerns network source addresses rather than the visible identity in an email message. ## What to check next Start with the evidence you actually possess. If you are a domain owner, inspect the public DMARC record for the exact domain used in the visible `From:` field. Then verify each production sending path in four layers: - DNS: query the authoritative DNS service and a public resolver for the intended SPF, DKIM, and DMARC records. - Vendor: confirm that each sending service shows its domain authentication as complete. - Message: send a real message through each production path and inspect the trusted receiver's `Authentication-Results`. - DMARC: review aggregate reports after they accumulate to find sources and alignment failures. Do not move directly to a rejecting policy because a DNS record looks correct. A public lookup cannot prove that an application signs mail, uses the intended return path, or continues to do so after a later configuration change. If you received a suspicious message, preserve it for your security team or report it through your mail provider. Do not reply, open attachments, or use the message's contact details to verify it. If the message appears to come from a known contact, use an existing phone number, chat channel, or address book entry instead. A public [email security score check](/tools/email-security-score) can help you inspect exposed domain controls. It cannot establish the production sending path, a receiver's private filtering decision, or whether a particular message was spoofed. ## Review the broader email security controls Stopping sender spoofs requires more than a published record. Use the [email threats learning hub](/learning/threats) to place DMARC, SPF, DKIM, user reporting, and account security in the same operating plan, and [what an email security gateway is](/learning/email-security-gateway) for where an inbound product fits alongside them. [Check your email security score](/tools/email-security-score) A guide or public score cannot prove that every sender is aligned, repair a compromised mailbox, or guarantee inbox placement. ## Sources and further reading - [RFC 9989: Domain-based Message Authentication, Reporting, and Conformance](https://datatracker.ietf.org/doc/html/rfc9989) - [RFC 8601: Message Header Field for Indicating Message Authentication Status](https://datatracker.ietf.org/doc/html/rfc8601) - [RFC 5321: Simple Mail Transfer Protocol](https://www.rfc-editor.org/rfc/rfc5321.html) - [RFC 5322: Internet Message Format](https://datatracker.ietf.org/doc/html/rfc5322) - [Google: Avoid and report phishing emails](https://support.google.com/mail/answer/8253?hl=en) ## Frequently asked questions ### How can I stop my email address from being spoofed? You cannot prevent every deceptive email that names your organization, but you can limit exact-domain spoofing by deploying DMARC with aligned SPF or DKIM. Inventory legitimate senders first, validate their real mail, review DMARC reports, and then consider a stronger DMARC policy. ### Should I be worried if my email is spoofed? Take it seriously when the message asks for credentials, money, an attachment, or any unusual action, because that is where the harm happens. Do not use the message itself to verify the request. If you own the domain, check whether it used your exact domain, a lookalike domain, or an authorized account that may be compromised. ### How do spoof emails get my address? An attacker only needs to know your address, not to have access to your mailbox. [RFC 5322 defines the `From:` field as part of the message format](https://datatracker.ietf.org/doc/html/rfc5322), so a sender can put any text there. Addresses are usually picked up where they are already visible, such as a website or staff directory, a mailing list, an earlier email thread, or a leaked dataset. A spoofed message does not record where its sender found the address, so you cannot tell from the message alone. ### How do I check if my email is spoofed? Check the visible `From:` domain, then inspect trusted `Authentication-Results` from the receiving system for SPF, DKIM, and DMARC results. For a domain-wide view, review DMARC aggregate reports. Neither a single header nor a public DNS check proves all mail using the domain is legitimate. ### What should I do if I already replied or clicked? Treat it as an incident rather than a mistake to hide. If you entered credentials, change that password through the real site, not through any link in the message, and end active sessions where the service allows it. If you approved a payment or sent details, contact your finance team and your bank immediately, because recovery windows are short. Then report it through your organization's security process and preserve the original message with its headers, since that is the evidence an investigation needs. --- # 550 5.7 0 DMARC policy violation Canonical: https://www.palisade.email/learning/550-5-7-0-dmarc-policy-violation > 550 5.7 0 DMARC policy violation needs provider-specific evidence. Check the exact SMTP response, sending domain, and published DMARC record. A `550 5.7.0 DMARC policy violation` response indicates that a receiving or relay system refused a message and associated the refusal with a policy decision. The code alone does not safely identify the mailbox provider, the exact failed authentication check, or the correct DNS change. Preserve the complete SMTP response, identify the visible From domain and sending service, then compare that evidence with the published DMARC record. ## Quick takeaways - A `550 5.7.0` response is SMTP evidence from a specific receiving or relay path, not a complete diagnosis. - The same enhanced-status-code family can be used for different policy decisions by different systems. - Do not change a DMARC record until you know which domain and production sending path produced the refusal. - A public DMARC lookup can show the currently published record, but it cannot prove why one receiver refused one message. - The full bounce text, message headers, and receiving provider documentation are the evidence needed to connect a refusal to a particular authentication condition. ## Why a DMARC-related SMTP refusal needs more evidence DMARC is part of an email authentication decision, but an SMTP refusal is still made by the system receiving or relaying the message. The response may be generated by the recipient's mailbox provider, a secure email gateway, or another service in the delivery path. Without the complete response and the system that generated it, the phrase "DMARC policy violation" is too broad to map to one remediation. Keep the original bounce or delivery log. The useful evidence includes the recipient domain, the sending domain shown in the message, the server that returned the response, the timestamp, and the full unedited response text. If a delivered copy exists, preserve its raw headers as well. A DMARC-related decision can depend on identifiers that are not visible in a public DNS lookup. The domain in the visible From address may differ from the envelope sender or the domain used by a DKIM signature. A sending service can also use a subdomain with its own DMARC policy. For protocol context before reviewing the error, see [DMARC](/learning/dmarc). The safe decision rule is: - If you have only the short error text, collect the complete SMTP response and delivery-path evidence before changing DNS. - If you have the sending domain, inspect its public DMARC record and record the result. - If you have message headers, compare the authentication results with the exact sending path. - If the receiving provider publishes documentation for the exact response, use that provider guidance to determine the required repair. ![Decision record for investigating a 550 5.7.0 DMARC policy violation, starting with the full SMTP response and ending with record and message evidence](/images/editorial/550-5-7-0-dmarc-policy-violation/550-5-7-0-dmarc-policy-violation-decision-record.webp "1200x829") *Source: Palisade.* ## When the answer changes The next action changes with the evidence available. A message rejected by one recipient system is not proof that every recipient will make the same decision, and a passing public record lookup is not proof that the application sent with the expected authenticated identifiers. ### When the sender uses a subdomain Check the exact domain in the visible From address. A sending path that uses a subdomain can be subject to a distinct record or a subdomain policy. Read [DMARC policy for subdomains](/learning/dmarc-policy-for-subdomains) before assuming the organizational-domain record is the only relevant policy. ### When the error is from Microsoft 365 Do not treat every Microsoft 365 `550 5.7.x` response as the same condition. The existing guide on [Microsoft 365 550 5.7.x access denied errors](/learning/fix-microsoft-365-550-5-7-x-access-denied) covers a related error family, but the provider's complete response remains the evidence that determines whether the situations match. ### When the message was sent through a third-party service Identify the service and the domain configuration used for that specific message. A domain can have multiple legitimate sending sources, and one source can fail while another succeeds. Review the sending service's delivery logs and authentication status before publishing a replacement DNS record. > Do not replace a DMARC record because of one rejected message unless the affected sending source, visible From domain, and documented receiving-system condition are known. An incorrect change can disrupt legitimate mail from other sources. ## Worked evidence record Record the evidence in a ticket or incident note before making a change. Use placeholders, not customer data, when sharing the case outside the authorized team. ```text Observed response: 550 5.7.0 DMARC policy violation Recipient domain: recipient.example Visible From domain: yourdomain.com Envelope sender domain: [from the sending system] DKIM signing domain: [from the message headers] Returning server: [from the complete SMTP response] Sending service: [application, ESP, or relay] Published DMARC record: [current DNS result] Provider documentation: [exact URL for the returning system] ``` This record separates observations from conclusions. The response establishes that delivery failed at a particular point. It does not establish which identifier failed, whether SPF or DKIM was involved, or whether changing `p` will fix the message. For example, a lookup might return a DMARC TXT record shaped like this: ```text v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com ``` This is illustrative only. Do not publish this value unchanged. The record shows a requested DMARC policy and an aggregate-report destination, but it does not reveal the authentication outcome for the rejected message. Compare it with the headers and the sending service's evidence before deciding what to repair. ## Check the evidence you have Start with the input that can answer a narrow question. - If you have a domain name, [check the published DMARC record](/tools/dmarc) and save the result with the incident. - If you have a bounce, obtain the complete response and identify the returning server and recipient domain. - If you have message headers, inspect the authentication results from the actual production path. - If you have a provider-specific error reference, follow the documented condition for that provider instead of assuming a generic `550 5.7.0` interpretation. After the immediate case is understood, an IT team or MSP may need to review whether other sending sources use the same domain and have consistent authentication evidence. Palisade analyzes DMARC aggregate-report data, identifies sending sources and authentication or alignment issues, and creates prioritized remediation tickets. A human reviews the evidence and applies any DNS or policy change. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=dmarc_policy_alignment&utm_content=550-5-7-0-dmarc-policy-violation) A DMARC platform does not prove why a particular receiver returned this SMTP response, change the DMARC policy automatically, or guarantee future delivery. ## Sources and further reading - [Palisade DMARC checker](/tools/dmarc) - [DMARC learning center](/learning/dmarc) - [DMARC policy for subdomains](/learning/dmarc-policy-for-subdomains) - [SMTP error 550 5.7.509 and DMARC verification](/learning/smtp-error-codes/550-5-7-509) ## Frequently asked questions ### What is 550 5.7 0 DMARC policy violation? A `550 5.7.0 DMARC policy violation` is an SMTP rejection in which the receiving or relay server refused the message and tied that refusal to a policy decision about the sending domain. The short code does not identify the provider or the exact check that failed. Use the full SMTP response, the returning server, and the message's sending-domain evidence to work out what the system evaluated. ### What does DMARC violation mean? A DMARC violation means a receiver decided a message did not meet the DMARC requirements for the domain in its visible From address, usually because no passing SPF or DKIM result was aligned with that domain. Different systems apply the phrase to different conditions, so check the receiving provider's own documentation for the exact response you received. Do not assume it always points to the same SPF, DKIM, or DNS fault. ### How do I fix email error 550 5.7 1? Start with the complete `550 5.7.1` response and the documentation of the system that returned it, because 5.7.1 covers different conditions from 5.7.0 and often has nothing to do with DMARC. Identify the returning server, the recipient domain, and the sending application. Inspect that production path before you change any DNS record. ### How do I fix a DMARC policy? Identify every legitimate sending source for the domain first, then publish the policy that matches what those senders actually do. A public record check shows what DNS publishes, not whether each application authenticates correctly or whether a receiving provider will accept future messages. Change `p` only once the sender evidence supports it. ### Can a DMARC record check explain a rejected message? A DMARC record check cannot explain one rejection, because it only shows the TXT record published right now. It cannot show the headers from the rejected message, the receiver's private policy decision, or how the sending application authenticated. Pair the record result with the full bounce text and the raw headers. --- # DKIM record format Canonical: https://www.palisade.email/learning/dkim-record-format > DKIM record format uses a DNS TXT record at selector._domainkey.domain with a required public key in p=. Learn the valid tag structure and core rules. A DKIM record format is a DNS TXT record published at `._domainkey.`. Its value is a semicolon-separated tag list that contains a required `p=` tag with the public key. `v=DKIM1` is recommended and must be first when present. The selector and domain come from the sending message's `DKIM-Signature` header, so the exact hostname and key value must come from the sending platform. ## Quick takeaways - A DKIM public key record uses DNS TXT, according to [RFC 6376](https://www.rfc-editor.org/rfc/rfc6376.txt). - The lookup name is `._domainkey.`. - Only `p=` is required in the DKIM key record. - If present, `v=DKIM1` must be the first tag. - TXT chunks must join with no inserted whitespace, and a selector must have one unique TXT record. - A CNAME can delegate a selector to a vendor hostname, but DKIM ultimately reads a TXT record. ## How the DKIM record format works [DKIM](https://www.rfc-editor.org/rfc/rfc6376.txt) lets a receiving system retrieve a public key that corresponds to a signature on an email message. The signer places its domain in the signature's `d=` tag and its selector in `s=`. For `d=example.com` and `s=selector1`, the receiver queries: ```text selector1._domainkey.example.com ``` The `_domainkey` label is fixed by the DKIM DNS namespace. The selector is chosen by the signer, which lets one domain publish separate keys for different sending services or key changes. RFC 6376 defines DNS TXT as the required base binding for DKIM keys. A record is a tag list, with tags separated by semicolons. The central tag is `p=`, which carries the base64-encoded public-key data. Do not copy a public key from an example into production. Your email platform generates the matching private key and public key pair. The primary tags are: - `v=DKIM1`: Identifies the record version. It is recommended. If included, it must be first and must be exactly `DKIM1`. - `p=`: Contains the public key. It is required. An empty `p=` explicitly revokes that selector's key. - `k=`: Names the key type. RFC 6376 defaults to `rsa`; [RFC 8463](https://www.rfc-editor.org/rfc/rfc8463.txt) adds `ed25519`. - `h=`: Optionally limits acceptable hash algorithms. - `s=`: Optionally limits the service types for which the key applies. Its default is `*`. - `t=`: Optionally sets flags, including `y` for DKIM testing and `s` to limit the relationship between `i=` and `d=` domains. - `n=`: Optional human-readable notes. ![Record anatomy showing the DKIM selector hostname and the required public-key tag](/images/editorial/dkim-record-format/dkim-record-format-record-grammar.webp "1600x900") *Source: Palisade.* For the wider role of this record alongside SPF and DMARC, see the [DKIM learning hub](/learning/dkim). ## When a DKIM record is valid, delegated, or unusable A minimum valid DKIM key record can contain only `p=`. In practice, records commonly begin with `v=DKIM1;` followed by `k=` and `p=`. A record that starts with another version value must be discarded by a verifier. Treat these as separate checks: - The selector name must match the `s=` value in the message signature. - The domain after `_domainkey` must match the signature's `d=` value. - The `p=` value must be the public key generated for that selector. - The selector must return one usable TXT record. RFC 6376 says results are undefined when multiple TXT records exist for a selector. - Long TXT values may be split into quoted DNS strings, but resolvers must concatenate them with no intervening whitespace. A space inserted into the public key changes its value. > Do not replace an existing selector record with a new value until you know which sender uses it. Removing or changing the public key before the sender changes its matching private key can make legitimate DKIM signatures fail. A CNAME changes the lookup path, not the DKIM format. [RFC 1034's CNAME rules](https://www.rfc-editor.org/rfc/rfc1034.txt) allow a DNS name to be an alias for another canonical name. A sending vendor may ask you to publish a CNAME at `selector1._domainkey.example.com` that points to its hostname. The resolver follows that alias and retrieves the TXT record at the target. A CNAME node cannot also hold a TXT record. This distinction matters when reviewing vendor instructions. The record at your selector can be a CNAME delegation, while the DKIM key record that the verifier reads remains a TXT record. For that vendor-managed pattern, see [what a DKIM CNAME record is](/learning/dkim-cname). For RSA keys, RFC 6376 requires signers to use at least 1024-bit keys for long-lived keys. [Google's Gmail sender guidance](https://support.google.com/mail/answer/81126) requires at least 1024 bits for personal Gmail and recommends 2048 bits where the DNS provider supports it. RFC 6376 also notes that large keys can encounter DNS response-size constraints. ## Worked DKIM TXT record example RFC 6376 Appendix C provides this illustrative public-key record. The `$ORIGIN` line means the full owner name is `brisbane._domainkey.example.org.` ```text $ORIGIN _domainkey.example.org. brisbane IN TXT ("v=DKIM1; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQ" "KBgQDwIRP/UC3SBsEmGqZ9ZJW3/DkMoGeLnQg1fWn7/zYt" "IxN2SnFCjxOCKG9v3b4jYfcTNh5ijSsq631uBItLa7od+v" "/RtdC2UzJ1lWT947qR+Rcac2gbto/NMqJ0fzfVjH4OuKhi" "tdY9tf6mcwGjaNBcWToIMmPSPDdQPNUYckcQ2QIDAQAB") ``` The quoted strings form one logical TXT value. They do not add spaces between lines. In the RFC's matching signature example, `s=brisbane` identifies the selector and `d=example.com` identifies the signing domain. That example shows the format, not a reusable key. A real record needs the selector and `p=` value generated by the exact sender that will sign messages. If you need a visual example rather than a grammar explanation, read [what a DKIM record looks like](/learning/what-does-a-dkim-record-look-like). ## Check the record against the message evidence Start with the evidence you have: - If you have a delivered message, inspect its `DKIM-Signature` header for `d=` and `s=`. Those values produce the exact DNS name to query. - If you have only a domain and selector, use `dig` or another DNS lookup to retrieve the TXT or CNAME response. [This DKIM `dig` guide](/learning/dig-dkim-record) covers the command and how to interpret the result. - If DNS looks correct, check the sending platform's DKIM verification status and send a new message through the same production path. - Then inspect the delivered message's authentication results. A published public key does not prove that the application used the matching private key or that the signature passed. DNS publication is only the first validation layer. The sender's status and a real message header confirm different parts of the configuration. ## Look up the selector record you found When you have the domain and selector from a `DKIM-Signature` header, query that exact hostname and compare the DNS answer with the sending platform's generated record. [Inspect a DKIM record with dig](/learning/dig-dkim-record) A DNS lookup cannot prove that the application signed a specific message, that the public key matches its private key, or that a receiving mailbox provider accepted the message. ## Sources and further reading - [RFC 6376: DomainKeys Identified Mail Signatures](https://www.rfc-editor.org/rfc/rfc6376.txt) - [RFC 8463: Ed25519-SHA256 for DKIM](https://www.rfc-editor.org/rfc/rfc8463.txt) - [RFC 1034: Domain names concepts and facilities](https://www.rfc-editor.org/rfc/rfc1034.txt) - [Google Workspace Admin Help: Set up DKIM](https://support.google.com/mail/answer/81126) ## Frequently asked questions ### What is a valid DKIM record example? A valid example is the RFC 6376 Appendix C record beginning `v=DKIM1; p=...` at a selector hostname such as `brisbane._domainkey.example.org`. The record's public key is illustrative only. Your sending platform must generate your own selector and `p=` value. ### How do you write a DKIM record? Publish a TXT record at `._domainkey.` with a tag list containing `p=`. Include `v=DKIM1` first when you use it. Keep split TXT strings as one logical value with no inserted whitespace, and do not publish multiple TXT records for one selector. ### What does a DKIM TXT record look like? A DKIM TXT record usually starts with `v=DKIM1` and contains a long `p=` public key value. See [what a DKIM record looks like](/learning/what-does-a-dkim-record-look-like) for a focused example, then use this page to check the tag rules and DNS name. ### Is a DKIM record a TXT or CNAME? A DKIM key record is a TXT record. A sender may instead instruct you to publish a CNAME at the selector hostname, which DNS resolves to a vendor-hosted TXT record. The CNAME is a delegation mechanism, while the DKIM key itself remains TXT data. ### Can a DKIM record have an empty `p=` tag? Yes. RFC 6376 defines an empty `p=` value as a revoked public key. It tells verifiers that the selector is known but signatures that rely on that key should fail verification. --- # DMARC failure to load tld list Canonical: https://www.palisade.email/learning/dmarc-failure-to-load-tld-list > DMARC failure to load tld list is an unidentified product error. Capture its source and context, then validate the domain record separately. "DMARC failure to load tld list" is not a documented DMARC result on its own. The wording does not identify the product that displayed it, whether it came from a browser page, API, or email message, or whether it affects DNS lookup, report processing, or a domain-entry check. Preserve the error and its context first. Then check the affected domain's published DMARC record separately. ## Quick takeaways - "failure to load tld list" does not, by itself, prove a DMARC authentication failure. - The product, screen or endpoint, timestamp, and affected domain are needed before a cause can be assigned. - A public DMARC record check can confirm whether a record is published, but it cannot explain an unidentified product loading error. - Do not change the DMARC policy to address this message. A policy change does not establish what failed to load. - Once the product-specific issue is resolved, use reporting and received-message evidence to validate the production sending path. ## What does the failure mean? The exact observable symptom is: ```text failure to load tld list ``` No identified provider documentation defines this string as a DMARC protocol error, a DNS response, a mailbox-provider rejection, or a report-processing result. It therefore cannot establish that the domain's DMARC record is absent, malformed, or causing delivery failures. A DMARC setup workflow can include configuring a domain, DMARC policy, and aggregate reporting, publishing the record in DNS, monitoring results, and later moving from `p=none` to `p=quarantine` or `p=reject`. [PowerDMARC describes that implementation sequence](https://powerdmarc.com/), but it does not define "failure to load tld list" or provide a repair for the message. Treat the error as evidence about the product that displayed it until that product documents otherwise. The [DMARC learning hub](/learning/dmarc) can help with the protocol and record context, but it cannot turn an unidentified UI message into a DMARC diagnosis. ![Diagnostic flow showing how to identify the product that displayed a TLD-list error, preserve context, check the DMARC record separately, and validate through the affected path](/images/editorial/dmarc-failure-to-load-tld-list/dmarc-failure-to-load-tld-list-diagnostic-flow.webp "1200x856") *Source: Palisade.* ## What usually causes it? ### The emitting product has not been identified The message may appear in a browser interface, a product API response, a browser console, or another system. Without the emitting product, there is no supported mapping from the wording to a function, cause, or repair. This is an evidence gap, not a documented DMARC cause. Record the product name, URL or endpoint, page title, and time of the failure before changing DNS or mail settings. ### The affected function is unknown A TLD list could be used by a product for domain input validation, lookup logic, report handling, or another internal function. The displayed text does not say which function failed. Do not infer that the error blocks DMARC evaluation. A domain-entry validation issue and a DMARC DNS lookup are different operations unless the product's documentation states that they are the same. ### The evidence is not tied to an affected domain or message A DMARC troubleshooting conclusion needs evidence linked to the domain or message path in question. For a DNS concern, preserve the queried domain and the returned result. For an authentication concern, preserve the trusted receiving system's authentication result from the delivered message. If the error appears without a domain, sender, recipient, or message identifier, it cannot be connected to a particular DMARC implementation. ### A separate DMARC record issue may exist A domain can have a published-record problem at the same time that a product shows an unrelated loading message. That possibility is an inference, not an explanation for this error. Use a record check only to inspect the public DMARC record. Do not treat a record result as proof that the product's TLD list loaded, that a production sender authenticates, or that a mailbox provider will accept a message. ## How do I diagnose the failure? ### 1. Identify where the exact string appears Record the product name and the precise location where "failure to load tld list" appears. Preserve the page URL, API endpoint if visible, timestamp, account or workspace context, and the domain entered at the time. If the message appears in a browser, retain a redacted capture that includes the surrounding page context. If it appears in an API response, preserve the exact response text and status information after removing credentials, tokens, and customer data. Do not rely on a paraphrase such as "the DMARC page failed." The literal string and its location are the starting evidence. ### 2. Check the product's official documentation and status information Search the affected product's official documentation for the exact phrase. Also check its official status information and support guidance for the relevant feature. The outcome of this step should be one of two clear findings: - The provider documents what the string means and gives a supported repair or retry path. - The provider does not document the string, so the issue needs provider support with the preserved evidence. Avoid changing network, DNS, or policy settings before this distinction is clear. Such changes may alter a working domain configuration without addressing the function that displayed the message. ### 3. Separate the public DMARC record from the loading error Once you know the affected domain, [check its DMARC record](/tools/dmarc). Compare the returned record with the domain you intended to inspect, including the exact organizational domain and any subdomain involved in the product workflow. A public check is useful for a narrow question: whether the domain has a publicly discoverable DMARC record at the time of the check. It is not evidence that the product's domain list is available, that aggregate reports are processing, or that a sender's messages pass DMARC. Keep the result with the incident notes. It prevents a separate public-record concern from being confused with the unidentified loading error. ### 4. Preserve received-message evidence only if mail is also failing If the report includes a delivery or authentication problem, obtain the full raw source of a message sent through the exact production path. Record the trusted receiving system's `Authentication-Results` header and redact addresses and other private data before sharing it. Do not infer an authentication failure from the TLD-list wording. The [DMARC alignment failure guide](/learning/dmarc-alignment-failure) is relevant only when message evidence identifies alignment as the issue. ### 5. Escalate with a bounded problem statement Send the product's support channel the exact error, affected time, affected domain, page or endpoint, redacted capture or response, and the result of any separate public DMARC record check. Ask what feature uses the TLD list, whether a known service condition applies, and what verification confirms recovery. This keeps the request focused on the product-controlled failure. It also gives support enough context to distinguish a loading issue from a configuration or protocol issue. ## How do I fix it? ### Follow the affected product's documented repair Use a repair only when the product that emitted the string documents its meaning and the required action. The available evidence does not support a universal configuration change, DNS edit, allowlist rule, or retry sequence for this error. If the provider identifies a service condition, follow its stated recovery or validation process. If it identifies a domain-input or configuration requirement, apply only that requirement to the affected function. > Do not loosen the DMARC policy to make this error disappear. Changing `p=` changes requested enforcement, but it does not identify, repair, or validate a TLD-list loading failure. ### Correct a separately confirmed DMARC record issue If the record check identifies a separate publication problem, repair that issue according to the DNS provider and the DMARC implementation workflow. The implementation sequence described by [PowerDMARC](https://powerdmarc.com/) includes configuring the domain, policy, and aggregate reporting, then publishing the record in DNS. That is a record-publication branch, not a documented fix for the TLD-list message. Keep the two incident tracks separate until the product confirms a relationship. ### Escalate an undocumented product error If official documentation does not define the error, do not invent a repair from the phrase. Provide support with the preserved context and ask for the product-specific cause, remediation, and validation method. A support response may identify an external dependency, a temporary product condition, or a domain-specific input issue. Until that response is documented for the affected product, those remain possibilities rather than established causes. ## How do I validate the repair? Repeat the same action that produced "failure to load tld list" in the same product, with the same affected domain and account context. Confirm that the product's documented success state appears or that its support team confirms the expected result. Validate the DMARC implementation independently: - Check the intended domain's public record through the [DMARC checker](/tools/dmarc). - Confirm the vendor's own status where the vendor provides one. - Send a new message through the exact production path and inspect the trusted receiver-added authentication results if mail authentication was part of the incident. - Review DMARC aggregate-report data after it has accumulated when the domain uses reporting. A successful public DNS lookup does not prove that the loading error is repaired. It also does not prove the production sender uses the expected authentication path, that future messages will authenticate, or that a receiver will make a particular delivery decision. ## Check the domain record after identifying the affected product Once you have the domain involved in the error, inspect its public DMARC record before making a DNS change. This helps separate a record-publication issue from a product loading failure. [Check the DMARC record](/tools/dmarc) A record check cannot identify which product emitted "failure to load tld list," repair that product's dependency, monitor its future state, or prove why an individual receiver accepted or rejected a message. If the domain has multiple senders or recurring DMARC-report work, Palisade is agentic DMARC software that analyzes aggregate-report data, identifies sending sources and authentication or alignment issues, and creates prioritized remediation tickets. It proposes the next policy step from the evidence, while a human reviews and applies any change. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=dmarc_troubleshooting&utm_content=dmarc-failure-to-load-tld-list). Palisade does not repair an unidentified third-party TLD-list loading error or control that provider's service state. For larger domain inventories, [bulk DMARC checking](/learning/bulk-dmarc-checker) can help establish which domains have publicly visible records. It still does not prove how a particular product handles a TLD list. ## Sources and further reading - [PowerDMARC DMARC implementation workflow](https://powerdmarc.com/) - [Palisade DMARC learning center](/learning/dmarc) - [Palisade DMARC checker](/tools/dmarc) - [Palisade guide to DMARC alignment failure](/learning/dmarc-alignment-failure) ## Frequently asked questions ### How do I fix DMARC authentication failure? Start with a message that actually failed and read the receiving system's `Authentication-Results` header, which shows which mechanism or alignment condition broke. Repair that specific condition, then send a new message through the same production path to confirm the result. The string "failure to load tld list" does not identify an authentication failure, so it is not the place to start. ### How to solve DMARC issue? Name the observable symptom first, because "DMARC issue" covers several different problems with different repairs. For "failure to load tld list," identify the product that displayed the string and follow its official documentation or support guidance. Check the domain's public DMARC record separately, since that check cannot explain a product's loading error. ### What causes DMARC failure? A DMARC failure is caused by something in the message path, so the cause sits in evidence tied to the affected domain, a received message, or a DNS result. The string "failure to load tld list" is not one of those causes and no provider documents it as one. If a message really did fail authentication, work from the receiver's authentication results and the [DMARC alignment failure guide](/learning/dmarc-alignment-failure). ### How do I enable DMARC for my domain? Configure the domain, DMARC policy, and aggregate reporting, then publish the DMARC record in DNS. [PowerDMARC describes this as an implementation workflow](https://powerdmarc.com/). Its workflow does not provide universal record syntax or a vendor-neutral validation procedure. ### Does a published DMARC record fix a TLD-list loading error? No, because the record lives in your DNS while the error belongs to the product that displayed it. A record check answers a public DNS question and nothing more. Use the affected product's own validation step once you have identified where the error came from. --- # DMARC meaning in networking Canonical: https://www.palisade.email/learning/dmarc-meaning-in-networking > DMARC meaning in networking: a DNS-based email-authentication protocol that validates authorized use of a From domain and requests handling. DMARC means Domain-based Message Authentication, Reporting, and Conformance. In networking, it is an email-authentication protocol that lets a domain owner publish a DNS policy for messages that use its visible From domain. A receiver evaluates whether SPF or DKIM passed with an aligned domain, then can consider the domain owner's requested handling for a DMARC failure. The receiver still makes its own delivery decision. ## Quick takeaways - DMARC is an email protocol, not a replacement for DNS. - A DMARC pass needs an aligned SPF pass or DKIM pass for the visible From domain. - The DMARC policy record is a DNS TXT record, usually published at `_dmarc.yourdomain.com`. - `p=none`, `p=quarantine`, and `p=reject` express a domain owner's requested handling for DMARC failures. - A receiving mail system can use the request in its filtering decision, but it does not have to follow it exactly. - A DMARC pass does not guarantee inbox placement or prove that every future message will authenticate. ## How DMARC works in a network [The IETF DMARC standard](https://datatracker.ietf.org/doc/html/rfc9989) defines DMARC as a protocol through which an email's Author Domain owner can validate use of that domain, publish a handling preference for failed validation, and request reports about its use. The Author Domain is the domain in the message's visible `From:` address. DMARC checks whether the message has either: - An SPF pass whose authenticated domain aligns with the Author Domain. - A DKIM pass whose signing domain aligns with the Author Domain. Alignment connects the passing authentication identifier to the domain a recipient sees in `From:`. Under relaxed alignment, the domains share the same organizational domain. Under strict alignment, they must be identical. [RFC 9989's DMARC overview](https://datatracker.ietf.org/doc/html/rfc9989#section-4.4) defines both modes and explains that a DMARC pass requires a passing, aligned identifier. A receiver looks up the applicable DMARC policy in DNS, evaluates SPF and DKIM, then determines a DMARC result. If the result is a failure, the published policy can inform the receiver's handling decision. The receiver can also use reputation, content filtering, and local policy. [RFC 9989 requires receivers not to reject mail solely because a domain publishes `p=reject`](https://datatracker.ietf.org/doc/html/rfc9989#section-5.4). For a broader introduction to the protocol and rollout, see the [DMARC learning hub](/learning/dmarc). ![Decision flow showing that DMARC evaluates aligned SPF or DKIM before a receiving mail system considers the published policy](/images/editorial/dmarc-meaning-in-networking/dmarc-meaning-in-networking-decision-flow.webp "1200x676") *Source: Palisade.* ## When the meaning changes in practice DMARC has a narrow job: validate authorized use of the visible From domain for an individual message. It does not certify a sender as trustworthy, prevent every type of phishing, or guarantee placement in a recipient's inbox. The IETF standard says a DMARC pass validates authorized use of the Author Domain for that message, but a receiver can still quarantine or reject it under its own policies. The practical decision rule is: - If SPF or DKIM passes with an aligned domain, DMARC passes. - If neither SPF nor DKIM produces an aligned pass, DMARC fails when an applicable policy record exists. - If no applicable DMARC policy record exists, the DMARC result is `none`, rather than pass or fail. A domain can choose not to publish a DMARC record. That means it does not participate in DMARC validation through a policy record. It does not mean that SPF, DKIM, or a receiver's own anti-abuse systems stop operating. DMARC is not universally necessary for every networked system. It is necessary when your organization needs the protocol's domain-use validation, policy publication, or reporting framework. A domain owner that wants full DMARC participation must publish a DMARC policy record, send aligned authenticated mail, and receive and analyze aggregate reports under [RFC 9989's conformance requirements](https://datatracker.ietf.org/doc/html/rfc9989#section-8). A team should also check the current requirements of each mailbox provider it sends to. ## A worked DMARC record example A DMARC policy record is stored as a DNS TXT record whose name begins with `_dmarc`. [RFC 9989 specifies `_dmarc.example.com` as the lookup pattern](https://datatracker.ietf.org/doc/html/rfc9989#section-4.5). ```text Host: _dmarc.yourdomain.com Type: TXT Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com ``` This is an illustrative example. Do not publish the reporting address or record value unchanged. Use the addresses and policy approved for your domain. The record has three useful parts: - `v=DMARC1` identifies the TXT value as a DMARC policy record. It must be the first tag. - `p=none` expresses no handling preference for messages that fail DMARC. It is often used while a team collects information about legitimate sources. - `rua=mailto:dmarc-reports@yourdomain.com` requests aggregate feedback reports at that address. The policy can instead be `p=quarantine`, which treats DMARC failures as suspicious, or `p=reject`, which expresses that failures indicate unauthorized use. [The registered `p` values and their meanings are defined in RFC 9989](https://datatracker.ietf.org/doc/html/rfc9989#section-4.7). DNS and DMARC are therefore different layers. DNS is the distributed naming and record-query system. [RFC 1034 describes DNS resource records, name servers, and resolvers](https://www.rfc-editor.org/rfc/rfc1034.html). DMARC is one email-authentication protocol that uses a DNS TXT record to publish its policy. DNS can store many other record types and supports many services besides email. A DMARC record lookup shows what is publicly published. It does not show whether each production application signs mail correctly or whether its SPF identifier aligns. For related tag detail, see [what the DMARC `fo` tag means](/learning/dmarc-fo-tag). ## What to check next Choose the next check based on the evidence you have: - If you only have a domain name, look up its public DMARC record and read the hostname, policy, and reporting address. - If you have a delivered message, inspect its authentication results to confirm whether SPF or DKIM passed with alignment. - If you are considering a stronger policy, use aggregate reports to identify legitimate sending sources before changing DNS. - If a message already bounced, compare the bounce with message-header evidence and see [how to fix "email rejected per DMARC policy"](/learning/email-rejected-per-dmarc-policy). Check DNS through the authoritative server and at least one public resolver after a DNS change. Then validate the vendor's sending status and send a real message through the production path. As aggregate reports accumulate, use them to find sources that still fail DMARC. A green DNS result alone does not prove that an application is signing mail or using the intended return path. ## Check the published DMARC record If you have a domain name and want to confirm what the public DNS currently publishes, inspect the record before making a policy decision. [Check the DMARC record](/tools/dmarc) A record lookup cannot prove why a specific receiver accepted or rejected a message, whether every production sender aligns, or how future mail will be placed. Once the lookup exposes an ongoing need to inventory sending sources and prioritize alignment work, Palisade's DMARC software can analyze DMARC aggregate-report data, identify sources and alignment issues, and propose the next policy step for human review. It does not change the DMARC policy or control a receiver's delivery decision. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=dmarc_fundamentals&utm_content=dmarc-meaning-in-networking) ## Sources and further reading - [RFC 9989: Domain-based Message Authentication, Reporting, and Conformance](https://datatracker.ietf.org/doc/html/rfc9989) - [RFC 1034: Domain names, concepts and facilities](https://www.rfc-editor.org/rfc/rfc1034.html) - [Palisade DMARC checker](/tools/dmarc) ## Frequently asked questions ### What is DMARC and how does it work? DMARC is an email-authentication protocol that validates whether SPF or DKIM passed with a domain aligned to the visible From domain. The domain owner publishes a DNS policy record, and a receiving mail system can use that policy when DMARC fails. ### Is DMARC really necessary? No. DMARC is not a universal requirement of networking. It is needed when a domain owner wants DMARC's validation, policy, and reporting functions, or when a receiver's current sender rules require it. A domain that fully participates in DMARC must publish a policy record and send aligned authenticated mail. ### What is an example of a DMARC? An example is `v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com`, published as a TXT record at `_dmarc.yourdomain.com`. It identifies the record as DMARC, requests no special handling preference for failures, and requests aggregate reports at the listed address. ### What is the difference between DNS and DMARC? DNS is the system that stores and answers queries for domain-related records. DMARC is an email-authentication protocol that uses a DNS TXT record to publish a domain owner's policy and reporting preferences. ### Does DMARC replace SPF or DKIM? No. DMARC uses SPF and DKIM authentication results. A DMARC pass requires an SPF or DKIM pass that aligns with the visible From domain. --- # Gmail rejected email from my domain Canonical: https://www.palisade.email/learning/gmail-rejected-email-from-my-domain > Gmail rejected email from my domain: read the SMTP code, identify the sending path, and fix SPF, DKIM, DMARC, TLS, PTR, or reputation evidence. Gmail rejected email from your domain when the exact sending path failed a receiver requirement or Gmail made a message, IP, or reputation decision. Start with the full SMTP bounce and identify whether it names authentication, TLS, PTR, message format, or unsolicited mail. Gmail does not provide one universal sender settings page for this diagnosis. The repair belongs in the service and DNS zone that sent the rejected message, as covered in the wider [email sender setup hub](/learning/esp-setup). ## Quick takeaways - A Gmail 5xx SMTP response is a rejection, while a 4xx response is a temporary deferral that the sender should retry. - The three documented 5.7.26 messages have different causes: missing SPF or DKIM, an SPF `-all` mismatch, or the sender domain's own DMARC policy. - A published SPF, DKIM, or DMARC record does not prove the production sender used it successfully. - Gmail's sender guidelines apply to mail sent to personal Gmail accounts, not messages sent to Google Workspace accounts. - Gmail documents blocked messages and blocked sending IP traffic, but does not document a durable domain-level block status that senders can look up. - Reputation-related remediation depends on the SMTP evidence and sending behavior, not on changing a DMARC record alone. ## What should I check before configuring Gmail? First, determine which system actually sent the rejected message. That may be a marketing platform, transactional provider, Google Workspace, a CRM, an application, or a server sending directly to Gmail. Collect the complete SMTP bounce, the envelope sender, visible From domain, sending IP if shown, and a new delivered-message header from the same route if one is available. Google states that its [Email sender guidelines](https://support.google.com/mail/answer/81126) apply to messages sent to personal Gmail accounts. A failed delivery to a Google Workspace recipient may have a different recipient policy or routing cause. Do not assume Gmail's published sender-requirement mapping explains every Workspace rejection. Confirm who can change the relevant DNS zone and who administers the sender. SPF and DMARC records can be shared by several services. DKIM selectors and vendor DNS targets are generated in the account that owns the sending path. > Copy DNS values from the account and domain you are configuring. Do not publish selectors, targets, tokens, or hostnames from another account or from an online example. Also identify whether the rejection concerns marketing mail, transactional mail, or employee mailbox mail. A change that fixes one route can leave another route unauthenticated. ## Which setup method should I use? Use the bounce code to choose the next check. Do not begin by replacing DNS records from an online example or by treating a message-level block as proof that the whole domain is blocked. Google's [Gmail SMTP errors and codes](https://knowledge.workspace.google.com/admin/support/troubleshooting/gmail-smtp-errors-and-codes) distinguishes authentication, TLS, reverse DNS, formatting, and reputation failures. If the code is 5.7.26, 5.7.27, or 5.7.30, inspect the sender's authentication or transport configuration. If it is 5.7.25, work with the owner of the sending IP and its reverse DNS. If it is a 5.7.1 or 5.7.28 reputation message, preserve the evidence and review sending practices before making DNS changes. Use automatic DNS publishing only when the sender account is authorized to update the correct DNS zone and its generated values match the selected domain. Use manual DNS when your DNS provider, change-control process, or security policy requires review. A dedicated IP is relevant only when the provider has assigned that IP to your production sending path. It does not repair an SPF, DKIM, DMARC, TLS, or message-format failure by itself. ![Decision flow for matching a Gmail SMTP rejection to the responsible sending path](/images/editorial/gmail-rejected-email-from-my-domain/gmail-rejected-email-from-my-domain-decision-flow.webp "1200x829") *Source: Palisade.* ![General product overview from the vendor's site, not a specific Gmail settings screen](/images/editorial/gmail-rejected-email-from-my-domain/gmail-rejected-email-from-my-domain-shot-1.png "1600x900") *Source: https://www.fortra.com/sites/default/files/2024-03/screenshot_2024-03-14_at_4.03.44_pm.png* ## How do I configure SPF and DKIM for Gmail? ### 1. Read the complete rejection from the sending service Open the delivery event, SMTP log, or bounce notification for the failed message. Record the SMTP code and preserve the text exactly. Google documents these separate 5.7.26 variants: ```text This email has been blocked because the sender is unauthenticated. Gmail requires all senders to authenticate with either SPF or DKIM. ``` ```text The (E)MAIL FROM domain [_domain-name_] has an SPF record with a hard fail policy (-all) but it fails to pass SPF checks with the ip: [_ip-address_]. ``` ```text Unauthenticated email from domain-name is not accepted due to domain’s DMARC policy. Contact the administrator of _domain-name_ domain if this was legitimate email. ``` The first message points to missing authentication. The second points to a sending IP that does not pass the envelope sender domain's hard-fail SPF policy. The third means the visible From domain's published DMARC policy rejected mail that did not pass aligned SPF or DKIM. ### 2. Identify the domain and service in scope Compare the visible From domain, envelope MAIL FROM domain, DKIM `d=` domain, and the sender that produced the bounce. SPF evaluates the envelope sender path, while DMARC requires alignment between the visible From domain and a passing SPF or DKIM identity. [RFC 9989's DMARC alignment rules](https://datatracker.ietf.org/doc/html/rfc9989) explain why a valid but unrelated SPF or DKIM result may still fail DMARC. If a vendor sends mail on your behalf, use that vendor's current domain-authentication instructions to generate its own records. Do not add a second SPF TXT record at the root domain. SPF mechanisms must be combined into the existing single SPF record after checking each provider's documented include value. ### 3. Publish the generated DNS records Publish only the records generated for the selected sender account and domain. The shapes below are illustrative only. **SPF record type:** `TXT` **SPF host:** `yourdomain.com` **SPF value, illustrative only:** ```text v=spf1 include:sender.example -all ``` **DKIM record type:** `CNAME` or `TXT`, as generated by the sender **DKIM host, illustrative only:** ```text selector1._domainkey.yourdomain.com ``` **DKIM value, illustrative only:** ```text selector1.example-sender.invalid ``` > Do not publish these examples. Copy the exact host and value generated in the sending service for your account and domain. Some DNS interfaces automatically append `yourdomain.com` to the host field. Entering a full domain where the provider expects only the relative host can create `selector1._domainkey.yourdomain.com.yourdomain.com`. Check the final fully qualified DNS owner after saving. Before altering SPF, preserve every existing mechanism required by legitimate senders. Before adding DKIM, check whether the selector already exists. Do not overwrite an active selector unless you are following the sender's documented key-rotation process. ### 4. Verify the sender's domain-authentication status Return to the sending provider and use its documented verification status for the selected domain. A vendor status indicates that the provider can currently find or accept the DNS configuration. It does not prove that a particular production route is signing messages or using the expected return path. For a 550 5.7.27 rejection, Gmail says: “This message was blocked because it didn’t pass SPF authentication. Gmail requires bulk email senders to authenticate their email with SPF.” For 550 5.7.30, Gmail says: “This message was blocked because it didn’t pass DKIM authentication. Gmail requires bulk email senders to authenticate their email with DKIM.” Match the code to the protocol before changing records. ### 5. Send a real message through the same production path Send a new test message through the exact system that generated the bounce. Use a mailbox where you can inspect the raw source. Check the receiver-added `Authentication-Results` field, which [RFC 8601 defines as an authentication assessment with a trust boundary](https://datatracker.ietf.org/doc/html/rfc8601). Look for the SPF and DKIM result, then compare the passing identity with the visible From domain. If the message uses DKIM to satisfy DMARC, confirm that the `d=` domain aligns with the From domain. Keep a redacted copy of the headers with the change record. ## How does this setup affect DMARC? DMARC applies the visible From domain's policy after evaluating aligned SPF or DKIM. A sender can pass SPF for one domain and DKIM for another, yet still fail DMARC if neither passing identifier aligns with the visible From domain. Use Palisade's [DMARC checker](/tools/dmarc) to inspect the published DMARC record after the DNS change. A public record check cannot show whether the actual sender uses the intended return path, whether Gmail accepted a specific message, or whether future mail will pass alignment. If the bounce says your domain's DMARC policy rejected the message, compare the message's aligned SPF and DKIM results before weakening the DMARC policy. The correct repair may be authenticating the missing sender, not changing a policy that protects legitimate mail. ## How do I validate the setup? ### Check public DNS Query the authoritative DNS server and at least one public resolver for the exact SPF, DKIM, and DMARC owners. Confirm that the fully qualified name has no duplicated zone suffix and that the answer matches the selected sender account. ```bash dig +short TXT yourdomain.com dig +short TXT _dmarc.yourdomain.com dig +short CNAME selector1._domainkey.yourdomain.com ``` ### Check the vendor status Review the sender provider's current verification state for the domain. If it reports an error, compare its expected record with the authoritative DNS response. A green vendor indicator is not a delivered-message check. ### Inspect a delivered message Send a fresh message through the same path and inspect its raw headers. Confirm SPF and DKIM results, the relevant authenticated identities, and DMARC alignment. Test each materially different route separately, including marketing, transactional, and mailbox-hosted mail. ### Review DMARC reports After aggregate reports arrive, check whether the sender appears as an authenticated and aligned source. Palisade's DMARC Agent can analyze aggregate-report data, identify sending sources and alignment issues, and create prioritized remediation tickets. It can propose the next policy step when the evidence supports it, while a human reviews the evidence and applies any DNS policy change. ## Troubleshooting ### Gmail reports 5.7.26 but SPF looks published Compare the bounce's specific 5.7.26 text with the envelope sender and sending IP. An SPF record ending in `-all` can correctly reject an IP that your provider did not authorize. Add only the provider's documented authorization to the existing SPF record, then retest the same route. ### Gmail reports 5.7.29 Google documents 550 5.7.29 as: “This message was blocked because it wasn’t sent over a TLS connection. Gmail requires all bulk email senders to use TLS/SSL for SMTP connections.” This is an SMTP transport setting on the actual sender path. A DNS authentication change cannot prove or repair TLS negotiation. ### Gmail reports 5.7.25 Google documents 550 5.7.25 when the sending IP lacks a PTR record or its forward DNS does not reference that IP. The reverse DNS owner is usually the IP provider or sending platform. Ask that owner to validate the PTR and forward-confirmed DNS for the production IP. ### Gmail reports a 5.7.1 or 5.7.28 reputation message Treat this as message or IP evidence, not proof of a permanent domain block. Google says spam rate is calculated daily and that bulk senders with a user-reported spam rate above 0.3% are ineligible for mitigation. It says eligibility returns when spam rates remain below 0.3% for seven consecutive days in its [sender-guidelines FAQ](https://support.google.com/mail/answer/14229414). Reduce unwanted mail, investigate the compromised or poor-performing source, and retest after the sender behavior changes. ### Gmail returns 421 4.7.28 Do not classify this as a rejection. Google documents 421 4.7.28 as: “Gmail has detected an unusual rate of email. To protect our users from spam, email has been temporarily rate limited.” Allow compliant retry behavior and investigate the rate signal named in the response, which can concern an IP, netblock, SPF domain, DKIM domain, URL domain, or repeated `Message-ID:`. ## Check the DMARC record behind the Gmail rejection Inspect the published DMARC record before changing the policy that may have rejected unaligned mail. Run the sending domain through Palisade's DMARC checker, then compare the result with the rejected message's SPF, DKIM, and visible From-domain evidence. [Check the DMARC record](/tools/dmarc) A public DMARC record check cannot prove why Gmail rejected one message, repair an SPF or DKIM configuration, monitor later DNS drift, or control Gmail's private reputation decision. If the same domain has multiple production senders, Palisade is DMARC software that can analyze DMARC aggregate reports and identify sources that still need remediation. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=vendor_setup&utm_content=gmail-rejected-email-from-my-domain) with no credit card required for signup or trial. ## Sources and further reading - [Gmail SMTP errors and codes](https://knowledge.workspace.google.com/admin/support/troubleshooting/gmail-smtp-errors-and-codes) - [Google Email sender guidelines](https://support.google.com/mail/answer/81126) - [Google Email sender guidelines FAQ](https://support.google.com/mail/answer/14229414) - [RFC 9989: Domain-based Message Authentication, Reporting, and Conformance](https://datatracker.ietf.org/doc/html/rfc9989) - [RFC 8601: Authentication-Results header field](https://datatracker.ietf.org/doc/html/rfc8601) - [Gmail sender unauthenticated rejection fix](/email-deliverability/gmail-blocked-sender-is-unauthenticated) ## Frequently asked questions ### Why is Gmail rejecting emails from my domain? Gmail can reject a message because the sending path is unauthenticated, fails a hard-fail SPF policy, fails the sender domain's DMARC policy, lacks TLS or PTR, has message-format problems, or has a reputation issue. Read the complete SMTP response. Google's three 5.7.26 variants identify different causes, so do not treat every 5.7.26 response as the same SPF problem. ### How do I stop Gmail from rejecting emails? Fix the requirement named in the bounce, then retest the identical sending path. Google maps 5.7.26 to authentication or DMARC alignment, 5.7.27 to SPF, 5.7.30 to DKIM, 5.7.29 to TLS, and 5.7.25 to PTR. Reputation-driven 5.7.1 and 5.7.28 responses require sending-behavior and reputation evidence, not only DNS changes. ### Is my domain blocked by Gmail? You cannot look that up, because Google does not publish a domain-level block status or a lookup for one. Gmail's published responses say that a message was blocked or that mail from a sending IP was blocked, which are decisions about that message or that IP. Read the full SMTP response you received and treat it as evidence about one sending path, not a verdict on the whole domain. ### Why is my domain Gmail not receiving emails? Two different problems share that wording, so separate them first. If Gmail is rejecting mail you send, use the SMTP-code diagnosis in this article and fix the requirement the bounce names. If nobody can send mail to your domain, that is an inbound routing problem: check your public MX records with the [DNS lookup tool](/tools/dns-lookup), then read the receiving mail service's routing logs. ### Does a passing SPF record stop Gmail rejections? No, a passing SPF record does not stop Gmail rejections on its own. SPF still fails when the actual sending IP is not authorized, and it can pass without aligning with the visible From domain, which is what DMARC requires. Gmail also rejects messages for DKIM, TLS, PTR, formatting, and reputation reasons that SPF has nothing to do with. --- # Pixm phishing protection Canonical: https://www.palisade.email/learning/pixm-phishing-protection > Pixm phishing protection is browser-layer protection that Pixm says uses AI computer vision to stop credential phishing from email, SMS, LinkedIn, and. Pixm phishing protection is browser-layer phishing protection that Pixm says is designed to protect credentials where they are entered: in the browser. According to [Pixm's product site](https://pixmsecurity.com), it stops phishing attacks in the browser with AI computer vision and is intended to address vectors that include LinkedIn and SMS as well as corporate email. This positions it as one layer in a wider phishing-defense program, not as a replacement for email authentication or email-security controls. ## Quick takeaways - Pixm describes its product as browser-layer protection for credential phishing. - Pixm says it uses AI computer vision to stop phishing attacks in the browser. - Pixm says the product can address phishing vectors such as LinkedIn, SMS, and corporate email. - Browser-layer phishing protection focuses on the webpage or credential-entry moment, not only on the original message. - Pixm says stopped threats and targeted users can be reviewed through its web portal or a SOC integration. - A browser-focused control does not replace email-domain authentication, mailbox filtering, or user reporting processes. ## How Pixm phishing protection works Phishing commonly attempts to move a person from a message, post, or text to a fraudulent page that requests a password, MFA code, or other credential. [Pixm describes its approach](https://pixmsecurity.com) as protecting credentials in the browser and stopping browser phishing with AI computer vision. The available product description supports the intended protection point, but it does not establish Pixm's specific technical architecture. It does not confirm which browsers or operating systems are supported, whether the product uses a browser extension or another endpoint model, or the exact detection and blocking behavior. Those details require current Pixm documentation or a product-specific listing. The distinction matters because the original phishing vector is not always email. A credential theft attempt can begin with an email link, a direct message on LinkedIn, an SMS message, or another route. Pixm specifically names “LinkedIn, SMS and others” among the browser-delivered phishing vectors it aims to cover. For the broader definition and common attack pattern, see [what phishing is](/learning/what-is-phishing). Browser-layer protection belongs within the wider set of controls covered in the [email security guide](/learning). Email authentication can help a receiver assess whether a message legitimately uses a domain, while browser-layer protection addresses a later point in the attack path: the page a user reaches. ![Flow showing a phishing link from email, SMS, or LinkedIn leading to a browser credential page, with browser-layer protection and separate email-domain controls](/images/editorial/pixm-phishing-protection/pixm-phishing-protection-browser-layer-flow.webp "1200x676") *Source: Palisade.* ## When browser-layer phishing protection changes the answer Browser-focused protection is most relevant when the risk includes users reaching credential-harvesting pages from channels beyond the corporate inbox. Pixm's stated positioning covers that situation because it names LinkedIn, SMS, and other vectors in addition to corporate email. Use this decision rule: - If the question is whether a suspicious webpage could capture a user's credentials after they open it, browser-layer phishing protection is the relevant control category. - If the question is whether a sender is authorized to use a visible From domain, inspect email authentication and DMARC instead. - If the question is whether a receiving mailbox accepted, spam-foldered, or rejected a message, the receiving provider's own logs or dashboard are the relevant evidence. - If the question is whether a user received a phishing message through a non-email channel, email controls alone do not cover the entire path. > Do not treat a browser-focused phishing control as proof that every phishing page will be detected or that every future credential theft attempt will be stopped. The supplied Pixm material does not document detection rates, false-positive rates, or coverage percentages. Pixm says organizations can access stopped threats and targeted-user information through its web portal or through a SOC integration. That statement supports a review capability at a high level, but it does not document exact alert fields, policy settings, logging methods, retention, or integration procedures. For a comparison framework that separates controls by the evidence they inspect, see [anti-phishing software for business](/learning/anti-phishing-software). ## A worked phishing-control example Consider an employee who receives a text message that appears to come from a familiar service. The message leads to a page that asks for a work email address and password. ```text Illustrative phishing path SMS message -> user opens a link -> browser loads a credential-request page -> browser-layer phishing protection evaluates the page -> security team reviews any stopped threat or affected-user evidence Separate email-domain controls: -> evaluate mail that uses the organization's visible From domain -> publish and enforce DMARC only after legitimate sources are validated ``` In this example, the text message is outside the corporate email path. A DMARC record for the organization's domain may help defend that domain against unauthorized email use, but it does not inspect the SMS link or determine whether the destination webpage is fraudulent. The same separation applies to email. If an attacker sends a lookalike-domain message that passes through a recipient's mailbox, authentication results alone do not describe every page the recipient might open. Conversely, a browser-level stop does not identify whether the sender used an authorized domain or whether the organization's DMARC policy is correctly published. Pixm says deployment can use a licensed installer, with automatic updates and no agents to manage. Treat that as [Pixm's vendor claim](https://pixmsecurity.com), not as deployment instructions. The available information does not verify device-management compatibility, installation steps, supported platforms, or administrator approval requirements. ## Choose the next check based on your evidence Start with the evidence you actually have. - If you have a suspicious URL or an email that links to one, preserve the message or URL according to your incident process and use the organization's security tooling to investigate it. A public email-domain check cannot determine whether the destination page is malicious. - If you need to assess the email-domain controls that sit alongside browser protection, run the sending domain through Palisade's [Email Security Score checker](/tools/email-security-score). It can help identify published email-security controls. - If the incident involves a message claiming to use your domain, review your DMARC posture and the sending path. The [threats and impersonation hub](/learning/threats) provides the wider context for phishing, impersonation, and related risks. - If you are evaluating a browser-focused product, ask the vendor for current documentation that confirms supported browsers, operating systems, deployment model, alert evidence, SOC integration details, and the process for handling false positives. A public email-security check can inspect DNS-visible controls. It cannot prove the production sending path, determine a browser product's current coverage, reveal a receiver's private decision, or guarantee future inbox placement. ## Assess the email-domain layer beside browser protection Pixm's stated browser focus addresses credential-phishing pages after a user reaches the browser. Check your email domain separately to identify whether published authentication and security controls need attention. [Check your email security score](/tools/email-security-score) An email-domain score cannot test Pixm's browser behavior, prove that a phishing page was blocked, monitor a device fleet, or replace evidence from an affected user's browser and security logs. ## Sources and further reading - [Pixm Security product site](https://pixmsecurity.com) - [Palisade Email Security Score checker](/tools/email-security-score) - [Palisade guide to email security](/learning) - [Palisade guide to phishing](/learning/what-is-phishing) ## Frequently asked questions ### Does Pixm phishing protection only cover email phishing? No, Pixm covers more than email. It says its browser phishing protection is meant to handle vectors including LinkedIn and SMS as well as corporate email. Pixm does not publish a full list of the channels and platforms it supports, so confirm the ones you care about with the vendor. ### Does Pixm phishing protection replace DMARC? No, the two controls do different jobs and one cannot stand in for the other. Pixm describes browser-layer protection against credential phishing. DMARC is an email-authentication policy that lets a domain owner state how receivers should handle messages that fail DMARC. ### Can a browser-focused phishing tool prove an email was legitimate? No, a browser-focused tool cannot settle that, because it only sees the browser stage. To judge whether an email legitimately used a visible From domain, you need message-authentication evidence from the headers and, where it applies, DMARC analysis. ### Can administrators review threats that Pixm stopped? Yes, administrators can review them. Pixm says stopped threats and the users targeted can be reached through its web portal or fed into a SOC. Pixm does not publish which views, fields, or integration methods that involves, so ask the vendor before you plan around it. ### Does Pixm publish its supported browser list on its product homepage? No, Pixm does not list supported browsers on its homepage. The page states the browser-focused positioning but names no browsers, operating systems, or deployment-management platforms. Ask Pixm directly if you need that list before a rollout. --- # Reverse DNS and email spam: what PTR checks really mean Canonical: https://www.palisade.email/learning/reverse-dns-email-spam > Reverse DNS email spam checks use PTR records as one sender signal. Learn what Google requires, what receivers may do, and how to validate it. Reverse DNS can affect how a receiving mail system evaluates your sending IP address, but a missing or mismatched PTR record does not prove that a message will go to spam. Google has required valid forward and reverse DNS for all senders since February 1, 2024. Microsoft says some mail servers may reject mail without a reverse record or flag it as spam. Reverse DNS is one signal, separate from authentication and receiver-specific filtering decisions. ## Quick takeaways - Reverse DNS maps an IP address back to a hostname through a PTR record. - Google requires valid forward and reverse DNS for all senders as of February 1, 2024. - Microsoft says some email servers may flag mail as spam or reject it when the sending IP lacks a PTR record. - RFC 5321 says an EHLO name and IP-address mismatch alone MUST NOT cause SMTP rejection. - Reverse DNS is not an SPF, DKIM, or DMARC authentication record. - A public PTR lookup shows current DNS data, not a receiver's private spam decision or future inbox placement. ## Who is affected? Any operator sending email directly from an IP address is affected. That includes teams operating their own SMTP servers and teams using an email service provider whose infrastructure sends mail on the organization's behalf. The relevant IP is the IP that opens the SMTP connection to the receiving server, not necessarily the IP address of the website or corporate network. Reverse DNS uses the DNS `PTR` record type. [RFC 1035 defines the reverse lookup tree](https://datatracker.ietf.org/doc/html/rfc1035#section-3.5) under `IN-ADDR.ARPA` for IPv4 addresses, while [RFC 1035's PTR record definition](https://datatracker.ietf.org/doc/html/rfc1035#section-3.3.12) describes the record that points from an address to a domain name. For record anatomy and lookup direction, see [what a PTR record is](/learning/email-reverse-dns-check). The sender normally cannot set a PTR record in an ordinary domain DNS zone. The organization that controls the IP address allocation, often a hosting provider, cloud provider, or email platform, must publish it. A PTR record is relevant to sender identity checks, but it is not a complete spam-prevention control. Google's sender guidelines list valid forward and reverse DNS separately from SPF or DKIM, and separately from DMARC requirements for bulk senders. That distinction matters: a plausible PTR name does not authenticate the visible From domain or establish DMARC alignment. ## What are the requirements? ### Google requires valid forward and reverse DNS [Google's email sender guidelines](https://support.google.com/a/answer/81126) require all senders to have valid forward and reverse DNS records. The requirement applies independently of whether the sender is classified as a bulk sender. For a sending IP, the reverse lookup should return a hostname. That hostname should then resolve forward to the same sending IP. This is commonly called forward-confirmed reverse DNS. ```text Illustrative only. Publish the actual PTR value through the organization that controls the sending IP. 198.51.100.24 -> mail1.yourdomain.com mail1.yourdomain.com -> 198.51.100.24 ``` Do not publish a PTR target that belongs to another tenant or copy a provider's example hostname. The IP owner generates or configures the real reverse record. ### A receiver may treat missing reverse DNS as an anti-spam signal Microsoft's [Remote Connectivity Analyzer guidance on missing PTR records](https://learn.microsoft.com/en-us/connectivity-analyzer/ip-address-does-not-have-ptr-record-dns) states: "Some e-mail servers check for a reverse record as a basic anti-spam check procedure. These e-mail servers may reject messages from your domain, or they may flag messages as spam." "May" is the important word. The statement confirms that reverse DNS can affect filtering or acceptance, but it does not establish a universal spam-folder outcome, a score, or a numeric threshold. No published source in this guidance shows that reverse DNS alone is sufficient to cause spam placement. A receiver can combine connection data with message authentication, sending reputation, content, complaint history, and local policy. The practical consequence is that fixing a PTR record can remove one avoidable negative signal, while leaving other delivery problems untouched. For related operational checks, see [email reverse DNS best practices](/learning/email-reverse-dns-best-practices). ### An EHLO mismatch alone cannot justify rejection The SMTP standard limits one common assumption about reverse DNS. [RFC 5321 section 4.1.4](https://datatracker.ietf.org/doc/html/rfc5321#section-4.1.4) says that the EHLO or HELO argument contains the client's domain name, but a mismatch between that name and the connecting IP address "MUST NOT" be the sole basis for refusing the connection. ```text EHLO mail1.yourdomain.com ``` This does not mean receivers must ignore reverse DNS. It means an EHLO-to-IP mismatch by itself is not enough for rejection under the SMTP specification. A receiver can use other policy evidence, and an operator should investigate a specific SMTP rejection from its exact message and connection evidence. [Reverse DNS does not match SMTP banner](/learning/reverse-dns-does-not-match-smtp-banner) covers that narrower failure case. ### Reverse DNS is not email authentication [RFC 8601 section 3](https://datatracker.ietf.org/doc/html/rfc8601#section-3) describes the `iprev` authentication-results method and notes that referenced guidance recommends applications avoid using this test as a means of authentication or security. A PTR record identifies a DNS name associated with an IP address. It does not prove authority to use the visible From domain. A receiver can record an IP reverse result in the `Authentication-Results` header: ```text Authentication-Results: mx.example; iprev=pass policy.iprev=mail1.yourdomain.com ``` The example is illustrative only. [RFC 8601 section 2.7.3](https://datatracker.ietf.org/doc/html/rfc8601#section-2.7.3) registers `pass`, `fail`, `temperror`, and `permerror` values for `iprev`. SPF, DKIM, and DMARC address different questions. SPF authorizes sending IP addresses for an envelope domain, DKIM verifies a signed message, and DMARC evaluates alignment against the visible From domain. Google's sender guidance identifies SPF or DKIM for all senders and DMARC for bulk senders. Reverse DNS does not replace any of them. ![Decision flow showing how a receiving server can use a PTR record as one signal without treating it as standalone authentication](/images/editorial/reverse-dns-email-spam/reverse-dns-email-spam-decision-flow.webp "1200x738") *Source: Palisade.* ## When does the requirement take effect? Google's valid forward and reverse DNS requirement took effect on February 1, 2024, according to its [email sender guidelines](https://support.google.com/a/answer/81126). The requirement is a Google sender policy, not a new DNS protocol. RFC 1035 defines DNS and PTR records. RFC 5321 is a Standards Track SMTP specification published in October 2008, and its EHLO mismatch rule has no receiver-enforcement date. RFC 8601, published in May 2019, defines the `Authentication-Results` header field and the `iprev` result method. Neither RFC makes a missing PTR record a universal spam trigger. Microsoft's published guidance does not name an operative date or a uniform enforcement threshold. It says receivers may flag or reject messages, so treat that statement as receiver-policy guidance rather than a guarantee about a particular mailbox provider. ## How do I implement the requirement? ### 1. Identify the actual outbound SMTP IP Find the public IP address that establishes the SMTP connection for the mail stream in question. For a third-party email platform, use the platform's delivered-message headers or support documentation instead of assuming that the visible From domain's web-server IP sends mail. If several IPs send mail, check each one. A valid PTR record on one marketing IP does not validate an unrelated transactional or corporate mail path. ### 2. Request or configure the PTR record with the IP owner Set the PTR target through the provider that owns the IP address range. Use a hostname under a domain you control when the provider supports that arrangement, then ensure the hostname resolves forward to the same IP. > Do not change a production PTR record until you know which services share the IP address. A careless reverse-DNS change can affect mail systems beyond the stream you are investigating. ### 3. Confirm the forward mapping Look up the PTR name, then query its A or AAAA record to confirm it leads back to the sending IP. The [DNS lookup tool](/tools/dns-lookup) can inspect the forward record after you have the hostname. A matching PTR and A or AAAA record satisfies the DNS portion of the check. It does not prove that the mail application sends from that IP, signs messages correctly, or meets a receiver's filtering policy. ### 4. Inspect a delivered message Send a message through the exact production path and inspect its raw headers. Look for an `Authentication-Results` field added by the receiving system. If it includes `iprev`, record its result and compare it with the current PTR lookup. Also inspect SPF, DKIM, and DMARC results. Reverse DNS can be sound while authentication fails, and authentication can pass while a receiver still uses other spam signals. ## How do I validate compliance? Start with a public check of the sending IP. Palisade's [IP reputation checker](/tools/ip-reputation) reports the PTR name returned for an IP and checks blocklist status. It can time out after 3,500 milliseconds and return no PTR result, and it does not perform forward confirmation for you. Use the result as a starting point, then query the reported hostname's A or AAAA record. Confirm the forward record maps to the same outbound IP. Check DNS through the authoritative provider and at least one public resolver if a recent change has not appeared consistently. Next, validate the vendor layer. If an email provider owns the sending infrastructure, confirm its current authentication or sender-verification status through that provider. A provider indicator is useful evidence, but it is not proof of a delivered message path. Then validate the message layer with a real delivered message from the production sender. Inspect `Authentication-Results`, SMTP connection information where available, and the exact IP used. A public PTR lookup cannot reveal a receiver's private spam score, inbox decision, or later infrastructure change. Finally, use DMARC aggregate reports after enough mail has flowed to identify authenticated sending sources and alignment failures across the domain. Reverse DNS checks do not replace DMARC monitoring. For broader DNS and SMTP context, visit the [infrastructure learning hub](/learning/infrastructure). ## Check the PTR record behind the sending IP Check the outbound IP with the [IP reputation checker](/tools/ip-reputation), then compare the returned PTR name with its forward DNS record. This follows from the evidence above because a receiver evaluates the connecting IP, not an assumed hostname. A public lookup cannot prove why a particular receiver placed a message in spam, repair a missing record, monitor later DNS changes, or guarantee inbox placement. ## Sources and further reading - [RFC 1035: Domain names, implementation and specification](https://datatracker.ietf.org/doc/html/rfc1035) - [RFC 5321: Simple Mail Transfer Protocol](https://datatracker.ietf.org/doc/html/rfc5321) - [RFC 8601: Authentication-Results header field](https://datatracker.ietf.org/doc/html/rfc8601) - [Google email sender guidelines](https://support.google.com/a/answer/81126) - [Microsoft guidance for an IP address without a PTR record](https://learn.microsoft.com/en-us/connectivity-analyzer/ip-address-does-not-have-ptr-record-dns) ## Frequently asked questions ### What is reverse DNS in email? Reverse DNS maps an email server's IP address to a hostname through a PTR record. [RFC 1035 defines the reverse DNS tree](https://datatracker.ietf.org/doc/html/rfc1035#section-3.5); see [email reverse DNS checks](/learning/email-reverse-dns-check) for the lookup process. ### Does missing reverse DNS send my email to spam? Missing reverse DNS does not send mail to spam on its own, but it does raise the risk. Microsoft says some email servers may flag messages as spam or reject them when the sending IP has no PTR record, and Google requires valid forward and reverse DNS from all senders. Neither says missing reverse DNS is by itself the reason a message lands in spam. ### Why would someone use a reverse email lookup? People use a reverse email lookup to find out what information is associated with an email address, usually to work out who an unfamiliar sender is. That is a different job from reverse DNS, which maps an IP address to a hostname and tells you nothing about a mailbox. ### Which DNS records are commonly used to stop email spoofing and spam? SPF, DKIM, and DMARC are the DNS-based email authentication controls commonly used for spoofing resistance. Reverse DNS is a connection identity signal, not an authentication record, and [RFC 8601 advises against treating `iprev` as authentication or security](https://datatracker.ietf.org/doc/html/rfc8601#section-3). ### How would I see whether a receiver failed my reverse DNS? Inspect the delivered message's `Authentication-Results` header for an `iprev` result such as `pass`, `fail`, `temperror`, or `permerror`. A missing `iprev` result does not prove the receiver ignored reverse DNS, because receivers decide which checks to record. --- # Valimail BIMI checker: what you can verify Canonical: https://www.palisade.email/learning/valimail-bimi-checker > Valimail BIMI checker guidance: confirm the available product scope, check public BIMI DNS evidence, and separate it from message and mailbox results. A Valimail BIMI checker cannot be documented from Valimail's public product information alone. Valimail's homepage describes Monitor and Enforce in terms of DMARC visibility and enforcement, including "Get unlimited domain visibility, for free," but it does not identify a public BIMI checker or publish BIMI-specific result states. Confirm the current product scope first, then use a public BIMI lookup only for the DNS evidence it can actually inspect. ## Quick takeaways - Valimail's public homepage describes Monitor and Enforce around DMARC visibility and enforcement, not a documented public BIMI checker. - A public BIMI lookup can inspect published DNS evidence, but it cannot prove that a production sender used the intended path. - A DNS result cannot prove that a mailbox provider displayed a brand indicator for a delivered message. - Do not infer BIMI readiness from DMARC product visibility alone. - A real delivered message, the relevant provider status, and later DMARC report data answer different questions from a public record check. ## What this tool checks A reader looking for a Valimail BIMI checker should first distinguish a vendor's DMARC products from a BIMI-specific public lookup. [Valimail's public homepage](https://valimail.com) positions Monitor and Enforce around domain visibility and DMARC enforcement. It does not provide enough published detail to establish that a public BIMI checker exists, what input it accepts, or which statuses it returns. If the immediate task is to inspect public BIMI DNS evidence, use the [Palisade BIMI checker](/tools/bimi). Treat the result as a point-in-time public lookup. It cannot see your sending-service configuration, private keys or certificates, a recipient mailbox's private decision, a delivered message's headers, or future mailbox display behavior. That boundary matters when comparing tools and vendors. A public record can be present while the outbound application is not using the intended authenticated sending path. A delivered message can authenticate differently from what a DNS-only check suggests. A mailbox provider can also make display decisions that a public lookup cannot observe. For background before testing, see [what a VMC is](/learning/what-is-a-vmc). Keep the VMC question separate from the question of whether a public BIMI-related DNS record is visible. ![Decision map for separating a Valimail product-scope question from a public BIMI DNS check](/images/editorial/valimail-bimi-checker/valimail-bimi-checker-decision-map.webp "1200x829") *Source: Palisade.* ## How to run the check ### 1. Define the evidence you have Start with the domain whose visible From address appears on the message or campaign you are investigating. Record whether you are trying to answer a DNS question, a sender-configuration question, a delivered-message question, or a mailbox-display question. Do not use a domain-level visibility product as evidence that a BIMI configuration is present. The product category and the protocol evidence are different. ### 2. Confirm the Valimail product scope Review [Valimail's current public product information](https://valimail.com) before relying on a Valimail-branded BIMI-checking workflow. The available public material describes Monitor and Enforce around DMARC, so it does not establish a BIMI checker URL, input form, result label, or repair threshold. If your organization has a Valimail account, use its current product documentation or authenticated interface to determine whether a BIMI feature is available to your account. Do not infer a current interface label from an old image, a search result, or a third-party description. ### 3. Inspect the public DNS evidence Submit the exact domain to the [Palisade BIMI checker](/tools/bimi) when you need a public DNS check. Save the domain, timestamp, and returned result so the same lookup can be repeated after a DNS change. You can also preserve an independent public DNS observation with a command such as this: ```bash dig +short TXT default._bimi.yourdomain.com ``` This command queries one example BIMI DNS owner. `yourdomain.com` is illustrative only. Do not publish or reuse another organization's record values, logo locations, certificate locations, or account-generated DNS targets. ### 4. Keep the tool result separate from message evidence A public response is only the DNS layer. After any DNS result, send a new message through the same production application, sender identity, and recipient path that matter to the investigation. Inspect the raw message and the provider-side result available for that test path. Then allow time for DMARC aggregate-report data to accumulate. Aggregate reports can help identify sending sources and authentication or alignment issues, but they do not replace the public DNS observation or a delivered-message check. > Do not remove or replace a published record because a single DNS lookup looks unexpected. Confirm the authoritative DNS answer, the intended vendor configuration, and the affected production sending path before changing mail-authentication settings. ## How to interpret the results The public material available for Valimail does not document BIMI-checker labels or result states. Do not assign Valimail-specific meanings such as pass, fail, ready, or verified to any result without current vendor documentation. ### A Valimail page describes DMARC visibility or enforcement This result answers a product-scope question, not a BIMI validation question. Valimail states that its Monitor offering provides domain visibility and that its products address DMARC visibility and enforcement. That can be relevant to DMARC operations, but it does not prove the presence, validity, or use of BIMI-related DNS configuration. Use [Valimail DMARC checker guidance](/learning/valimail-dmarc-checker) when the evidence concerns a DMARC record or DMARC status. Keep that workflow separate from the BIMI task. ### A public BIMI lookup returns DNS evidence A returned DNS answer shows only what the queried public resolver observed for that owner at that time. Compare it with the authoritative DNS answer and the exact record generated for your own domain by the relevant provider or certificate workflow. This result does not establish that the sending application is configured for the expected domain, that a recipient received a message through that path, or that a mailbox displayed a brand indicator. ### A public BIMI lookup does not return the expected DNS evidence First confirm the queried domain and owner name. Then compare the answer from a public resolver with the authoritative DNS zone and the configuration generated for your own domain. A missing public answer can result from an incorrect owner, an unpublished record, a DNS propagation issue, or a configuration mismatch. The available Valimail material does not document how a Valimail BIMI checker would classify any of those cases. Move to the domain's DNS provider and the applicable sender or certificate workflow before deciding which condition applies. ### A delivered message does not show the expected outcome Do not use the public DNS result as a diagnosis of one delivered message. Inspect the raw source for the exact production path, then check the relevant mailbox-provider or sending-service status. The public lookup cannot reveal why that recipient handled one message in a particular way. ## How to act on the result Work through the evidence in order: - Confirm whether the task is about Valimail's documented DMARC products or public BIMI DNS evidence. - For a public DNS issue, compare the lookup result with the authoritative DNS zone and the record values generated for your own domain. - For a sender-path issue, inspect a new message sent through the exact production application and identity under investigation. - For a mailbox-display issue, use the recipient provider's available evidence. A public checker cannot expose a receiver's private policy decision. - For a recurring multi-domain DMARC problem, keep DNS, sender, message, and aggregate-report findings separate until the source of the issue is clear. Teams evaluating related vendors can start at the [Palisade comparison hub](/compare). Product scope should be confirmed from each vendor's current documentation rather than inferred from a similarly named checker. ## How to retest After the authoritative DNS answer changes, repeat the same public BIMI lookup with the same domain. Record the new timestamp and compare the returned DNS evidence with the earlier result. Then send a new message through the same production path. Confirm the relevant sender and recipient evidence separately. After aggregate reports have accumulated, review whether the source and authentication or alignment evidence agree with the DNS and message observations. A changed public DNS result does not prove that every sender is configured correctly, that all recipients will display a brand indicator, or that future messages will authenticate. ## Check the public BIMI DNS evidence after confirming the scope If you need to inspect the public BIMI-related DNS evidence for a domain, run it through Palisade's BIMI checker after confirming that the question is not actually about Valimail's DMARC visibility products. [Check the BIMI record](/tools/bimi) The check can inspect public DNS at one point in time. It does not prove a production sending path, repair DNS, monitor future changes, or guarantee mailbox display or delivery. For an ongoing DMARC workflow, Palisade is DMARC software that analyzes aggregate-report data, identifies sending sources and authentication or alignment issues, and proposes prioritized remediation work for human review. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=tools_vendors_comparisons&utm_content=valimail-bimi-checker) ## Sources and further reading - [Valimail homepage and product overview](https://valimail.com) - [Palisade BIMI checker](/tools/bimi) - [What is a VMC? Verified Mark Certificates for BIMI](/learning/what-is-a-vmc) - [Valimail DMARC checker: what you can verify](/learning/valimail-dmarc-checker) ## Frequently asked questions ### Does Valimail provide a public BIMI checker? The current Valimail public homepage describes DMARC visibility and enforcement products. It does not identify a public BIMI checker, its URL, supported input, result states, or repair guidance. Confirm current availability in Valimail's documentation or authenticated product interface. ### Can a public BIMI lookup prove that a mailbox will display a brand indicator? No. A public lookup can inspect DNS evidence visible to the resolver. It cannot see a mailbox provider's private decision, the delivered-message path, or the future handling of a message. ### Does a public BIMI DNS result prove that a sender is configured correctly? No. The DNS result does not show whether a production application used the intended sender identity or configuration. Send a new message through the exact production path and inspect the resulting message and provider evidence. ### Should a DMARC visibility product be treated as BIMI validation? No. DMARC visibility and enforcement are different from a documented BIMI-checking workflow. Confirm the exact product feature and then collect the DNS, sender, message, and aggregate-report evidence relevant to the question. ### What should I retest after changing BIMI-related DNS? Repeat the same public lookup after the authoritative DNS answer changes. Then send a new message through the same production path and inspect the recipient-side evidence separately. A changed DNS result alone does not prove mailbox display or delivery. --- # How do I improve email deliverability and in what order should I fix things? Canonical: https://www.palisade.email/learning/ways-to-improve-email-deliverability > How to improve email deliverability in 12 ordered steps: authenticate with SPF, DKIM and DMARC, repair sender reputation, then earn engagement. Improving email deliverability means fixing three layers in order: authentication first, then sender reputation, then the mail itself. The order matters because the layers gate each other. A perfect campaign from an unauthenticated domain still fails, and a perfectly authenticated domain with a spam-complaint problem still lands in junk. The 12 steps below follow that order, and each one names the mechanism it changes. For the wider topic, including the bulk sender rules and provider-specific failures, see the [email deliverability hub](/email-deliverability). ## Quick takeaways - Authentication comes first: publish [SPF](/learning/what-is-spf), sign with [DKIM](/learning/what-is-dkim), and set a [DMARC](/learning/what-is-dmarc) policy before touching content or send times. - Gmail and Yahoo have required authentication, a low spam rate, and one-click unsubscribe from senders of roughly 5,000 messages a day since February 2024, and Outlook.com added its own authentication requirement in May 2025. - Keep the spam complaint rate reported in Postmaster Tools below 0.10%. Mitigation starts at 0.3%, so 0.29% is not a safe operating level. - Reputation recovers slowly. Providers want to see weeks of clean sending before they restore full inbox placement, which is why prevention beats repair. - Deliverability is an outcome receivers control. You cannot switch it on, but you can remove every reason they have to filter you. ## Fix authentication first Authentication failures are the only deliverability problem that can hard-reject mail on its own, and they are also the fastest to fix: each one is a DNS record you control. ### Step 1: Publish an SPF record SPF lists the servers allowed to send mail for your domain. Publish one TXT record at the domain root naming every legitimate source: your mail platform, your CRM, your invoicing tool, your help desk. Sources you forget will fail authentication and, once you enforce DMARC, stop arriving. Check what your domain publishes today with the [SPF checker](/tools/spf), and keep the record under the 10-DNS-lookup limit, because a record over the limit returns a permanent error instead of a pass. ### Step 2: Sign with DKIM everywhere you send DKIM attaches a cryptographic signature that survives the trip from server to inbox. Turn it on at every sending platform, not only your primary mail provider. A DKIM signature travels with the message, so it keeps authenticating through forwarding when SPF breaks, which makes it the more durable of the two checks. Verify a selector with the [DKIM checker](/tools/dkim). ### Step 3: Publish a DMARC record with a reporting address DMARC ties SPF and DKIM to the domain a recipient actually sees, and it is the requirement the bulk sender rules name explicitly. Start with a monitoring [policy](/learning/glossary/dmarc-p) and a reporting address: `v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com`. The reports name every source sending as your domain, legitimate or not, and they are the evidence for every later step. A record with no `rua` address collects nothing, which leaves you enforcing blind. The [DMARC setup guide](/dmarc-setup) walks through publishing it at your DNS provider. ### Step 4: Align the passing domain, then enforce DMARC only passes when the domain that SPF or DKIM authenticated matches the visible From domain. A vendor passing SPF on its own domain does you no good, so fix alignment sender by sender using the aggregate reports from step 3. When a full sending cycle shows every legitimate source passing, tighten the policy to `p=quarantine`, then `p=reject`. Enforcement is what stops spoofing, and consistent authentication is also what the receivers grading your reputation want to see. ## Repair and protect your reputation Reputation is the receiver's memory of your sending history. It decides whether authenticated mail reaches the inbox or the spam folder, and it moves slower than any DNS record. ### Step 5: Keep the spam complaint rate under 0.10% Google's sender guidelines require keeping the spam rate reported in Postmaster Tools below 0.3%, and recommend staying below 0.10%. Treat 0.10% as the operating ceiling, not the target, because mitigation at 0.3% means mail is already being filtered. The two levers that move complaint rate are consent and relevance: send to people who asked for the mail, about the thing they asked for. ### Step 6: Remove hard bounces and sunset the unengaged A hard bounce means the address does not exist. Sending to it again tells the receiver you do not manage your list, and enough of them reads as address harvesting. Remove hard bounces immediately and stop mailing addresses that have not opened or clicked in months. A smaller list that engages outperforms a bigger one that ignores you, because engagement is itself a placement signal. ### Step 7: Warm up new domains and IPs A sender with no history has no reputation to draw on, and receivers treat unknown volume as suspicious by default. Start small, increase gradually over weeks, and keep the daily pattern consistent rather than spiking. This applies to a new dedicated IP, a new domain, and a new subdomain moving to its own reputation. ### Step 8: Check your sending IP against the blocklists A blocklist entry explains sudden 5xx rejections that no authentication change will fix. Run your sending IP through the [blocklist checker](/tools/blocklist-checker), and if it is listed, follow the operator's own delisting process. Then find the cause, because a delisted IP that keeps the same sending behavior gets relisted. ## Make the mail worth delivering With authentication passing and reputation stable, the remaining filters judge the mail itself and how recipients react to it. ### Step 9: Give marketing mail one-click unsubscribe Bulk senders must include RFC 8058 one-click unsubscribe headers on marketing mail and honor the request within two days. That is a Gmail and Yahoo requirement, not a courtesy. It also protects your complaint rate: a recipient who cannot find the unsubscribe link uses the spam button instead, and the spam button costs far more. ### Step 10: Send only to people who opted in Purchased lists, scraped addresses, and pre-checked consent boxes all convert into complaints and spamtrap hits. Collect addresses yourself, confirm the subscriber wants the mail, and record when and how they opted in. Consent is the root cause behind most complaint-rate problems, which makes it the cheapest one to fix early. ### Step 11: Keep volume and cadence consistent Receivers model your normal sending pattern. A domain that sends 2,000 messages a day and suddenly sends 80,000 looks compromised, and the response is deferral or filtering while the receiver decides. Plan launches and seasonal peaks as ramps rather than cliffs, and keep transactional and marketing mail on separate streams so one cannot damage the other. ### Step 12: Monitor DMARC reports and spam rates continuously Deliverability work does not stay fixed on its own. New tools get connected, keys expire, and a forgotten integration starts failing quietly. Aggregate DMARC reports show every source sending as your domain, so a broken sender appears in a report before it appears as lost mail. Pair them with Postmaster Tools for the complaint-rate side, and review both on a schedule. ## Match the fix to the evidence you have The steps above are ordered by mechanism, but the fastest route through them depends on the evidence in front of you. ![Decision rule showing that a specific sending-path signal can direct investigation, while a generic email rule cannot prove inbox placement](/images/editorial/ways-to-improve-email-deliverability/ways-to-improve-email-deliverability-evidence-rule.webp "1200x676") *Source: Palisade.* - A bounce message with an SMTP code names its own fix. Look the code up in the [SMTP error code index](/learning/smtp-error-codes) and start there. - A domain and nothing else supports a public check first. The [Email Security Score](/tools/email-security-score) shows every authentication gap at once. - DMARC aggregate reports point at the exact sending service that fails, which turns "improve deliverability" into a named list of senders to fix. - A generic rule with no source, from any vendor, is not evidence about your domain. Test it against your own reports before acting on it. One favorable check proves the state of public DNS at that moment. It does not prove a receiver's private placement decision, so treat any single result as an input rather than an outcome. ## Common issues when improving deliverability ### Authentication passes but mail still lands in spam This is a reputation or engagement problem wearing an authentication costume. SPF, DKIM, and DMARC establish who sent the mail; they do not override a complaint spike, a cold IP, or recipients who never open the mail. Check the spam rate in Postmaster Tools first, then engagement by segment. ### Deliverability dropped suddenly after months of stability Sudden drops usually have a single trigger: a blocklist entry, a complaint spike from one campaign, a volume spike, or a new sending tool that fails alignment. Check the [blocklists](/tools/blocklist-checker), the most recent campaign's complaint numbers, and the newest source in your DMARC reports, in that order. ### A new domain sends everything to spam No history means no trust. Warm the domain gradually, authenticate it fully before the first campaign, and send the first weeks of volume to your most engaged recipients so the early signals are positive. A subdomain builds its own sending reputation, so warm it as its own sender. ### Forwarded mail keeps failing Forwarding rewrites the sending path, which breaks SPF. A valid DKIM signature survives forwarding, so DMARC still passes on the DKIM side for correctly signed mail. If forwarded mail fails both, the fix is DKIM signing at the original platform, not an SPF change. ## How do you know it worked? Measure before and after with the same instruments: the spam rate in Postmaster Tools, the bounce rate at your sending platform, and your DMARC aggregate reports. A [deliverability test](/tools/email-deliverability-test) shows what a receiving server records about one real message, which is useful for confirming a specific fix landed. Placement changes take longer than DNS changes: expect authentication fixes to show up within days and reputation recovery to take weeks. For an ongoing DMARC program rather than a one-off cleanup, Palisade analyzes your aggregate reports, identifies the sending sources behind every authentication and alignment failure, and creates prioritized remediation tickets. It proposes each policy step when the evidence supports it, and a human reviews and applies every change. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=deliverability&utm_content=ways-to-improve-email-deliverability) Palisade does not control a receiver's private placement decision or guarantee delivery, and it does not change a DMARC policy on its own. ## Sources and further reading - [Google: Email sender guidelines](https://support.google.com/a/answer/81126) (spam-rate thresholds and the 5,000-message requirements; checked 2026-08-27) - [Yahoo Sender Best Practices](https://senders.yahooinc.com/best-practices/) (checked 2026-08-27) - [RFC 8058: one-click unsubscribe](https://www.rfc-editor.org/rfc/rfc8058) (checked 2026-08-27) - [Microsoft: fix NDR 550 5.7.515 in Outlook.com](https://support.microsoft.com/en-us/outlook/fix-ndr-error-550-5-7-515-in-outlook-com) (checked 2026-08-27) ## Frequently asked questions ### What improves email deliverability fastest? Authentication improves email deliverability fastest, because it is DNS you control and it removes hard failures the same day. Publishing SPF, enabling DKIM, and adding a DMARC record with a reporting address takes an afternoon. Reputation and engagement improvements follow, but they compound over weeks rather than days. ### What is a good spam complaint rate? A good spam complaint rate is below 0.10% in Google Postmaster Tools. Google's guidelines require staying under 0.3% and recommend 0.10%, and filtering ramps up between the two, so the recommended number is the one to operate by. ### What is the 30/30/50 rule for cold emails? No mailbox provider or standards body defines a 30/30/50 rule. It circulates as informal cold-email advice with varying meanings, so do not treat it as a deliverability control. The measurable levers remain authentication, complaint rate, list quality, and consistent volume. ### What does the 3-21-0 email rule mean? There is no primary source defining a 3-21-0 rule. Named formulas without a documented definition cannot explain how a receiver handled your mail. If a tactic matters, its effect will be visible in your own bounce, complaint, and DMARC report data. ### Which strategy will improve email deliverability the most? The strategy that will improve email deliverability the most is the one the evidence in front of you supports. Hard rejections with SMTP codes point at authentication, so start at steps 1 to 4. Spam-folder placement with clean authentication points at reputation: complaints, list quality, and volume patterns, steps 5 to 8. If you have no evidence yet, run a deliverability test and read your DMARC reports before changing anything, because a strategy picked without evidence usually changes the wrong layer. ### Do the bulk sender requirements apply to small senders? The strict thresholds start at roughly 5,000 messages a day to one provider's users, and Yahoo applies the same rules without publishing a number. The requirements themselves, authentication, low complaints, easy unsubscribe, are best practice at any volume, and small senders that follow them get steadier placement too. ### How long does reputation recovery take? Reputation recovery takes weeks, not days. Receivers want to see a sustained low complaint rate and consistent volume before restoring full inbox placement. DNS-level fixes propagate in hours, so the gap between "fixed" and "recovered" is normal rather than a sign the fix failed. ## Related reading - [Email deliverability: the full hub](/email-deliverability) - [How to set up DMARC](/dmarc-setup) - [What is DMARC?](/learning/what-is-dmarc) - [Gmail bulk sender guidelines](/learning/gmail-bulk-sender-guidelines) --- # 550 message rejected due to senders DMARC policy Canonical: https://www.palisade.email/learning/550-message-rejected-due-to-senders-dmarc-policy > 550 message rejected due to senders DMARC policy requires the failed message, recipient response, and DNS evidence before a safe repair for your domain. `550 message rejected due to senders dmarc policy` is a receiver rejection that needs message and DNS evidence before you change anything. The wording alone does not identify the receiving provider, the exact DMARC evaluation, or whether SPF, DKIM, alignment, forwarding, or a local receiver rule caused the rejection. Preserve the original delivery-status notification and failed-message headers, then compare the RFC 5322.From domain with the authenticated domains. ## Quick takeaways - The exact `550` text alone does not prove which DMARC condition failed. - Preserve the complete recipient response, enhanced status code, and original message headers before changing DNS. - Compare the visible From domain with the SPF-authenticated domain and DKIM `d=` domain. - Do not relax a DMARC `p=` policy as a substitute for finding the failed sending path. - Retest through the same application, sender, route, and recipient provider after an approved repair. - A public DMARC lookup shows the published record, not the receiver's private decision for one message. ## What does the failure mean? The observable symptom is this rejection text: ```text 550 message rejected due to senders dmarc policy ``` This wording indicates that the receiving system associated the rejection with the sender's DMARC policy. It does not establish the source of the text, its exact original punctuation, or the rule the receiver applied. In particular, it does not prove that a published `_dmarc` record is malformed, that the sender used `p=reject`, or that a specific authentication mechanism failed. Treat the original non-delivery report or SMTP transcript as the strongest evidence. Preserve the complete response, recipient domain, timestamp, enhanced status code if present, and the full raw source of the rejected message. A generic 550 response can have several causes, as explained in [what 550 errors mean](/learning/smtp-error-codes). This article addresses only the DMARC-related wording shown above. The first diagnostic question is narrow: did the rejected message authenticate and align for the visible From domain? Do not infer the answer from a mail client screenshot or a public DNS result. ![Decision flow for preserving the 550 DMARC rejection, comparing authenticated domains with the visible From domain, approving a narrow repair, and retesting the same path](/images/editorial/550-message-rejected-due-to-senders-dmarc-policy/550-message-rejected-due-to-senders-dmarc-policy-diagnostic-flow.webp "1200x856") *Source: Palisade.* ## What usually causes it? ### Missing evidence for the actual authentication result The most likely immediate problem is that the team has the bounce text but not the receiver-added authentication evidence. The available evidence does not document which provider emits this exact string or map it to one failure condition. Without the raw message, an operator cannot distinguish an SPF issue, a DKIM issue, an alignment issue, forwarding, or a receiver-specific decision. This is an evidence gap, not a reason to edit the DMARC record. Gather the received message source and the original delivery-status notification first. ### SPF or DKIM does not support the sending path Palisade states that it identifies sending sources and pinpoints SPF, DKIM, and DMARC issues behind deliverability problems on its [DMARC software page](/). That supports investigating these mechanisms, but it does not prove which one caused this rejection. Compare the visible From domain to the domains recorded in the receiver's trusted authentication results. If the receiver reports a failed SPF or DKIM result, record the entire relevant line and the domain values before changing sender configuration. ### The authenticated domain does not match the visible From domain A message can have authentication results without showing that the relevant authenticated domain matches the RFC 5322.From domain. This is an inference to test from the headers, not documented behavior for the unnamed receiver behind this exact error. Look for the visible From address, the SPF-authenticated domain, and the DKIM signing domain. Keep the findings in one evidence record instead of relying on a provider dashboard alone. ![Evidence checklist for the failed message, including the recipient response, enhanced status code, visible From domain, SPF domain, DKIM domain, route, and timestamp](/images/editorial/550-message-rejected-due-to-senders-dmarc-policy/550-message-rejected-due-to-senders-dmarc-policy-evidence-checklist.webp "1200x696") *Source: Palisade.* ### A legitimate sender was not accounted for before enforcement A staged enforcement process gives operators time to identify legitimate sending sources before moving to stricter handling. Palisade describes the sequence as [“monitor, then quarantine, then reject”](/). The available PowerDMARC page also describes monitoring before moving to `p=quarantine/reject` on its [DMARC implementation guidance](https://powerdmarc.com). That guidance does not establish the current record syntax or cause of this rejection. It does support checking whether the affected application, ESP, gateway, or forwarding route was included in the sender inventory before enforcement. ### The receiver applied a rule that the available evidence does not disclose The response may reflect receiver-specific policy, forwarding behavior, or an implementation detail. The available evidence does not document the receiver's evaluation rules, alignment mode, or handling of this exact string. Do not label an inference as a provider rule. If the message and DNS evidence show authentication and alignment for the production path, collect the provider's own delivery evidence before changing working sender settings. ## How do I diagnose the failure? ### 1. Preserve the failed delivery evidence Save the original delivery-status notification or SMTP transcript without editing the response text. Record the recipient domain, sending application, sending time, Message-ID, and enhanced status code if available. Obtain the raw source of the original failed message. A forwarded copy, a resend, or a message viewed in a mail client may not preserve the same path or headers. ### 2. Record the domains from the failed message From the exact failed message, record these values in a redacted incident note: ```text Visible From domain: yourdomain.com SPF authenticated domain: example-mailfrom.yourdomain.com DKIM signing domain: mail.yourdomain.com Recipient response: 550 message rejected due to senders dmarc policy ``` These are illustrative labels only. Do not publish customer addresses, selectors, message identifiers, full headers, private keys, tokens, or recipient data. The visible From domain is the domain to compare with the authenticated domains. If the receiver's headers do not provide the required SPF or DKIM domains, do not guess from DNS records. ### 3. Inspect the published DMARC record Use the [DMARC checker](/tools/dmarc) to inspect the currently published record for the visible From domain. Capture the result with the incident record and compare it with the message evidence. A public record check cannot prove why this individual receiver rejected a message, prove the production sender used the intended authentication path, or reveal a receiver's private DMARC decision. ### 4. Identify the exact sending route Map the application and every outbound system that handles the affected mail: application, ESP or relay, signing service, gateway, and recipient. Confirm whether the failed message used the same route as a known good message. The [DMARC learning hub](/learning/dmarc) provides the wider context for policy and alignment. For this incident, keep the scope limited to the sender and route shown in the failed message. ### 5. Separate a finding from an inference A finding is a value visible in the raw message or DNS answer. For example, a DKIM `d=` value in a header is a finding. A conclusion that a particular receiver rejected mail because of that value is an inference unless the provider documents it or its message evidence says so. This distinction prevents a risky DNS change based on a generic bounce string. ## How do I fix it? ### Repair the confirmed sender configuration If the raw message identifies a failed or non-aligning SPF or DKIM path, repair the configuration for that specific sending application or relay. Keep the change limited to the affected source, and obtain human approval before changing DNS or sender settings. The repair changes authentication or alignment for that sender. It does not change a receiver's private reputation or guarantee later delivery. ### Add the confirmed legitimate sender to the operational inventory If the affected source is legitimate but was omitted during rollout, document its owner, route, visible From domain, SPF domain, DKIM domain, and validation result. Then apply the narrow sender-side configuration change supported by the message evidence. Palisade's [DMARC enforcement article](/learning/why-do-corporations-struggle-to-move-from-dmarc-awareness-to-enforcement) explains why sender visibility matters before stricter enforcement. Do not treat a sender inventory as proof that every future message will authenticate. ### Escalate an unpublished receiver decision with evidence If the raw message shows the expected authentication and alignment outcome but the rejection persists, provide the recipient provider with the complete response, redacted headers, timestamp, and Message-ID through its supported channel. The available evidence does not establish that a DNS record change will resolve that scenario. > Do not lower `p=` to work around an unconfirmed sender failure. Policy relaxation changes requested enforcement. It does not repair SPF, DKIM, alignment, routing, or a receiver-specific rule. ## Investigate this with your coding agent Use this after collecting redacted failed-message headers and an exported DNS configuration. The task is to compare evidence and propose a narrow change, not to modify DNS or sender settings. ```agent Problem: A message was rejected with "550 message rejected due to senders dmarc policy" and the failed production path must be compared with the visible From domain. Evidence: Redacted original-message headers, the recipient response, visible From domain, SPF authenticated domain if present, DKIM d= domain if present, and exported DNS records for yourdomain.com. Repository scope: DNS infrastructure-as-code, exported DNS record definitions, and mail-sending configuration files for the affected application. Constraints: Inspect before editing. Do not apply changes until I approve the proposed diff. Exclude secrets, private keys, tokens, unredacted headers, recipient data, and customer data. Identify only the configuration relevant to the confirmed sending path. Requested output: A diagnosis, minimal proposed change, rollback, and unknowns. Verification: Send a new message through the same application and recipient path, then compare the trusted authentication results and recipient response with the failed message. Stop if: Credentials, private data, production mutation, or missing evidence is required. ``` ## How do I validate the repair? Repeat the same sending path. Use the same application, visible From domain, outbound relay or ESP, message type, and recipient provider that produced the rejection. A successful test from another system does not validate the repaired route. Check the relevant layers independently: - DNS: confirm the authoritative record and at least one public lookup return the intended published DMARC record. - Vendor: confirm the sender's own authentication or verification status where that status applies to the affected route. - Message: inspect a newly delivered message's trusted authentication results and compare its domains with the visible From domain. - DMARC: once reports accumulate, review whether the affected source continues to show the expected authentication outcome. Keep the original failure, approved change, passing same-path test, and unresolved questions together in the incident record. A passing public DNS lookup alone is not a completed validation. ## Check the published DMARC record after the evidence review Once you have the visible From domain and the failed message's authentication details, [check the DMARC record](/tools/dmarc) to inspect what is publicly published for that domain. Compare it with the same-path message evidence before proposing any DNS change. For an ongoing sender inventory and remediation workflow, Palisade can analyze DMARC aggregate-report data, identify sending sources and authentication or alignment issues, and create prioritized remediation tickets. It can propose the next policy step when the evidence supports it, while a human reviews the evidence and applies the change. It does not change the DMARC policy itself, control a receiver's private rejection decision, or guarantee delivery. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=dmarc_troubleshooting&utm_content=550-message-rejected-due-to-senders-dmarc-policy) ## Sources and further reading - [Palisade DMARC software](/) - [PowerDMARC DMARC implementation guidance](https://powerdmarc.com) - [Palisade DMARC checker](/tools/dmarc) - [What are 550 errors?](/learning/smtp-error-codes) ## Frequently asked questions ### How to fix DMARC policy of reject? Find the sending path that failed authentication and fix that source, rather than editing the policy. Compare the visible From domain in the rejected message with the SPF-authenticated domain and the DKIM `d=` domain, then repair whichever one does not align. Change the `p=` value only when you are deliberately staging enforcement from monitor to quarantine to reject. ### How to fix 550 email error? Start with the full text of the bounce rather than the number, because `550` covers many different recipient decisions. Save the complete response, the receiving provider, the enhanced status code, the raw headers of the failed message, and the exact route that produced it. Then repair only the condition that evidence names, and retest through the same path. ### What is 550 DMARC policy? It is the wording of a rejection message, not a protocol term. The receiving server refused the message and pointed at the sender's DMARC policy as the reason, but the text does not name the provider, the mechanism that failed, or the alignment result. Pull the headers of the failed message before you decide what to change. ### Why is my message blocked due to DMARC? Your message was blocked because the receiver evaluated it under DMARC and it did not pass for the domain in your From address. That happens when neither SPF nor DKIM produced a passing, aligned result for that domain, often because of a forgotten sending service, a relay, or forwarding along the way. The bounce text alone will not tell you which, so read the rejected message's headers. ### Should I change DMARC to `p=none` after this rejection? No, because loosening the policy hides the problem instead of fixing it. Changing `p=` only changes what you ask receivers to do with failing mail, and it repairs nothing in your SPF, DKIM, alignment, or routing. Find the production path that failed first. --- # ActiveCampaign DMARC checker Canonical: https://www.palisade.email/learning/activecampaign-dmarc-checker > ActiveCampaign DMARC checker guide: inspect a published DMARC record, interpret its policy, validate sending evidence, and retest safely with confidence. An ActiveCampaign DMARC check should start with the domain shown in the visible From address of the marketing message. Use the [Palisade DMARC checker](/tools/dmarc) to inspect the public DMARC TXT record, then compare that DNS evidence with a real delivered message and, later, DMARC aggregate reports. A published record can show the policy a domain asks receivers to apply. It cannot prove that ActiveCampaign sent, signed, or aligned a particular message. ## Quick takeaways - A DMARC checker inspects the public DNS record for the domain in the visible From address. - DMARC evaluates aligned SPF or aligned DKIM, not the presence of a DMARC record alone. - `p=none` requests monitoring treatment, while `p=quarantine` and `p=reject` request stronger handling for failing mail. - A public DNS result does not prove a production ActiveCampaign message passed DMARC at a recipient. - Check a delivered message's authentication results before changing a DMARC policy. - DMARC aggregate reports show sources and outcomes after mail has been sent. ## What this tool checks The [Palisade DMARC checker](/tools/dmarc) is the appropriate first check when you have a domain and need to inspect its public DMARC record. DMARC records are DNS TXT records published at `_dmarc.`. [RFC 7489 defines the DMARC record format and receiver evaluation model](https://datatracker.ietf.org/doc/html/rfc7489). For an ActiveCampaign sender, use the organizational domain from the message's visible From address. ActiveCampaign describes its platform as providing "Personalized email marketing," and its Help Center includes an Email Marketing category with deliverability material. Those facts establish the email-marketing context. They do not establish how a particular ActiveCampaign account signs messages or which DNS values it requires. A public check can answer whether a resolver can retrieve a DMARC record and what tags that record publishes. It cannot see: - The sending application or account that generated a message. - The envelope sender used on the production path. - DKIM signatures on a delivered message. - A recipient's private spam, rejection, or reputation decision. - Future DNS changes, new sending sources, or continuous mail flow. Use the [DMARC learning hub](/learning/dmarc) for the wider record, alignment, and policy model. A domain-level record check is one layer of evidence, not a delivery diagnosis. ![DMARC record interpretation map for an ActiveCampaign sending domain](/images/editorial/activecampaign-dmarc-checker/activecampaign-dmarc-checker-record-map.webp "1200x600") *Source: Palisade.* ## How to run the check ### 1. Identify the visible From domain Send a test campaign through the same ActiveCampaign configuration used for production, if doing so is appropriate for your sending process. Record the domain after the `@` in the visible From address. Do not substitute a tracking domain, a return-path domain, or a domain copied from another account. DMARC uses the RFC 5322.From domain as its identifier, subject to organizational-domain rules in RFC 7489. ### 2. Inspect the published DMARC record Submit that visible From domain to the [Palisade DMARC checker](/tools/dmarc). Keep the result with a timestamp and the exact domain queried. This is useful DNS evidence before a DNS edit or an escalation to the team that controls the domain. You can independently query public DNS with an example domain: ```bash dig +short TXT _dmarc.yourdomain.com ``` If the command returns more than one DMARC-looking TXT string, stop before editing. RFC 7489 says a receiver must treat multiple DMARC records at the same owner name as a permanent error. Determine which DNS system is authoritative and remove the conflict through the domain's approved change process. ### 3. Keep the DNS result separate from message evidence A record such as the following is illustrative only. Do not publish or copy another organization's reporting addresses, tags, or domains into your own DNS. ```text _dmarc.yourdomain.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com" ``` The record shows a requested DMARC policy and optional reporting destination. It does not show whether a real ActiveCampaign message has aligned SPF or DKIM. For that, inspect the raw source of a delivered test message and retain the recipient-added authentication results. ### 4. Confirm ownership before changing DNS If a record is missing, malformed, or too strict for the evidence you have, identify the person or system that manages DNS. The sending service's setup instructions, DNS configuration, and delivered-message headers are separate evidence layers. The [vendor email authentication guide](/learning/esp-setup) explains why a vendor's sending setup should be checked alongside the domain's public authentication records. > Do not weaken an enforcing DMARC policy solely because one campaign had a delivery problem. First determine whether the message failed aligned SPF and DKIM, whether the visible From domain was correct, and whether the recipient's decision was actually a DMARC failure. ## How to interpret the results ### No DMARC record is published If `_dmarc.yourdomain.com` has no usable DMARC TXT record, receivers have no DMARC policy published for that domain. This does not prove that every message fails SPF or DKIM. It means the domain has not published the DMARC policy record that receivers use for DMARC evaluation. Before publishing a record, inventory every legitimate sender that uses the visible From domain. Test actual message paths, including marketing mail, transactional mail, support systems, and forwarding scenarios that matter to the organization. A record should follow evidence, not replace it. ### The record has `p=none` `p=none` asks receivers to take no specific action based on a DMARC failure, subject to receiver policy. It is commonly used while a domain collects evidence through aggregate reporting. It does not make an unauthenticated message pass, and it does not guarantee inbox placement. Use this state to verify the exact sources sending as the domain and identify where SPF or DKIM alignment fails. [RFC 7489's DMARC policy tags](https://datatracker.ietf.org/doc/html/rfc7489#section-6.3) define `none`, `quarantine`, and `reject`. ### The record has `p=quarantine` or `p=reject` `p=quarantine` requests that failing mail be treated as suspicious. `p=reject` requests that failing mail be rejected. Receivers can apply local policy, so the record does not guarantee a uniform recipient outcome. Treat an enforcing policy as a change-control issue. Confirm that the production message path has an aligned SPF pass or an aligned DKIM pass before making the policy stricter. A green vendor status indicator is not a delivered-message check. ### The record is malformed or has conflicting values A malformed record can prevent reliable DMARC evaluation. Check the record against RFC 7489 before editing. Common protocol questions include whether `v=DMARC1` is present, whether `p=` has a valid value, and whether there is exactly one DMARC record at the queried owner name. Do not assume that a DNS response from one resolver explains every recipient result. Confirm the authoritative DNS answer, then check at least one public resolver after a change. ## How to act on the result Start with the narrowest repair supported by evidence. - If no record exists, determine whether the domain has a complete inventory of legitimate senders. Publish only a record approved by the DNS owner after that inventory and reporting plan are in place. - If the record is malformed, correct the syntax at the exact `_dmarc` owner name. Preserve unrelated DNS records. - If the record is valid but a message failed, inspect the delivered message's `Authentication-Results` header. [RFC 8601 defines this receiver-added authentication status field](https://datatracker.ietf.org/doc/html/rfc8601). Check the visible From domain, the SPF authenticated identity, the DKIM `d=` domain, and whether either passing identity aligns. - If the recipient accepted or filtered mail unexpectedly, use that recipient's message evidence or provider dashboard. A public DMARC lookup cannot identify a receiver's private filtering decision. For Gmail-bound mail, the [email authentication guidance for Gmail](/learning/authenticate-email-for-gmail) can help separate sender authentication work from recipient-specific delivery observations. Stronger authentication supports deliverability, but it does not guarantee inbox placement. ## Investigate this with your coding agent Use this when the domain's DNS is managed in a repository or infrastructure-as-code system and you have a redacted DMARC lookup result. Remove report addresses, account identifiers, tokens, private keys, unredacted headers, and customer data before sharing evidence. ```agent Problem: The ActiveCampaign visible From domain has a missing, malformed, conflicting, or policy-inappropriate public DMARC TXT record. Evidence: Redacted Palisade DMARC checker result, exact queried domain, intended DMARC policy, and a redacted delivered-message authentication summary if available. Repository scope: DNS infrastructure or configuration files that manage the queried domain's _dmarc TXT record. Constraints: Inspect before editing. Do not apply changes until I approve the proposed diff. Do not expose or add report addresses, tokens, private keys, account-specific hostnames, or unrelated DNS changes. Requested output: File location, diagnosis, minimal proposed change, rollback, and unknowns. Verification: Run the same Palisade DMARC checker against the exact queried domain, confirm the authoritative TXT answer, and compare a new delivered message from the same sending path. Stop if: Credentials, private data, production mutation, or missing evidence is required. ``` ## How to retest After an approved DNS correction, query the same `_dmarc` owner through the same checker and retain the new timestamped result. Then verify DNS through the authoritative provider and at least one public resolver. Send a new message through the same ActiveCampaign campaign configuration, sender identity, recipient path, and visible From domain. Inspect the new message's authentication results. Finally, review DMARC aggregate reports once they accumulate. These four layers answer different questions: - DNS confirms the record published for the domain. - Vendor configuration confirms the intended sending setup. - A delivered message confirms what the exact production path used. - DMARC aggregate reports reveal observed source and authentication patterns over time. Do not conclude that a DNS correction fixed delivery until the delivered-message layer supports that conclusion. ## Track the senders behind the record A public DMARC check is useful for the first DNS question: what policy does the domain publish today? It does not show which production sending sources remain unauthenticated or unaligned after an ActiveCampaign change. Palisade is agentic DMARC software that analyzes DMARC aggregate-report data, identifies sending sources and authentication or alignment issues, and creates prioritized remediation tickets. It can propose the next DMARC policy step when the evidence supports it, while a human reviews the evidence and applies the DNS change. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=vendor_setup&utm_content=activecampaign-dmarc-checker) Palisade does not autonomously change the DMARC policy, prove every future message will authenticate, or control a receiver's private delivery decision. ## Sources and further reading - [RFC 7489: Domain-based Message Authentication, Reporting, and Conformance](https://datatracker.ietf.org/doc/html/rfc7489) - [RFC 8601: Message Header Field for Indicating Message Authentication Status](https://datatracker.ietf.org/doc/html/rfc8601) - [Palisade DMARC checker](/tools/dmarc) - [ActiveCampaign](https://activecampaign.com) - [ActiveCampaign Help Center](https://help.activecampaign.com) ## Frequently asked questions ### Does a published DMARC record prove ActiveCampaign mail passes DMARC? No. A published record shows the policy and tags visible in public DNS. A delivered message is required to confirm the SPF and DKIM identities that the production sending path used and whether either one aligned with the visible From domain. ### Should I use the ActiveCampaign sending domain or the visible From domain? Yes, use the visible From domain for the DMARC record check. DMARC identifies mail using the RFC 5322.From domain, then evaluates alignment against authenticated SPF or DKIM identities. ### Can `p=none` protect a domain from spoofing? No. `p=none` requests no specific disposition for DMARC failures. It can support evidence gathering through reporting, but it does not request quarantine or rejection treatment for failing messages. ### Does `p=reject` guarantee that every receiver rejects spoofed mail? No. DMARC policies are requests to receivers, and receivers can apply their own local policy. A `p=reject` record is stronger than `p=none`, but it does not guarantee one outcome at every recipient. ### What should I check after correcting a DMARC record? Check the same public record again, confirm the authoritative DNS answer, send a new message through the same production path, inspect its authentication results, and review aggregate reports after they accumulate. --- # Agari DMARC checker: what to verify before you rely on a result Canonical: https://www.palisade.email/learning/agari-dmarc-checker > Agari DMARC checker guidance: check a domain's public DMARC record, understand the evidence limit, and identify what still needs validation. An Agari DMARC checker search should begin with the public DMARC record for the domain you need to assess. A record lookup can show whether a DNS-published DMARC record is visible, but it cannot confirm the production sending path, message authentication, a receiver's decision, or ongoing domain state. If you need the basics first, see [Palisade's DMARC learning hub](/learning/dmarc). ## Quick takeaways - A DMARC check can mean checking whether a domain publishes a public DMARC record. - A public record lookup is useful evidence, but it is only one part of a DMARC assessment. - The available material does not verify a current public Agari DMARC checker or its result states. - A DNS result cannot prove that a production sender signs messages correctly. - A receiver's inbox, spam, rejection, or quarantine decision needs message and receiver-specific evidence. - A DMARC program needs evidence from DNS, the sending service, delivered messages, and aggregate reports. ## What this tool checks A DMARC checker is intended to inspect a domain's publicly available DMARC record. [DMARC Report describes its free tools as tools that verify DMARC, SPF, DKIM, BIMI, and MTA-STS records without signup](https://dmarcreport.com). That describes a public DNS-checking task. Use the [Palisade DMARC checker](/tools/dmarc) when the evidence you have is a domain name and you want to inspect its public DMARC record. Treat the result as a point-in-time DNS observation. A public lookup cannot see: - Which applications, ESPs, gateways, or services actually send mail for the domain. - Whether those systems use the domain's intended authentication configuration. - The `Authentication-Results` added to a delivered message. - A mailbox provider's private filtering or reputation decision. - Later DNS changes, new senders, or future message outcomes. For a broader explanation of the protocol's role, read [what DMARC is](/learning/what-is-dmarc). If a recipient has already rejected a message, the [550 5.7.0 DMARC policy violation guide](/learning/550-5-7-0-dmarc-policy-violation) is a better starting point than a DNS result alone. ![Evidence map for checking a public DMARC record and validating a production sending path](/images/editorial/agari-dmarc-checker/agari-dmarc-checker-evidence-map.webp "1200x676") *Source: Palisade.* ## How to run the check ### 1. Start with the visible From-domain Use the domain that appears after the `@` sign in the visible From address of the mail you are assessing. Record the domain exactly. Do not substitute a sending service's domain unless the question is specifically about that service's own DMARC record. If the issue concerns one failed message, preserve a redacted copy of the raw headers before changing DNS. A domain lookup and a message header answer different questions. ### 2. Check the public DMARC record Open the [Palisade DMARC checker](/tools/dmarc) and submit the domain you need to inspect. Keep a timestamp with the result because public DNS data can change. You can also repeat the public lookup from a command line with an example domain: ```bash dig +short TXT _dmarc.yourdomain.com ``` This command queries for TXT data at the standard DMARC record owner name for the example domain. It is a public-DNS observation. It does not show whether a specific email platform sent a message, which authentication result a recipient recorded, or why a recipient handled one message in a particular way. ### 3. Preserve the result as one evidence layer Save the exact returned text and the time of the lookup. Then separate the next questions: - DNS question: is a public DMARC record visible for the domain? - Vendor question: does the sending platform show the domain as configured and verified? - Message question: what authentication results appear on a newly delivered message from the same production path? - DMARC-program question: what do aggregate reports show after data accumulates? Do not treat a green-looking DNS result as evidence for all four questions. ## How to interpret the results The available public material does not document current Agari result labels, a current Agari user-interface path, or the exact result states of the Palisade DMARC checker. Do not infer a product-specific diagnosis from an unverified label or from a generic product image. ### A public record is returned A returned DNS value is evidence that the queried public DNS name has an answer at the time of the check. It is appropriate to record the returned value and move to the sender configuration and delivered-message layers. It is not enough to conclude that every sender using the visible From-domain passes DMARC. The record does not expose the configuration of every application that may send mail for the domain. ### No usable record is visible A missing or unusable public result is a reason to investigate the domain, the queried DNS owner, and the authoritative DNS configuration. Before publishing or changing a record, compare the authoritative answer with at least one public resolver result. Do not copy a record, host name, token, selector, or target from another organization. DNS values generated by an email provider are specific to the relevant account and domain. ### The record is visible but the mail issue continues A public result cannot explain a recipient-specific delivery problem by itself. Move to a message sent through the exact production path, then inspect the recipient's raw message source and the sender platform's current status. If the recipient has provided a rejection message, retain that exact text and use the recipient's documentation or dashboard where available. ### The result is unclear or differs across lookups Treat differing observations as a DNS investigation, not proof that a mail platform is broken. Record the domain, lookup time, resolver used, returned answer, and whether the authoritative DNS server agrees. Do not change a DMARC policy based solely on a single ambiguous public lookup. ## How to act on the result Use the evidence in order so that a public record check does not become a premature production change. - Confirm the domain. Check that the domain belongs to the visible From address or the stated operational question. - Record the public DNS answer. Keep the exact output and timestamp from the checker or command. - Check the domain in the relevant sending platform. Confirm the current domain-verification or authentication status using that provider's own interface and documentation. - Send a fresh test message through the same application, account, sender identity, and route used in production. - Inspect the delivered message's raw source. Retain only redacted headers when sharing evidence externally. - Review DMARC aggregate-report data after reports have accumulated. DMARC Report describes report processing as a way to see sending sources and whether messages pass SPF, DKIM, and DMARC checks, as well as authentication failures or unauthorized senders ([DMARC Report product description](https://dmarcreport.com)). - Escalate a receiver-specific decision to the receiver's own dashboard, documentation, or support channel when that is the only source that can explain it. > Do not raise or change a DMARC policy from a public lookup alone. A DNS check does not inventory every production sender or prove the result of a delivered message. ## Investigate this with your coding agent Use this when you have a redacted checker result and need to document the application's actual input handling or deterministic public-DNS result states before proposing a website or DNS-related change. ```agent Problem: Determine what the DMARC checker returns for a redacted test domain and whether the public result matches the DNS lookup. Evidence: Redacted checker output, queried example domain, lookup timestamp, and redacted DNS response. Exclude private keys, tokens, unredacted headers, and customer data. Repository scope: Inspect the DMARC checker route and DNS lookup implementation only. Constraints: Inspect before editing. Do not apply changes until I approve the proposed diff. Do not alter DNS, production configuration, or tool behavior. Requested output: Diagnosis, minimal proposed change, rollback, and unknowns. Verification: Retest the same example domain through the same checker path and compare it with a fresh public DNS lookup. Stop if: Credentials, private data, production mutation, or missing evidence is required. ``` ## How to retest Repeat the same domain lookup after the authoritative DNS answer has changed or after you have clarified the domain under investigation. Use the same domain spelling and record the time of the retest. Then repeat the production-path test separately: - Send a new message through the same sender and application. - Inspect the new delivered message rather than relying on an earlier message. - Confirm the relevant vendor's current domain status in its interface. - Review aggregate-report data when available. The expected DNS change is limited to the public record result you intended to correct. A changed DNS result does not, by itself, establish that the sender is authenticating or that every receiver will accept future mail. ## Check the public record, then close the production evidence gap If you are assessing a domain after an Agari DMARC checker search, inspect the domain's public DMARC record first. Then compare that DNS observation with sender configuration, a real delivered message, and aggregate-report evidence before making a policy decision. [Check the DMARC record](/tools/dmarc) A public record check cannot prove a specific production sender's authentication result, repair sender configuration, monitor later DNS changes, or guarantee how a receiver will handle a message. For teams that need to work through recurring sender and alignment evidence, [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=dmarc_tools_validation&utm_content=agari-dmarc-checker). Palisade analyzes DMARC aggregate-report data, identifies sending sources and authentication or alignment issues, and creates prioritized remediation tickets. A human reviews the evidence and applies any DNS or policy change. ## Sources and further reading - [Palisade DMARC checker](/tools/dmarc) - [DMARC Report free record-checking tools](https://dmarcreport.com) - [DMARC Report product overview](https://dmarcreport.com) - [Palisade DMARC learning hub](/learning/dmarc) ## Frequently asked questions ### What is Agari DMARC protection? "Agari DMARC protection" is a vendor product name rather than a standard term, so what it covers depends on Agari's own current documentation. Confirm the product name, the checker it offers, and the workflow it supports there before you follow product-specific guidance. To inspect a domain's public DMARC record right now, use the [Palisade DMARC checker](/tools/dmarc). ### How to check DMARC status? Check the domain's public DMARC record with a DNS-based checker such as the [Palisade DMARC checker](/tools/dmarc), then record the result and timestamp. A complete status assessment also needs the sending platform's status, a real delivered message from the production path, and DMARC aggregate-report evidence. ### What is a DMARC check? A DMARC check is a DNS lookup that reads the DMARC record a domain publishes at `_dmarc.yourdomain.com`. DMARC Report describes its free tools as verifying DMARC records, alongside SPF, DKIM, BIMI, and MTA-STS records ([DMARC Report](https://dmarcreport.com)). The lookup shows the published record, not how a specific message authenticated. ### How to check if DMARC is enforced? Read the policy the domain publishes in its DMARC record, which is the `p=` tag returned by a lookup such as the [Palisade DMARC checker](/tools/dmarc). That tells you what the domain asks receivers to do, not whether your production senders pass. Before you treat enforcement as safe, review the sending sources, a delivered message from the production path, and aggregate-report data. ### Can a DNS result explain why one recipient rejected a message? No, because a DNS result only shows the record published at the time of the check. A rejection is explained by the raw headers, the exact rejection text the receiver returned, the receiver's own documentation, and the sending platform's record of that message. --- # AI email warmup: what it is and what it cannot prove Canonical: https://www.palisade.email/learning/ai-email-warmup > AI email warmup automates messages and mailbox interactions to try to improve sender reputation, but it cannot prove inbox placement or email. AI email warmup is software that automates sending activity and positive mailbox interactions for a connected inbox in an attempt to improve sender reputation and email deliverability. It is a vendor workflow, not an email standard or proof that future campaigns will reach inboxes. It also does not validate DMARC, SPF, DKIM, DNS, or a receiver's private spam decision. ## Quick takeaways - AI email warmup describes an automated vendor workflow, not a mailbox-provider protocol. - A warm-up product may send messages from a connected inbox and automate interactions with those messages. - Warmbox says its workflow can remove messages from spam, open, bookmark, and reply to some messages. - A connected inbox can use different connection methods, depending on the vendor and provider. - Warm-up activity does not prove that a production campaign will authenticate or reach the inbox. - [Email deliverability](/email-deliverability) covers a broader operational discipline than inbox warm-up. ## How AI email warmup works The available vendor description is straightforward. [Warmbox describes its service as an "AI-based warm-up tool"](https://warmbox.ai) intended to raise inbox reputation and improve email deliverability. Its stated mechanism is automated mail sent from the connected inbox, followed by interactions that resemble lead engagement. According to [Warmbox's product description](https://warmbox.ai), those automated interactions can include removing messages from spam, opening messages, bookmarking messages, replying to some messages, and generating positive interactions. The vendor also says users connect an inbox before starting warm-up, with examples that include Gmail or Google Workspace OAuth, Outlook 365, Yahoo Mail, Amazon SES, and SMTP. That workflow has two distinct parts: - The tool needs access to an inbox or sending path that the user connects. - The tool automates messages and interaction signals around those messages. Neither part establishes why a receiving mailbox placed a specific production message in spam or the inbox. Mailbox providers can make decisions using signals that are not public, and a warm-up product cannot expose every part of that decision. ![Decision flow showing what AI email warmup can automate and the separate evidence needed for authentication and mailbox placement](/images/editorial/ai-email-warmup/ai-email-warmup-decision-flow.webp "1200x676") *Source: Palisade.* AI-assisted email tooling can cover several jobs that should remain separate. For example, [Apollo documents email warm-up under its email deliverability materials](https://knowledge.apollo.io), while [Instantly presents AI outreach, campaign automation, and deliverability as separate product areas](https://instantly.ai). Those product categories may appear together in a sales workflow, but that does not make a warm-up result an authentication check or a placement guarantee. For a broader look at where AI can help with email-security work, see [AI-powered email security](/learning/ai-powered-email-security). The relevant question is always what evidence the tool actually collects and what decision it can support. ## When the answer changes AI email warmup can mean different product mechanics across vendors because there is no supplied standard definition from an RFC, IETF specification, or mailbox-provider guidance. Treat a vendor's product page as a description of that vendor's workflow, not as a universal rule. Use this decision rule: - If you need to know whether a warm-up vendor sends messages and automates inbox interactions, use that vendor's current documentation. - If you need to know whether your domain has a public authentication or DNS issue, inspect the domain's configuration. - If you need to know how one delivered message authenticated, inspect the raw message headers from that exact sending path. - If you need to know whether a receiver accepts, filters, or places your production mail, use evidence from the affected provider, campaign, and delivered messages. A public configuration result and a mailbox-placement result answer different questions. A security check can identify exposed authentication gaps, but it cannot prove continuous sending behavior, a recipient's private filtering decision, or future inbox placement. Do not treat a warm-up dashboard as proof that every system using the domain is ready to send. Marketing platforms, transactional services, support systems, and employee mail can use different authentication paths and visible From domains. ## A worked evidence example Consider a team that connects `sales@yourdomain.com` to a warm-up product before starting outbound campaigns. The product may report automated messages and positive interactions. That is evidence about the warm-up workflow, not a complete deliverability diagnosis. ```text Warm-up evidence: sales@yourdomain.com was connected to a vendor workflow Authentication evidence: inspect the production message headers for SPF, DKIM, and DMARC results DNS evidence: inspect the public domain configuration Placement evidence: review messages delivered through the actual campaign path ``` The evidence should lead to different actions: - If the warm-up tool is active but authentication evidence is missing, obtain a real delivered message from the production sender and inspect its headers. - If the public domain configuration has a gap, fix the configuration through the appropriate domain and sending-service process before treating the issue as a reputation problem. - If authentication passes but a receiver still filters mail, collect receiver-specific evidence. A warm-up result does not identify the receiver's exact reason. - If the team manages many domains or sending sources, track each source separately. One connected inbox does not represent every sender that uses `yourdomain.com`. This distinction matters because sender reputation and email authentication are related but different. Stronger authentication supports better deliverability, but it does not guarantee inbox placement. ## Choose the next check based on your evidence Start with the evidence you already have. If you only have a domain name and a concern that its email posture may be weak, use the [Email Security Score tool](/tools/email-security-score). It is a useful first diagnostic for public-facing email-security configuration. If you have a production message, preserve its raw headers and compare the authentication results with the visible From domain and the actual sending service. That message is more relevant than a generic warm-up report when the problem is a failed or filtered campaign. If you are deciding whether warm-up belongs in an outreach process, read [Apollo email warmup: what it does and what it cannot prove](/learning/apollo-email-warmup). Keep the vendor workflow separate from evidence about the domain, the production sender, and the receiving mailbox. ## Check the email-security posture behind the warm-up question Before attributing delivery trouble to reputation alone, inspect the public email-security configuration for the sending domain. That gives you a starting point for questions that a warm-up workflow does not answer. [Check the domain's email-security score](/tools/email-security-score) A public score cannot prove that a connected inbox will reach the inbox, repair a sender configuration, monitor every production source, or reveal a receiver's private filtering decision. If your team needs to inventory sending sources, analyze DMARC aggregate-report data, and prioritize authentication or alignment issues across domains, [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=email_deliverability&utm_content=ai-email-warmup). Palisade is agentic DMARC software that analyzes aggregate-report data and proposes remediation priorities, while a human reviews the evidence and applies changes. It does not change DMARC policy automatically or guarantee delivery or inbox placement. ## Sources and further reading - [Warmbox](https://warmbox.ai) - [Apollo knowledge base](https://knowledge.apollo.io) - [Instantly](https://instantly.ai) - [Palisade Email Security Score tool](/tools/email-security-score) - [Email deliverability](/email-deliverability) ## Frequently asked questions ### Is AI email warmup an email standard? AI email warmup is not a standard. It is a category of vendor software, and no RFC, IETF specification, or mailbox provider defines it. Each vendor decides what its own warm-up workflow does, so compare products on their documented mechanics rather than the label. ### Can AI email warmup prove inbox placement? No warm-up product can prove inbox placement, because automated messages inside a vendor network say nothing about how a receiving provider will treat your next production message. Placement evidence comes from the real sender, the delivered messages, and the receiver involved. ### Does AI email warmup check DMARC, SPF, or DKIM? No, warm-up tools do not check DMARC, SPF, or DKIM. They connect an inbox and automate activity around messages, which is a separate job from validating the domain's authentication and DNS configuration. Check the domain and a real delivered message for that. ### Does connecting one inbox warm up every sender on a domain? No, connecting one inbox affects only that inbox and its configured sending path. Marketing platforms, transactional services, support systems, and employee mail can use the same domain with different authentication settings and different delivery outcomes. Track each sending source on its own. ### Should a team investigate authentication before blaming a warm-up problem? Yes, check authentication first, because a domain-level email-security check and the raw headers from a real production message reveal problems a warm-up report cannot see. Reputation work is worth doing after you know the authentication path is sound. --- # Analyze email headers online Canonical: https://www.palisade.email/learning/analyze-email-headers-online > Analyze email headers online by separating message evidence from DNS and MX checks, then use the right source for routing and transport issues. To analyze [email headers](/tools/email-header-analyzer) online safely, first separate the copied message evidence from the sending domain's published DNS and MX configuration. A header copy can point to a routing or transport question, but an MX or DNS lookup checks the domain's current public configuration rather than the contents of that individual message. There is no single published universal requirement or operative date for online header analysis. ## Quick takeaways - An email header is message-level evidence, while MX and DNS lookups inspect a domain's published configuration. - A public MX lookup can list MX records in priority order, but it cannot inspect a copied message header. - A routing-related clue in a message may justify a separate mail-server diagnostic. - Current DNS results do not prove the configuration that existed when a specific message was delivered. - An online check cannot establish a receiver's private delivery decision from public DNS alone. ## Who is affected? This guidance applies to an operator investigating one delivered, delayed, rejected, or suspicious email and trying to decide what evidence to collect next. It is also useful for teams responsible for a domain's mail-routing configuration. The scope is deliberately narrow. A copied message header and a domain lookup answer different questions: - Message evidence concerns the particular email you received or sent. - DNS and MX evidence concerns the records a domain publishes when the lookup occurs. - Mail-server diagnostics concern the reachable server and its observable network behavior. If you need a basic explanation of what a message header is before collecting evidence, start with [what is an email header](/learning/what-is-an-email-header). For broader DNS, SMTP, and transport topics, use the [infrastructure learning hub](/learning/infrastructure). Do not treat a current public lookup as a historical record of the exact delivery path. DNS records can change after a message arrives. A public lookup also cannot reveal a mailbox provider's private filtering or placement decision. ## What are the requirements? There is no IETF or mailbox-provider requirement in the available public evidence that defines one universal process for analyzing email headers online. The practical requirement is to match the test to the evidence you have, and to avoid treating one kind of evidence as proof of another. ### Keep the message copy and domain lookup separate If you have a copied header from one message, preserve it as message evidence. If you also need to inspect the domain's public routing configuration, perform that check separately by [querying the domain's MX records](/tools/mx). [MXToolbox describes its MX Lookup test](https://mxtoolbox.com/) as listing a domain's MX records in priority order and performing the lookup against the authoritative name server. That supports a narrow operational conclusion: an MX lookup can help inspect current routing configuration, but it does not analyze the header copy from an individual email. ```text Message evidence A copied header from one delivered or rejected email Domain evidence MX and DNS records returned for yourdomain.com at lookup time Do not equate these two evidence sets. ``` ![Decision checklist for separating copied message evidence from current DNS and MX lookup evidence](/images/editorial/analyze-email-headers-online/analyze-email-headers-online-decision-checklist.webp "1200x524") *Source: Palisade.* ### Use a DNS check for the published domain, not the message body When the question is "What does this domain publish now?", use a DNS lookup. The [Palisade DNS lookup](/tools/dns-lookup) is appropriate for checking public DNS records associated with a domain. A DNS result can support a configuration investigation. It cannot prove that the message used a particular production path, that the mail server accepted a particular SMTP session, or that a recipient evaluated the message in a particular way. Use example values when recording the distinction for a ticket or handoff: ```text Domain to inspect: yourdomain.com Question: What records are publicly published now? Evidence collected: DNS lookup result and lookup time Evidence not established: contents or handling of one specific message ``` ### Escalate a routing clue to a mail-server diagnostic A message investigation can uncover a routing-related question that public DNS alone does not answer. In that case, use a diagnostic that targets the mail server itself. MXToolbox states that its Diagnostics option can “connect to the mail server, verify reverse DNS records, perform a simple Open Relay check and measure response time performance.” That is distinct from reading a message header and distinct from listing MX records. This distinction matters in practice. A domain can publish MX records, while a separate server-level question remains open. Conversely, a mail-server diagnostic does not reconstruct the exact content or handling of a message you received. > Do not paste unredacted headers, recipient addresses, message identifiers, or other customer data into a third-party service unless your organization's data-handling rules permit it. Keep the original message and its evidence in an approved system. ## When does the requirement take effect? No dated, universal header-analysis requirement applies to this task in the available source material. Header analysis is an investigation method, not a single mailbox-provider compliance deadline. MX records are DNS configuration data. Their current result reflects the lookup performed at that time, not a requirement date for interpreting an individual message. If your investigation concerns a provider-specific deadline, use that provider's current official documentation rather than applying a general header-analysis rule. For the related transport layer, see [email transport security](/learning/infrastructure). Transport-security requirements and mailbox-provider enforcement policies need their own source-backed dates and scope. ## How do I implement the requirement? ### 1. Define the question before choosing a checker Write down whether you are investigating a specific message, a domain's published routing records, or a reachable mail server. One question can lead to more than one check, but each check should have a defined purpose. A useful ticket note can look like this: ```text Observed issue: Delivery or routing question for one message Message evidence available: copied header, if approved for handling Domain evidence needed: current MX or DNS records Server evidence needed: only if routing or reachability needs investigation ``` ### 2. Preserve the message evidence in an approved location Keep the original message evidence with the incident or support case. Remove or restrict access to personal data according to your organization's policy. Do not assume a domain lookup can replace message evidence. The two artifacts may be collected at different times and answer different questions. ### 3. Check published DNS and MX records separately Run the sending or receiving domain through the [DNS lookup tool](/tools/dns-lookup) when you need current public record evidence. Record the domain and the time of the lookup with the result. If the issue is an MX-routing question, an MX lookup can show the current priority-ordered records. That result is useful for comparing current configuration with the question raised by the message, but it does not prove the historical path of that message. ### 4. Use a server diagnostic only for a server-level question If the evidence points to reachability, reverse DNS, open-relay exposure, or response time, use an appropriate server diagnostic. Keep the diagnostic result separate from the copied message evidence. This avoids a common investigation error: treating a successful public configuration check as proof that the individual message was handled correctly. ### 5. Record what each result does not establish Every investigation note should state the limit of the evidence. For example, a current DNS check does not establish a receiver's private filtering decision. A mail-server diagnostic does not prove the full path or interpretation of a prior message. For authentication-specific troubleshooting, [email authentication failure: diagnose the right layer](/learning/email-authentication-failure) helps keep DNS, vendor status, delivered-message evidence, and DMARC reporting separate. ## How do I validate compliance? Validate the evidence at the layer where the question exists. - For public routing configuration, collect the domain's current DNS or MX result and the lookup time. - For a mail-server question, collect the diagnostic result that addresses the server behavior. - For a specific message, retain the approved message evidence and compare it only with claims that the evidence can support. - For ongoing authentication posture, use DMARC aggregate-report data after it has accumulated. A one-time DNS lookup does not show every production sender or later configuration drift. A complete operational check often needs more than one layer. Public DNS is one layer. A vendor's current status is another. A real delivered message from the production path is separate evidence. DMARC aggregate reports add broader sending-source evidence over time. Do not describe a public lookup as proof of inbox placement, future delivery, or a mailbox provider's private decision. Those conclusions require evidence from the relevant system and may remain unavailable. ## Check the transport-security context behind the routing question If the header investigation has narrowed the issue to mail transport or domain routing, review [email transport security](/learning/infrastructure) before changing DNS or mail-server configuration. That guide provides transport context. It does not analyze a specific copied message header, prove the exact historical route of a message, or reveal a receiver's private delivery decision. ## Sources and further reading - [MXToolbox MX Lookup and Diagnostics](https://mxtoolbox.com/) - [Palisade DNS lookup](/tools/dns-lookup) - [Email transport security](/learning/infrastructure) - [Email authentication failure: diagnose the right layer](/learning/email-authentication-failure) ## Frequently asked questions ### Can an MX lookup analyze an email header online? An MX lookup cannot analyze a header, because it inspects the MX records a domain publishes rather than the contents of one message. Read the header from your preserved copy of that message, and treat the MX result as separate evidence about the domain's current routing. ### Does a current DNS lookup prove how a past email was routed? No, a current DNS lookup cannot prove how an earlier message was routed, because it only shows the records returned at the moment the lookup runs. Records can change after a message arrives. Save the lookup time with the result so nobody later reads it as a historical record. ### Can a mail-server diagnostic replace message evidence? No, a server diagnostic cannot replace message evidence, because it reports server behavior such as reverse DNS, open-relay exposure, and response time. It does not reconstruct the header content or the handling of a message that was already delivered. Keep both artifacts and compare them. ### Does a public DNS check prove inbox placement? No, a public DNS check cannot prove inbox placement, because mailbox providers keep their filtering and placement decisions private. That evidence has to come from the receiving provider or from the messages your sending path actually delivered. ### Should I share a full email header with an online service? Share a full header only when your organization's data-handling rules allow it. Headers can carry recipient addresses, message identifiers, internal hostnames, and routing details, so handle them as message evidence rather than as a throwaway string. When the rules are unclear, redact the personal fields or keep the analysis inside an approved system. --- # What is an anti-phishing program? Canonical: https://www.palisade.email/learning/anti-phishing-program > Anti phishing program: an operating model for ownership, controls, reporting, response, and measurement that reduces organizational phishing risk. An anti-phishing program is an organizational operating model for reducing phishing risk through accountable ownership, technical controls, staff reporting, incident response, measurement, and recurring review. It is not one email-security product or an annual training session. A useful program connects preventive controls with a way for people to report suspicious messages, then uses the resulting evidence to improve controls and response. ## Quick takeaways - An anti-phishing program needs named owners for controls, reporting, triage, communications, and incident decisions. - Employee awareness matters, but training alone does not prevent or contain phishing incidents. - The reporting route should be easy to find and should hand reports to a defined triage process. - Authorized phishing exercises can measure behavior, but they are not a substitute for technical controls or incident response. - Metrics should show reporting, response, control performance, and recurring weaknesses. - DMARC helps protect a domain from unauthorized use in the visible From field, but it does not stop every phishing attack. ## How an anti-phishing program works An anti-phishing program combines people, process, and technology around a single operational goal: reduce the chance that a phishing message succeeds and reduce the impact when one reaches a user. The [CISA Cybersecurity Performance Goals](https://www.cisa.gov/cybersecurity-performance-goals) identify phishing-resistant multifactor authentication, user awareness, and email protections as important safeguards. Those safeguards need operating ownership. Someone must decide what gets configured, review evidence, handle reports, and authorize changes that affect mail flow or user access. A program normally has these connected components: - **Governance and scope:** Define the business units, mail systems, identities, third parties, and high-risk workflows in scope. Assign an accountable security owner and operational owners for each control. - **Preventive controls:** Use email filtering, domain authentication, access controls, and phishing-resistant multifactor authentication where appropriate. [NIST's phishing guidance](https://csrc.nist.gov/pubs/tn/2276/final) treats phishing as a problem that requires multiple controls, not one user behavior intervention. - **Reporting and triage:** Give staff a clear route to report a suspicious message. Define who receives the report, what evidence they inspect, when they remove or block a message, and when they escalate. - **Awareness and exercises:** Train people on the reporting route and the threats relevant to their work. Run authorized exercises only under documented scope and leadership approval. - **Incident response:** Connect phishing reports to the incident process. A report about credential entry, malicious attachments, payment changes, or account takeover needs a known handoff and decision owner. - **Measurement and improvement:** Review outcomes on a fixed cadence, identify recurring failure patterns, and assign follow-up work. The [Department of Justice phishing awareness program guidance](https://www.justice.gov/jmd/page/file/1368721/dl?inline=) describes a program model that includes training, testing, reporting, and metrics. The important operating point is the feedback loop. A reported phish can reveal a filter gap, a targeted business process, an authentication weakness, or a training need. For the threat itself and common forms it takes, see [what phishing is](/learning/what-is-phishing). ## When the answer changes The components stay broadly similar, but the program design changes with the organization’s risk and operating environment. A small organization may have one security lead coordinating email administration, help desk triage, and incident response. A larger organization may split those duties among security operations, identity, messaging, legal, finance, HR, and regional teams. In both cases, ownership must be explicit. A shared inbox without a triage owner is a reporting channel, not a reporting process. Use this decision rule: - If a user can report a suspicious email but nobody has a response target or authority to act, prioritize triage ownership and escalation rules. - If reports repeatedly identify messages that bypass filtering, prioritize the evidence from those reports and tune the relevant preventive control. - If exercises show that users do not recognize the reporting route, improve the route and training before treating click rates as the sole program outcome. - If attackers impersonate your organization’s visible From domain, assess domain authentication and DMARC separately from inbound filtering. [PCI DSS requirement 5.4.1](/learning/does-pci-dss-4-0-require-dmarc) may also affect how some organizations document anti-phishing controls. > A phishing exercise can affect users, support teams, and business operations. Define its purpose, scope, authorization, support plan, and escalation path before sending it. No control proves that phishing risk is eliminated. A secure email gateway may not see every social-engineering channel. DMARC does not evaluate a fraudulent domain that an attacker controls. Training does not replace a response process after a user enters credentials. ## A workable ownership and evidence matrix Start with a dated matrix that gives each part of the program an owner, a recurring cadence, evidence to retain, and a trigger for escalation. The structure below is illustrative only. Replace each role and timeframe with the organization’s approved model. ```text Program area: Suspicious-email reporting Owner: Service desk lead Cadence: Review reports each business day Evidence: Report volume, message samples, triage outcome Escalate when: Credential entry, malware, payment fraud, or executive impersonation is reported Program area: Inbound email controls Owner: Messaging security owner Cadence: Review after material incidents and at scheduled control reviews Evidence: Filter decisions, allow-list changes, incident findings Escalate when: A confirmed phishing message reaches multiple recipients Program area: Domain impersonation controls Owner: Domain and email administrator Cadence: Review DNS changes and DMARC aggregate-report findings Evidence: Published DNS records, delivered-message headers, DMARC reports Escalate when: An unknown source uses the organization’s visible From domain Program area: Awareness exercises Owner: Security awareness owner Cadence: Run only under approved campaign plan Evidence: Authorization, audience, reporting behavior, follow-up actions Escalate when: The exercise creates a support or business-impact issue ``` ![Checklist showing anti-phishing program areas with an owner, cadence, retained evidence, and escalation trigger](/images/editorial/anti-phishing-program/anti-phishing-program-ownership-checklist.webp "1200x524") *Source: Palisade.* The matrix is useful because it separates evidence types. A DNS lookup can show what a domain publishes. A vendor dashboard can show its own status. A delivered message and its `Authentication-Results` header show what happened on one real sending path. DMARC aggregate reports add source-level evidence after reports accumulate. None of these layers alone proves that the whole program works. ## What to do next with the evidence you have Start with the evidence already available. - If you have staff reports, document the current report-to-triage path and measure how long it takes to acknowledge, classify, and close reports. - If you have recent incidents, identify the missed control or broken handoff. Do not assume the cause was user awareness without reviewing the message, identity, and response evidence. - If you have an approved exercise plan, keep it focused on the reporting behavior and remediation question it is meant to test. For campaign design, see why organizations run regular phishing simulations. - If you are selecting an email-security product, use [anti-phishing software: how to compare business tools](/learning/anti-phishing-software). Product selection is one workstream, not the program itself. - If domain impersonation is in scope, inspect the published DMARC record and compare its DNS result with delivered-message headers and aggregate reports. A public DNS check cannot show whether every production sender is aligned, why a receiver handled one message a certain way, or whether phishing-report triage works. ## Choose the next control-specific workstream Use the [email-threats learning hub](/learning/threats) to select the next control or implementation guide after you have assigned owners and recorded the evidence your program needs. A guide cannot assess your organization, run authorized exercises, operate incident response, or prove that controls are effective. ## Sources and further reading - [NIST Technical Note 2276: Phishing](https://csrc.nist.gov/pubs/tn/2276/final) - [CISA Cybersecurity Performance Goals](https://www.cisa.gov/cybersecurity-performance-goals) - [Department of Justice phishing awareness program guidance](https://www.justice.gov/jmd/page/file/1368721/dl?inline=) - [Palisade guide to anti-phishing software](/learning/anti-phishing-software) ## Frequently asked questions ### Is an anti-phishing program just employee training? No. Training is one component. An anti-phishing program also needs preventive controls, a reporting route, triage, incident-response handoffs, accountable owners, and outcome review. ### Who should own an anti-phishing program? The organization should assign one accountable program owner, usually in security or risk, while giving operational control owners clear duties. Messaging, identity, service desk, incident response, HR, legal, and finance may each own parts of the work. ### How often should phishing simulations run? Only according to an approved program plan that defines the purpose, audience, authorization, support plan, and follow-up action. The right cadence depends on the organization’s risk, capacity, and evidence from prior exercises and incidents. ### What metrics should an anti-phishing program track? Track reported-message volume, triage time, incident outcomes, recurring attack patterns, control gaps, and completion of assigned remediation. Exercise results can add evidence, but click rate alone does not measure the whole program. ### Does DMARC stop every phishing attack? No. DMARC helps receivers evaluate mail that uses your visible From domain and fails aligned SPF or DKIM. It does not stop phishing from attacker-controlled domains, compromised accounts, or non-email channels. --- # Anti-phishing software: how to compare business tools Canonical: https://www.palisade.email/learning/anti-phishing-software > Anti phishing software comparison for businesses: evaluate native controls, dedicated email security, DMARC, and sender-domain protection options. Choose anti-phishing software by the attack surface and operating model you need to cover. Native Microsoft 365 controls fit organizations that want protection configured inside their existing suite. Dedicated email-security products fit teams that need a separate email-protection layer. DMARC protects a domain from unauthorized use in the visible From address, but it is not an inbound phishing filter. ## Quick takeaways - Anti-phishing software can protect inbound mail, detect impersonation, inspect suspicious links, or help stop unauthorized use of your sending domain. - A native email suite policy is often the practical starting point when all mailboxes already use that suite. - A dedicated email-security product needs a documented deployment and operational fit, not a claimed detection percentage. - DMARC is a sender-domain authentication control, not software that evaluates every inbound phishing message. - Compare products against the same evidence: recipient scope, deployment path, actions, investigation workflow, and gaps. - Test a shortlisted product with representative mail flow before treating a policy setting or public DNS record as a working protection outcome. ## Who this comparison is for This comparison is for an IT or security team selecting business phishing protection, including teams that use Microsoft 365 and teams considering an additional email-security layer. It also applies to MSPs that need a consistent method for evaluating protection across customer tenants. The first decision is the job. Inbound email protection evaluates messages received by users. Impersonation controls assess suspicious claims about a sender, person, or domain. External brand protection and phishing-site disruption are separate services with different evidence and response paths. Sender-domain controls help recipients authenticate mail that claims to come from your domain. Those jobs overlap, but they are not interchangeable. An [anti-phishing program](/learning/anti-phishing-program) combines controls, procedures, reporting, and user decisions. A product comparison should identify which part of that operating model the product can document and which part still needs another control or process. For a broader framework for recurring DMARC-platform decisions, see [Palisade's DMARC platform comparisons](/compare). ## How the options were evaluated The criteria below were checked against vendor-controlled documentation on August 13, 2026. A documented capability is treated as available only within the scope the vendor describes. Missing documentation is an open question, not evidence that a capability is absent. - Protection job: Is the documented function native anti-phishing policy, dedicated inbound email security, or sender-domain authentication? - Deployment and scope: Does the vendor document where the protection is configured and which users, domains, or mail flow it can target? - Operator action: Does the documentation describe an action such as quarantine, policy targeting, investigation, or a DNS policy? - Evidence to validate: Can the buyer verify the result in the vendor's status or investigation workflow and with a real message from the production path? - Boundary: What does the product category not establish, such as future inbox placement, a receiver's private filtering decision, or every form of phishing? Use the same test design across finalists. Send approved, non-malicious test messages through the exact production route, then inspect the receiving system's result. Confirm DNS through the authoritative provider and a public resolver when sender-domain authentication is in scope. Once message volume accumulates, use DMARC aggregate reports to identify sources that use the domain. ![Decision flow for selecting native email protection, dedicated email security, or DMARC sender-domain controls](/images/editorial/anti-phishing-software/anti-phishing-software-decision-flow.webp "1200x676") *Source: Palisade.* ## Microsoft Defender for Office 365 anti-phishing policies Microsoft Defender for Office 365 fits Microsoft 365 organizations that want anti-phishing controls configured in the Microsoft Defender portal or through Exchange Online PowerShell. Microsoft's documentation states that its anti-phishing policies include anti-spoofing protection and anti-impersonation protection, with a default policy that applies to all recipients and custom policies that can target users, groups, or domains. - Best fit: A Microsoft 365 organization that needs tenant-native anti-phishing policy controls and can operate them within Microsoft Defender for Office 365. - Relevant evidence: [Microsoft's anti-phishing policy documentation](https://learn.microsoft.com/en-us/defender-office-365/anti-phishing-policies-mdo-configure) states that the feature applies to Defender for Office 365 Plan 1 and Plan 2, documents policy targeting, and documents actions including quarantine, junking, redirecting, Bcc delivery, and deletion for specific detections. - Tradeoff: The documented configuration is Microsoft-specific. It does not establish that every phishing technique will be detected, or that a message sent through a different production route received the same treatment. Microsoft documents that policy changes can take up to 30 minutes to apply. It also documents policy precedence for recipients included in Standard or Strict preset security policies. That makes policy assignment and precedence part of the evaluation, not an administrative detail. A useful test sequence is: ```yaml tenant: example Microsoft 365 tenant recipient_group: phishing-pilot@yourdomain.com policy_scope: pilot group only test_message: approved internal test through production route evidence_to_capture: - applied policy or preset-security scope - message trace or quarantine outcome - recipient-visible result - false-positive review decision ``` > Do not widen a policy, add trusted senders, or change message actions based only on a lab result. Test the same mail route and preserve a rollback path before changing protection for all recipients. ## Proofpoint email protection Proofpoint fits organizations evaluating a dedicated email-protection product instead of relying only on suite-native controls. Its product page presents email protection as protection against email-borne threats and directs buyers to its email-security product portfolio. - Best fit: A team that wants to evaluate a dedicated email-security provider and can validate the vendor's deployment design against its inbound mail architecture. - Relevant evidence: [Proofpoint's Email Protection product page](https://www.proofpoint.com/us/products/email-protection) describes its email-security offering and associated threat-protection positioning. The vendor's [Core Email Protection solution brief](https://www.proofpoint.com/sites/default/files/solution-briefs/pfpt-us-sb-core-email-protection.pdf) is relevant for the product scope that Proofpoint publishes. - Tradeoff: The public product materials do not replace a tenant-specific deployment review. Record the exact mail path, licensing scope, administrative workflow, and investigation access required for your environment before deciding. ![Proofpoint email security product overview](/images/editorial/anti-phishing-software/anti-phishing-software-shot-2.png "1454x1137") *Source: [Proofpoint, "Raising the Bar for Detecting and Responding to Email Fraud"](https://www.proofpoint.com/us/blog/email-and-cloud-threats/raising-bar-detecting-and-responding-email-fraud-advanced-bec-defense), checked 2026-08-13. Vendor-published illustrative interface; labels and workflow can change.* A dedicated layer should be tested as a deployed system, not as a feature list. Ask whether the product sees every intended inbound path, how it handles a false positive, who can release or investigate a message, and what evidence the operator can export during an incident. Those answers should come from the vendor's current documentation and a controlled evaluation. ## Cloudflare Area 1 Email Security Cloudflare Area 1 Email Security fits buyers assessing a dedicated email-security service from Cloudflare. Its vendor datasheet describes the service as an email-security offering and is the appropriate source for Cloudflare's own scope statements during an evaluation. - Best fit: A team that wants to assess Cloudflare's dedicated email-security offering against its current inbound-mail design. - Relevant evidence: [Cloudflare's Area 1 Email Security datasheet](https://www.cloudflare.com/static/d40dbf403f1f55a270556c8cef5a086f/Cloudflare_Area_1_Email_Security_Datasheet.pdf) describes the vendor's email-security service and should be checked again for current deployment, packaging, and capability details before procurement. - Tradeoff: A vendor datasheet does not prove that the service covers each route in your environment or that a particular message will be classified the same way in production. Use the same evaluation questions used for any dedicated email-security layer: where traffic enters, which recipients are covered, how the service coexists with existing controls, which operator actions are available, and which message evidence demonstrates the outcome. Do not infer a feature absence where the public material is silent. Put it in the open-question field and resolve it with current vendor documentation or a controlled evaluation. ## DMARC for sender-domain impersonation control DMARC has a different job from inbound anti-phishing software. [RFC 7489](https://www.rfc-editor.org/rfc/rfc7489) defines DMARC as a mechanism for domain owners to publish policy and request reports about messages that use their domain in the RFC 5322 From field. It uses SPF and DKIM authentication with identifier alignment. - Best fit: A domain owner that needs to reduce unauthorized use of its own visible From domain and identify legitimate sending sources before enforcing a DMARC policy. - Relevant evidence: RFC 7489 defines the published DMARC policy and aggregate reporting model. It does not define a complete inbound phishing-detection system for messages that claim to come from unrelated domains. - Tradeoff: A passing DMARC record does not block a phishing message sent from another domain, test an inbound mail filter, prove every future message will authenticate, or guarantee inbox placement. DMARC belongs beside inbound protection because both address impersonation risk, but the validation evidence differs. Validate a DMARC change at four layers: - DNS: Query the authoritative DNS provider and a public resolver for the published record. - Vendor: Confirm that each sending service reports its own authentication setup as verified. - Message: Send mail through each production source and inspect the received message's `Authentication-Results`. - DMARC: Review aggregate reports after data accumulates to identify sources and alignment issues. ## Inspect the sending domain behind an impersonation concern If the concern is that someone can send mail claiming to be your business, inspect the public DMARC record before choosing a sender-domain remediation path. The [DMARC checker](/tools/dmarc) can inspect the published record for a domain and help frame the question for the email-security evaluation. [Check the DMARC record](/tools/dmarc) A public record check cannot test an inbound filter, block a phishing message, prove a vendor's protection efficacy, or show a mailbox provider's private decision about a message. ## How to choose Choose native suite controls when the documented protection scope, administration path, and pilot evidence fit the email platform you already operate. Choose a dedicated email-security product when you need a separate layer and can verify its deployment, operational workflow, and coverage on your actual mail routes. Add DMARC when protecting your visible sending domain is part of the problem. Use this evidence scorecard for every shortlisted option: ```yaml - option: Microsoft Defender for Office 365 anti-phishing policies checked_on: 2026-08-13 best_fit: Microsoft 365 tenant-native anti-phishing controls verified_evidence: Policy targeting and message actions documented by Microsoft open_question: Production results for this tenant's mail routes and policy precedence - option: Proofpoint Email Protection checked_on: 2026-08-13 best_fit: Dedicated email-security evaluation verified_evidence: Email-protection offering documented by Proofpoint open_question: Tenant-specific deployment, coverage, and investigation workflow - option: Cloudflare Area 1 Email Security checked_on: 2026-08-13 best_fit: Dedicated Cloudflare email-security evaluation verified_evidence: Email-security service documented in Cloudflare's datasheet open_question: Current deployment fit and production-path coverage - option: DMARC checked_on: 2026-08-13 best_fit: Protecting the visible From domain from unauthorized use verified_evidence: Policy and reporting model defined by RFC 7489 open_question: Every legitimate production sender's authentication and alignment status ``` ![Buyer checklist for validating anti-phishing software against the actual mail path, operator workflow, and sender-domain boundary](/images/editorial/anti-phishing-software/anti-phishing-software-trial-checklist.webp "1200x524") *Source: Palisade.* Keep malware prevention in a separate workstream. Email phishing can carry malware, but a phishing-control decision does not replace endpoint protection, incident response, or browser security. ## Sources and further reading - [Microsoft Defender for Office 365 anti-phishing policy configuration](https://learn.microsoft.com/en-us/defender-office-365/anti-phishing-policies-mdo-configure) - [Proofpoint Email Protection](https://www.proofpoint.com/us/products/email-protection) - [Cloudflare Area 1 Email Security datasheet](https://www.cloudflare.com/static/d40dbf403f1f55a270556c8cef5a086f/Cloudflare_Area_1_Email_Security_Datasheet.pdf) - [RFC 7489: Domain-based Message Authentication, Reporting, and Conformance](https://www.rfc-editor.org/rfc/rfc7489) ## Frequently asked questions ### Is DMARC anti-phishing software? No. DMARC is a sender-domain authentication policy and reporting mechanism. It helps receivers evaluate mail that uses your visible From domain, but it does not inspect or block every inbound phishing message. ### Should a Microsoft 365 business start with native anti-phishing controls? Yes, when Microsoft 365 is the production email platform and the documented Defender policy scope fits the required recipients and mail routes. Validate the result with a pilot group, policy-precedence review, and real messages from the production path. ### Can dedicated email security replace DMARC? No. Dedicated email security can address inbound-message protection, while DMARC helps protect a domain from unauthorized use in the visible From address. A business may need both controls because they answer different questions. ### Does a public DMARC check prove phishing protection is working? No. A public DMARC check can show the record currently published for a domain. It cannot test an inbound filter, establish vendor detection performance, or prove how a mailbox provider will treat a particular message. ### What evidence should an MSP collect before recommending a phishing tool? Collect the current mail architecture, affected domains and recipient groups, documented vendor scope, the intended action for suspicious messages, pilot results from the real mail path, false-positive handling, and the rollback procedure. Keep unknown deployment or coverage details as open questions until the vendor documents or demonstrates them. --- # BIMI logo checker: check and interpret your BIMI record Canonical: https://www.palisade.email/learning/bimi-logo-checker > BIMI logo checker guide: check a domain's BIMI record, interpret Palisade results, repair DMARC enforcement or record issues, and retest now. A BIMI logo checker checks the BIMI configuration published for a domain. Enter the sending domain in the [Palisade BIMI Checker](/tools/bimi), then use the result to separate a missing BIMI DNS record from a certificate, logo, or DMARC-enforcement issue. The result is useful public evidence, but it cannot prove that a mailbox provider will display a logo for every future message. ## Quick takeaways - Palisade's BIMI Checker accepts a domain, not an uploaded logo file or SVG URL. - BIMI policy is normally published as a DNS TXT record at `default._bimi.yourdomain.com`. - A BIMI `l=` tag points to the brand indicator file over HTTPS. - BIMI participation requires DMARC enforcement: `p=quarantine` or `p=reject`. RFC 9989 retired [`pct`](/learning/glossary/dmarc-pct), so a current record omits it, but a legacy record publishing `pct` below 100 fails BIMI. - A BIMI record can exist while its logo or VMC certificate still needs attention. If the logo itself fails validation, see [Getting your logo BIMI-ready](#getting-your-logo-bimi-ready). - A public check does not prove the production sending path, delivered-message authentication result, continuous state, or a provider's private display decision. ## What this tool checks The [Palisade BIMI Checker](/tools/bimi) is a domain-level check for "Brand Display and Verified Checkmark (BIMI)." It normalizes a submitted domain, queries the public BIMI configuration, and can fetch and validate the referenced logo and certificate chain. It does not accept a logo file, SVG markup, or a standalone logo URL. BIMI belongs in the broader set of [sender-domain infrastructure controls](/learning/infrastructure) that depend on DNS and message authentication. The checker can return a public configuration result with a `pass`, `warn`, or `fail` status. Its defined result headlines are: - "Brand display and verified checkmark (BIMI) are certified" - "Brand display and verified checkmark (BIMI) are missing" - "Brand display and verified checkmark (BIMI) failed" - "Brand display and verified checkmark (BIMI) requirements are not met" - "Brand display and verified checkmark (BIMI) are not certified" - "VMC certificate expired" The checker can show the BIMI record, the `l=` logo location, the `a=` VMC location, and, when a logo URL is available, the certificate-validity date. A successful public result can also confirm that the logo was fetched and valid, the VMC chain was trusted, the logo matched the certificate, and the certificate covered the domain. That is still bounded evidence. The logo-validation response does not identify the exact SVG profile rule that failed. It also cannot prove that the application which sends production mail is using the intended From domain, that a receiver authenticated a delivered message, or that a particular provider will render the logo or verified checkmark. ![Palisade BIMI checker product overview](/images/editorial/bimi-logo-checker/bimi-logo-checker-shot-1.webp "1600x900") *Source: Palisade.* ## How to run the check ### 1. Start with the visible From domain Use the domain after `@` in the address recipients see in the From header. If different teams or systems send from different visible domains, check each domain separately. BIMI and DMARC decisions are tied to domains, so a parent company name or a sending platform hostname is not a substitute for the actual From domain. ### 2. Run the BIMI check Open the [Palisade BIMI Checker](/tools/bimi) and submit the domain. The checker accepts a domain even if you paste a URL or email address because it normalizes the value before scanning. Use the final domain value as your test record. You can independently query the public BIMI policy owner with this illustrative lookup: ```bash dig +short TXT default._bimi.yourdomain.com ``` The BIMI Internet-Draft specifies that domain-owner preferences are DNS TXT records beneath `_bimi`, with the default selector published at `default._bimi.example.com`. This is a public lookup only. It does not test a sent email. ![BIMI record components used by a domain-level checker](/images/editorial/bimi-logo-checker/bimi-logo-checker-records.webp "1200x533") *Source: Palisade.* ### 3. Preserve the result before changing DNS Copy the displayed headline, status, returned BIMI record, and technical-detail errors into the change ticket. If the card says "No BIMI record found," capture that fact with the domain and time of the lookup. If it displays `l=` and `a=`, retain those URLs as evidence without copying another organization's values into your own DNS. > Do not replace a BIMI record with an example from another domain. The logo URL, certificate URL, and certificate-domain relationship are account-specific. ## How to interpret the results ### Brand display and verified checkmark (BIMI) are certified This is the checker’s passing headline. A live check of `palisade.email` returned a BIMI record with both `l=` and `a=` values, a fetched valid logo, and a complete trusted VMC chain where the logo matched the certificate and the certificate covered the domain. Treat this as a strong public configuration result. Send a real message through the same production source and inspect its authentication evidence before claiming the full path is ready. [Email authentication](/learning) controls still determine whether the message can meet DMARC requirements. ### Brand display and verified checkmark (BIMI) are missing This is the headline for a missing BIMI record. Live checks of `google.com` and `example.com` returned this state, with no BIMI value, location, or assertion and the `bimi-no-record` error. Confirm the exact From domain first. Then query `default._bimi.yourdomain.com` directly and compare the result with the authoritative DNS zone. The checker’s technical guidance for this error says: "Create a BIMI record with a valid, trademarked SVG (version 1.2) logo and a VMC to display your logo in your client’s inbox and increase your brand’s visibility." The public result establishes that no BIMI record was found in that run. It does not establish why the record is absent or whether a DNS change has been approved. ### Brand display and verified checkmark (BIMI) failed This headline maps to the `bimi-invalid` state. It means the checker identified a BIMI configuration but did not validate it as required for a passing result. Review the raw record, `l=` value, `a=` value, and the technical details before changing anything. The BIMI Internet-Draft requires an `l=` tag containing one HTTPS URI for the Brand Indicator file. It marks the `a=` certificate URI optional. Keep that protocol rule separate from display expectations. An `a=` value can be absent under the draft, while the checker may present a self-assertion warning about the absence of a VMC. ### Brand display and verified checkmark (BIMI) requirements are not met This headline maps to `bimi-requirements-not-met`. One defined assessment is `bimi-requires-dmarc-enforcement`: "BIMI record requires DMARC enforcement. This means DMARC must have a reject (any pct value) or quarantine (pct=100%) policy." Repair DMARC enforcement before treating logo or certificate work as the next protocol threshold. The current BIMI Internet-Draft requires a strong DMARC policy on the organizational domain and the message's RFC5322.From domain. It says BIMI processing MUST NOT occur when either relevant DMARC policy is `p=none`. [RFC 9989's DMARC policy definition](https://www.rfc-editor.org/rfc/rfc9989.html) defines the available `p=` values as `none`, `quarantine`, and `reject`. ### Brand display and verified checkmark (BIMI) are not certified This headline maps to `bimi-uncertified`. The BIMI record may be present, but the result does not establish certification. Inspect whether the output provides a logo value without an `a=` value or identifies a certificate-related condition. Do not infer which mailbox providers will display a logo from this state alone because provider display behavior is outside the evidence returned by a public configuration check. ### VMC certificate expired This headline maps to `bimi-vmc-expired`. Check the VMC URL shown as `a=` and the date presented by the checker. A certificate replacement must be generated and approved through the responsible certificate and DNS workflow. Recheck the public record after the replacement is published, then validate an actual message path separately. ## How to act on the result Start with the earliest failed prerequisite shown by the evidence. - For a missing record, confirm the visible From domain, inspect `default._bimi.yourdomain.com`, and obtain the domain-specific record values from the organization responsible for the logo and certificate. - For an enforcement requirement, repair DMARC policy only after reviewing aggregate-report evidence and the sending sources that would be affected. DMARC enforcement can change delivery outcomes for unauthenticated mail. - For a logo validation issue, review the actual file at `l=`. [RFC 6170's certificate-image profile](https://www.rfc-editor.org/rfc/rfc6170.html) requires SVG Tiny 1.2 behavior, prohibits `script` elements, and prohibits external IRI references to information outside the image for specified content types. The checker may report that a logo is invalid without identifying the particular failed rule. - For a certificate condition, use the VMC owner’s current process to examine the `a=` resource and the domain relationship. Do not copy a certificate-chain URL from another tenant. - For a passing result, proceed to a delivered-message check and later aggregate-report review. A valid DNS and HTTPS configuration does not prove that every sender using the domain authenticates correctly. If the work is specifically about preparing an eligible SVG and its trademark relationship, use [the logo and trademark guidance below](#getting-your-logo-bimi-ready). For protocol context before a change, see [what BIMI is and how its record works](/learning/what-is-bimi). ## Getting your logo BIMI-ready A failed logo validation usually traces back to the file itself. BIMI accepts only a constrained SVG profile, and most exported logos need conversion, a trademark decision, and a stable hosting location before the record can pass. ### Convert the logo to SVG Tiny P/S BIMI requires SVG Tiny 1.2 restricted to the Portable/Secure profile. The root `` element must declare `baseProfile="tiny-ps"` and `version="1.2"`. The file must be square with a solid, opaque background, contain no scripts, hyperlinks, external references, or animation, include a `` element describing the logo, and stay small, well under 32 KB. Three conversion routes work: - [Palisade's BIMI SVG converter](/tools/bimi-svg-converter) converts an uploaded logo to the Tiny P/S profile directly. - In Adobe Illustrator, or the free Inkscape, convert text to outlines, center the mark on a square artboard with padding, add a solid background rectangle, and save as SVG using the SVG Tiny 1.2 profile. Then open the file in a text editor, remove metadata and any scripts or external references, add the `` element, and set `baseProfile` to `tiny-ps`. - Other web-based converters can transform simple logos directly in the browser, but they can mishandle gradients, fine detail, or text. Inspect the result and clean it up in a vector editor if needed. The BIMI Group also publishes [conversion tools](https://bimigroup.org/svg-conversion-tools-released/) for turning an SVG 1.2 file into the P/S profile. ![Five steps to convert a logo to SVG in Adobe Illustrator, from opening the file to saving as SVG.](/images/figures/how-to-convert-your-company-logo-to-svg-understanding-sv-fig1.webp "1200x800") *Source: Palisade.* ### Meet the trademark requirement A VMC is issued only against a registered trademark. Check the [WIPO Global Brand Database](https://www.wipo.int/branddb/en/) to confirm whether the logo is already registered, and search for conflicting marks before filing. Submit the application through the trademark office of your country, and confirm that country is recognized by the major VMC issuers before applying. Expect real cost and lead time. US filing runs $350 per class of goods or services since January 2025, roughly £200 in the UK, and about $250 AUD in Australia, with separate fees for each class. Registration typically takes roughly 12 months or more in the US, around 4 months in the UK, 5 to 6 months in the EU, and up to 18 to 24 months in India. Respond promptly if the trademark office contacts you, or the application can be abandoned. ### VMC or CMC? A Verified Mark Certificate requires the registered trademark and adds Gmail's blue verified checkmark beside the logo. Since September 2024, Gmail also accepts a Common Mark Certificate, which displays the logo without the checkmark and requires proof that the logo has been in public use for at least 12 months instead of a trademark. Choose based on whether you own a registered trademark and whether the checkmark matters to you. ### Host the file Host the finished SVG at a public HTTPS URL you control. A path on your own domain or CDN is ideal, so the file cannot be changed out from under you. The record's `l=` tag points to that URL, and `a=` points to the certificate. ### Common logo failures - The SVG validates in a browser but fails BIMI: a browser renders full SVG, while BIMI accepts only the Tiny P/S profile. The usual culprits are a missing `baseProfile="tiny-ps"`, a transparent background, an embedded raster image, or a stray script or hyperlink. - The converted file looks blurry or jagged: the converter embedded the raster image inside an SVG wrapper instead of tracing it into vector paths. Re-trace the logo with Illustrator's Image Trace or Inkscape's Trace Bitmap. - The file is far larger than expected: automated tracers can generate thousands of unnecessary anchor points. Simplify paths and remove hidden or off-canvas elements before exporting. - Text renders wrong on other systems: a missing font gets substituted. Convert text to outlines so the letterforms travel with the file as shapes. - The logo appears cropped or off-center: providers crop BIMI logos to a circle. Center the mark on a square canvas with even padding on all sides. - The logo stopped showing after it worked: certificates are typically valid for one year. When the certificate at `a=` lapses, the logo stops displaying, so set a renewal reminder well before expiry. ![Checklist of the requirements a BIMI SVG logo must meet before it is uploaded.](/images/figures/how-to-make-your-company-logo-bimi-compatible-fig2.webp "1200x639") *Source: Palisade.* ## How to retest Run the same domain through the BIMI Checker after the authoritative DNS answer and referenced HTTPS resources have changed. The expected result depends on the repair: - A missing record should change from "Brand display and verified checkmark (BIMI) are missing" to a result that shows the published record. - A corrected logo should produce a successful logo fetch and validation if the file meets the required profile. - A corrected certificate should update the displayed VMC validity information when the checker can validate the chain. - A DMARC repair should remove the enforcement prerequisite only after the relevant domains publish a qualifying policy. Then send a new message through the exact application, sender identity, gateway, and recipient path that matters. Inspect the delivered message's authentication results, and use DMARC aggregate reports once they have accumulated. Public DNS and certificate checks cannot replace either layer. ## Check the BIMI record before changing the logo If the evidence points to a missing record, expired VMC, or failed public validation, run the domain through the BIMI Checker and compare the returned `l=` and `a=` values with the approved domain configuration. [Check the BIMI domain configuration](/tools/bimi) The check can inspect public BIMI DNS, the referenced logo, and certificate-chain evidence. It does not repair DNS, identify every SVG-profile violation, monitor future changes, prove the production sending path, or guarantee inbox logo display. ## Sources and further reading - [Palisade BIMI Checker](/tools/bimi) - [Brand Indicators for Message Identification, draft-14](https://datatracker.ietf.org/doc/draft-brand-indicators-for-message-identification/) - [BIMI Internet-Draft text, sections 4.3 and 7.1](https://www.ietf.org/archive/id/draft-brand-indicators-for-message-identification-14.txt) - [RFC 6170: Internet X.509 Public Key Infrastructure - Certificate Image](https://www.rfc-editor.org/rfc/rfc6170.html) - [RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance](https://www.rfc-editor.org/rfc/rfc9989.html) ## Frequently asked questions ### Does a BIMI logo checker accept an SVG file? No. The Palisade BIMI Checker accepts a domain and checks the public BIMI configuration associated with that domain. It can fetch the logo referenced by the record, but it does not provide a logo-file upload or SVG paste field. ### Is a VMC required in every BIMI record? No. The current BIMI Internet-Draft marks the `a=` certificate URI as optional. The `l=` URI for the Brand Indicator file is required. A missing VMC can still affect the checker’s certification result and any provider-specific display outcome. ### Does BIMI require DMARC enforcement? Yes. The BIMI Internet-Draft requires a strong DMARC policy, either `p=quarantine` with `pct=100` or `p=reject`, on the organizational domain and the message's RFC5322.From domain. BIMI processing MUST NOT occur if the relevant policy is `p=none`. [RFC 9989 has since retired `pct`](/learning/what-is-dmarcbis-rfc-9989-dmarc-standard) from DMARC, so a current record simply omits the tag; the `pct=100` condition only bites on legacy records that still publish a lower value. ### Can a valid BIMI result prove my logo will appear in every inbox? No. A valid result proves public configuration evidence such as the BIMI record, logo fetch, and certificate validation where available. It cannot prove a mailbox provider's private display decision, the production sending path, or future message authentication. ### Where is the BIMI DNS record published? The default BIMI record is published as a TXT record at `default._bimi.yourdomain.com`. The domain-specific record must contain the correct values generated for that domain's logo and certificate arrangement. --- # Bounce email address: what it is and how to find it Canonical: https://www.palisade.email/learning/bounce-email-address > Bounce email address explained: identify the envelope return path, read delivery-status evidence, repair the confirmed cause, and retest the same route. A bounce email address is usually the sender address used for delivery failures, rather than the address visible in the message's From field. Start with the complete SMTP response or delivery-status notification, then identify the envelope return path and the system that owns it. Repair the specific failure shown in that evidence and resend through the same production path. ## Quick takeaways - A visible From address and a bounce email address can be different addresses. - The SMTP envelope reverse path is the return address for delivery failures in SMTP. - A delivery-status notification can identify the failed recipient, action, status, and diagnostic code. - A bounce does not by itself prove a DNS, authentication, mailbox, or reputation problem. - Do not create or change a bounce address until the sending platform and the observed failure are known. - Retest with a new message sent through the same application and outbound route. ## What does the failure mean? In SMTP, the `MAIL FROM` command supplies the envelope reverse path. [RFC 5321 defines the reverse path as the address used when the receiving SMTP server needs to report delivery errors](https://datatracker.ietf.org/doc/html/rfc5321#section-4.5.5). Many sending platforms call that address a bounce address, return path, envelope sender, or MAIL FROM address. A delivery-status notification, or DSN, is separate from the original message. [RFC 3464 defines DSN fields including `Final-Recipient`, `Action`, `Status`, and `Diagnostic-Code`](https://datatracker.ietf.org/doc/html/rfc3464#section-2.3). The recipient's SMTP reply and the DSN identify the actual failure. The bounce address identifies where a failure report can be sent. This is the evidence shape to preserve from a delivery-status notification: ```text Final-Recipient: rfc822; recipient@yourdomain.com Action: failed Status: 5.1.1 Diagnostic-Code: smtp; <recipient@yourdomain.com> ... User unknown ``` The address after `Final-Recipient` is the recipient that failed. The bounce email address may appear in the original message's envelope data or its delivered `Return-Path` field. Do not assume the visible From address is the address that receives the notification. [SMTP enhanced status codes classify the status value by class, subject, and detail](https://datatracker.ietf.org/doc/html/rfc3463). A `5.x.x` result indicates a permanent failure for that transaction, but the exact `x.x` values and diagnostic text are what narrow the cause. Preserve the entire response before changing DNS, authentication, or the recipient list. ![Diagnostic flow showing how to identify the SMTP response, map the envelope return path to its owner, apply a narrow repair, and repeat the same sending path](/images/editorial/bounce-email-address/bounce-email-address-diagnostic-flow.webp "1200x829") *Source: Palisade.* Use this checklist to keep the return path, recipient, and response evidence separate before changing a configuration. ![Checklist for diagnosing a bounce email address by preserving evidence, identifying the return path, classifying the failure, and validating the repair](/images/editorial/bounce-email-address/bounce-email-address-diagnostic-checklist.webp "1200x582") *Source: Palisade.* ## What usually causes it? ### The bounce email address was confused with the visible From address This is common when an operator searches message headers only for the address shown to the recipient. SMTP treats the reverse path and message header addresses as different fields with different purposes. Inspect the transaction evidence, `Return-Path` on the delivered copy when present, and the sending platform's configured envelope-sender setting. This distinction does not prove that either address caused the failure. It identifies which owner and configuration path should receive investigation. ### The recipient address or mailbox is invalid A DSN with recipient-specific evidence, such as a `5.1.1` status and an "User unknown" diagnostic, points first to the recipient address or mailbox. [RFC 3463 defines the `5.1.1` enhanced status code as a bad destination mailbox address](https://datatracker.ietf.org/doc/html/rfc3463#section-3.2). Remove or correct the confirmed invalid recipient in the sender's approved contact process. Do not alter the bounce address to work around a recipient failure. ### The recipient domain cannot accept mail A failure can concern the recipient domain's mail routing rather than the bounce email address. The receiving system's diagnostic text and status code determine that branch. A public MX lookup can inspect published routing records, but it cannot prove that a recipient mailbox exists or explain a private receiver decision. For a recipient-domain routing failure, use the broader [delivery errors guide](/learning/delivery-errors) to keep DNS evidence separate from mailbox and receiver-policy evidence. ### The sending platform has an incorrect envelope-sender configuration This is an inference when the original message has an unexpected reverse path, a platform-generated bounce mailbox, or a DSN cannot be returned to the intended owner. The exact setup and repair are provider-specific. A CRM, ESP, or MTA may generate the envelope sender automatically, require a verified domain, or use a provider-managed return path. Use the sending platform's current documentation for the exact configuration path. Do not copy another tenant's selector, CNAME target, token, or bounce-domain value into DNS. ### Authentication evidence is being treated as the bounce cause SPF, DKIM, and DMARC results can matter to a receiver's handling, but a bounce notice alone does not establish an authentication failure. Inspect trusted receiver-added `Authentication-Results` from the affected message. [RFC 8601 defines this header field and its authentication result methods](https://www.rfc-editor.org/rfc/rfc8601.html). A passing authentication result does not guarantee delivery or inbox placement. A failing result requires message-path and domain evidence before it supports a repair. ## How do I diagnose the failure? ### 1. Preserve the full SMTP response or delivery-status notification Save the raw DSN or the sending platform's complete delivery event. Record the recipient, timestamp, sending application, outbound route, SMTP reply, enhanced status code, and diagnostic text. Keep the original in access-controlled incident records. Redact recipient addresses and message content before sharing the evidence in tickets. A shortened dashboard label can hide the response that distinguishes an invalid recipient from a routing or policy failure. ### 2. Identify the envelope return path Locate the `MAIL FROM` value in sending logs where available. In a delivered message, inspect `Return-Path` as supporting evidence. Map that address or domain to the team and platform that control it. Do not rely on a user-facing From address. It may be a different domain or mailbox. ```text Visible From: updates@yourdomain.com Envelope reverse path: bounces@bounce.yourdomain.com Failed recipient: recipient@example.net ``` This is illustrative only. Use addresses from the actual failed path, and do not publish customer addresses or platform-generated identifiers. ### 3. Classify the failure from the recipient's evidence Read the exact SMTP status and diagnostic code before opening DNS records or changing authentication. A recipient-specific permanent failure needs recipient-list remediation. A routing-related failure needs recipient-domain DNS evidence. An authentication-related response needs the corresponding header and DNS evidence. If the message has a specific receiver response, the [bounce-back email guide](/learning/bounce-back-email) can help distinguish a notification from the system that generated it. ### 4. Confirm the owner of the sending path Identify which application created the message, which service submitted it, and which MTA or ESP delivered it. Then determine whether that path is expected to use the observed bounce address. A provider-managed bounce mailbox may be correct even when it differs from the branded From address. Treat an unexpected address as a configuration lead, not proof of a fault. ### 5. Check only the DNS or authentication evidence relevant to the response If the evidence identifies a sending-domain authentication issue, inspect the published domain records and compare them with the received message headers. If the evidence identifies recipient-domain routing, inspect the recipient domain's MX records. Do not use a public DNS result as proof of a mailbox, a production sending route, continuous state, a receiver's private decision, or future placement. For the difference between a delivery failure and wider inbox outcomes, see [what email deliverability means](/email-deliverability). ## How do I fix it? ### Correct the confirmed recipient data When the DSN identifies an invalid recipient or mailbox, correct the address at its approved source or suppress it from future sends. This repair changes recipient data. It does not change authentication, alignment, reporting, or DMARC enforcement. > Do not resend repeatedly to a recipient after a permanent failure without correcting the confirmed cause. Repeated attempts can obscure the incident record and create unnecessary traffic. ### Restore the intended envelope-sender configuration When the sending platform's documentation and logs show that the wrong bounce address is configured, restore the expected provider-supported setting. Confirm that the address or domain is controlled by the responsible team and that failure notifications can be received and reviewed. This repair changes the sending configuration. It does not establish why a specific recipient server rejected the original message. ### Repair the confirmed authentication or routing condition If the exact response and message evidence identify authentication failure, repair the affected SPF, DKIM, or DMARC configuration through the owner of that sending path. If the evidence identifies recipient-domain routing, repair only the published routing condition that the recipient domain owner controls. Do not loosen the DMARC policy as a bounce-address fix. A `p=` change changes requested DMARC enforcement. It does not correct an invalid recipient, restore an envelope sender, or repair a documented SMTP failure. ### Escalate an unpublished receiver decision with complete evidence When the receiver gives only a generic or unpublished rejection, provide its support channel with the complete SMTP response, timestamp, sending IP where appropriate, message identifiers, and redacted raw headers. Do not claim an internal receiver decision has a known DNS or reputation cause without documentation from that receiver. ## How do I validate the repair? Send a new message through the same application, sender identity, outbound service, and recipient path that produced the failure. Confirm the sending platform records the expected envelope reverse path and that any resulting DSN reaches the intended operational mailbox. Validate each applicable layer: - Check the authoritative DNS record and at least one public resolver when the repair changed DNS. - Confirm the sender platform shows the current verified or authenticated state when its configuration changed. - Inspect a newly delivered message's trusted `Authentication-Results` when authentication is part of the failure. - Review DMARC aggregate reports after data accumulates to identify whether the same production source is aligned. A successful test to one recipient does not guarantee delivery to all receivers. Keep the new SMTP response, raw message evidence, and change record together. ## Inspect the domain evidence behind the bounce path After the SMTP response identifies a possible authentication or DNS branch, inspect the sending domain's published security posture before changing records. [Check the email security score](/tools/email-security-score) A public score can inspect published domain evidence. It cannot read a delivery-status notification, confirm that a recipient mailbox exists, prove the production sending path, or explain one receiver's private rejection decision. If recurring delivery failures expose unknown senders or alignment issues across several domains, [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=delivery_errors&utm_content=bounce-email-address). [Palisade's documented DMARC Agent workflow](https://docs.palisade.email/guides/fixing-authentication-issues/) analyzes DMARC aggregate-report data, identifies sending sources and authentication or alignment issues, and creates prioritized remediation tickets. It does not repair a recipient mailbox, change a receiver's decision, or guarantee delivery. ## Sources and further reading - [RFC 5321 section 4.5.5: SMTP reverse path](https://datatracker.ietf.org/doc/html/rfc5321#section-4.5.5) - [RFC 3464: Delivery status notifications](https://datatracker.ietf.org/doc/html/rfc3464) - [RFC 3463: Enhanced mail system status codes](https://datatracker.ietf.org/doc/html/rfc3463) - [RFC 8601: Authentication-Results header field](https://www.rfc-editor.org/rfc/rfc8601.html) - [Palisade email security score](/tools/email-security-score) ## Frequently asked questions ### What is bounce email address? A bounce email address is usually the SMTP envelope reverse path used to receive delivery failures. It can differ from the visible From address. Confirm the actual address from sending logs, the delivered message's `Return-Path` when available, or the sending platform's configuration. ### How to create a bounce email? Only create or configure a bounce email address through the documentation for the specific ESP, CRM, or MTA that sends the message. The correct setting, verification method, and DNS requirements are provider-specific. Start by identifying the platform that owns the envelope reverse path. ### What is the most hacked email provider? No authoritative, stable ranking identifies one email provider as "the most hacked." Security incidents, account compromise reports, and provider populations change over time. This question also does not identify the SMTP evidence needed to diagnose a bounce email address. ### What is bounce back email? A bounce-back email is a delivery failure notification, often a DSN, sent after an SMTP delivery problem. It should contain recipient and status evidence that helps identify the cause. A bounce email address is the return-path address that can receive that notification. ### Does a bounce email address prove why a message failed? No. The bounce email address identifies the return path for delivery failures. The complete SMTP response, DSN fields, message headers, and the sending path identify the actual failure branch. ### Can changing DMARC fix a bounce email address problem? No. Changing the DMARC policy changes requested enforcement. It does not correct an invalid recipient address, configure an envelope sender, or resolve an SMTP routing failure. --- # Brevo email warmup Canonical: https://www.palisade.email/learning/brevo-email-warmup > Brevo email warmup is not documented as a native Brevo feature in the available help material. Check domain authentication before changing sending. Brevo email warmup does not have a documented native feature, schedule, or sending procedure in the available Brevo help material. Brevo does document domain authentication, including an article titled [“Authenticate your domain with Brevo (Brevo code, DKIM, DMARC)”](https://help.brevo.com). Before changing sending practices, confirm that the sending domain's authentication setup is complete and test the production mail path. ## Quick takeaways - The available Brevo documentation confirms domain-authentication guidance, not a Brevo-specific warmup workflow. - No documented Brevo sending-volume schedule or daily threshold is available here. - Domain authentication and sending practices are separate checks. - A published DNS record does not prove that Brevo is using it for a delivered message. - A mailbox provider's inbox or spam decision is private to that provider. - Do not rely on generic warmup advice as proof that a Brevo account is configured correctly. ## What Brevo email warmup can mean "Email warmup" usually describes a sending-practice question: whether a sender should change message volume or cadence before using a mailbox. That description alone does not establish that Brevo provides a warmup product, recommends a specific sequence, or applies a particular account limit. The available Brevo help-center material identifies Deliverability as a help category and lists [Brevo's domain-authentication article](https://help.brevo.com) covering Brevo code, DKIM, and DMARC. It does not establish a Brevo-specific warmup procedure. Treat any volume plan, timing recommendation, or tool comparison that is not documented by Brevo as unverified. Authentication is still relevant because it identifies whether a message has evidence that the sender is authorized to use the visible domain. For a broader explanation of the signals that affect mail delivery, see [email deliverability](/email-deliverability). Authentication can support delivery, but it does not guarantee inbox placement. Brevo setup should also be considered in the context of the wider [ESP setup guidance](/learning/esp-setup). A sender can have valid DNS records while the application is not yet signing with the expected domain or using the intended return path. ## When the answer changes The answer changes only when Brevo publishes current documentation that addresses the exact question, such as a native feature, a documented sending-practice recommendation, an account-status rule, or a provider-specific path in the Brevo interface. Use this decision rule: - If Brevo documentation names a warmup feature or procedure, follow that current Brevo documentation and preserve the stated limits and conditions. - If you only have DNS records, verify the records before treating them as a configuration result. - If you have a delivered production message, inspect its raw headers and authentication results for evidence from the actual sending path. - If you have access to Brevo account status or delivery reporting, use Brevo's own view to investigate its account-specific information. - If you do not have current Brevo documentation or production evidence, do not infer a sending schedule from another provider's product or from a public DNS lookup. The relevant authentication question is often SPF alignment. [Brevo SPF alignment](/learning/brevo-spf-alignment) covers that narrower issue. SPF alignment is not the same as evidence that a mailbox provider will accept, place, or engage with future mail. ## A practical evidence check before changing sending practices Start by separating the evidence you have from the conclusion it can support. ```text Illustrative evidence record only Visible From domain: updates.yourdomain.com Published DNS evidence: DKIM and DMARC records found Delivered-message evidence: Authentication-Results header from a real message Brevo evidence: Current account status or documented configuration result DMARC evidence: Aggregate-report data after messages have been sent ``` > Do not publish account-generated DNS values, selectors, CNAME targets, tokens, or unredacted message headers. Copy the values from Brevo's current domain-authentication instructions for your own account. A DNS lookup can show what is publicly published. It cannot confirm that Brevo used the expected signing identity for a message. A Brevo status indicator can show a vendor-side configuration result, but it is not a delivered-message check. A delivered message can provide message-level evidence, while DMARC aggregate reports can later show authenticated traffic patterns after reporting data accumulates. ![Flow showing the evidence needed before treating a Brevo sending-practice change as validated](/images/editorial/brevo-email-warmup/brevo-email-warmup-evidence-flow.webp "1200x829") *Source: Palisade.* Use the four layers in order: - DNS: query the authoritative DNS source and at least one public resolver for the records Brevo instructs you to publish. - Vendor: confirm the current authentication or verification result in Brevo, using the vendor's documented path. - Message: send a real message through the exact production path and inspect its raw headers, including authentication results. - DMARC: review aggregate-report data after it accumulates to identify sources and alignment outcomes. This process does not establish that email warmup works. It establishes whether the authentication and sending path have evidence behind them. ## What to do next with the evidence you have If you are still setting up Brevo, begin with Brevo's current domain-authentication instructions. Record the DNS values generated for your own account, then validate them at the DNS, vendor, message, and DMARC layers. If you already send through Brevo, collect a delivered test message from the production path. Check the visible From domain, return-path identity, DKIM signing domain, and `Authentication-Results` header. Do not use an unredacted header in a public ticket or document. If your question is whether a third-party warmup service is the best option, there is no independent primary comparison available here to support a recommendation. If your question is whether warmup improves inbox placement, do not treat a vendor claim as proof of a general result. For adjacent questions about the concept itself, see [Does email warmup work?](/learning/does-email-warmup-work) and [Apollo email warmup](/learning/apollo-email-warmup). Those articles address their own scopes and do not establish Brevo-specific configuration behavior. ## Check the sending domain's security posture Before changing Brevo sending practices, inspect the sending domain's public email-security posture and compare the result with a real message from the Brevo production path. [Check the email security score](/tools/email-security-score) A public check cannot prove that Brevo is using the expected configuration, repair a sender, monitor future changes, or guarantee a mailbox provider's delivery decision. If you need ongoing DMARC-report analysis across sending sources, [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=warmup_sending_practices&utm_content=brevo-email-warmup). Palisade analyzes DMARC aggregate-report data, identifies sending sources and authentication or alignment issues, and proposes prioritized remediation work for human review. It does not change DMARC policy or guarantee delivery. ## Sources and further reading - [Brevo Help Center](https://help.brevo.com) - [Brevo domain-authentication help article listing](https://help.brevo.com) - [Palisade Email Security Score](/tools/email-security-score) ## Frequently asked questions ### What is the best email warm up tool? No independent comparison ranks warmup tools, so no name can be given as the best one. Judge a tool against your provider's current documentation, your own sending requirements, and evidence from your authenticated production mail path. Brevo's help center does not document a warmup feature of its own, so any tool you add sits outside Brevo's documented setup. ### Is email blasting illegal? It depends on where you send from, who you send to, the type of message, and the consent you hold. This page does not give legal advice and cannot rule on your situation. Check the laws that apply to your sending and take advice on them before you run a large campaign. ### How do I warm up my email address? Complete Brevo's documented domain-authentication setup for the sending domain first, because a change in volume does nothing if the domain is not authenticated. Brevo's help center does not publish a warmup schedule, so there is no Brevo-specific ramp to copy. Validate the DNS records, the Brevo status view, a real delivered message, and later DMARC aggregate reports before you change how much you send. ### Does email warmup actually work? Brevo, the mailbox providers, and the standards bodies do not publish evidence that warmup produces a general inbox-placement result, so treat a vendor's claim as marketing rather than proof. Authentication checks can verify parts of your sending setup. They do not prove future delivery either. --- # Bulk DMARC checker Canonical: https://www.palisade.email/learning/bulk-dmarc-checker > Bulk DMARC checker workflow: check domain records in batches, sort DMARC and SPF findings, investigate failures, and retest DNS changes now. A bulk DMARC checker helps you collect public DMARC and SPF record information for many domains, then sort the list into domains that need investigation first. Treat the batch as DNS inventory, not proof that every production sender authenticates or that a mailbox provider will accept a message. Confirm material findings with the exact DNS record, delivered-message headers, and DMARC aggregate reports. ## Quick takeaways - A bulk DMARC check can compare public DMARC, SPF, and policy fields across a domain list. - Record presence is not the same as a working production sending path. - Sort domains by missing or unclear DMARC and SPF results before changing records. - A published DMARC policy does not show which sending services are authorized. - Retest the same domains after DNS changes, then validate a real delivered message. - DMARC aggregate reports provide evidence about sources after mail has been sent. ## What this tool checks A bulk checker accepts a list of domains and returns public DNS information in a result set. The [dmarc.cc bulk checker](https://dmarc.cc) displays fields labelled "Domain", "DMARC", "SPF", and "Policy". Its results are limited to the first 50 domains submitted in a list. The site also states: "Verify your email to scan up to 200 at once." The [DMARC Generator bulk checker](https://dmarcgenerator.com) similarly describes its feature as checking DMARC and SPF records for dozens of domains and exporting the results. These outputs are useful for organizing an inventory because they expose public record status at the domain level. A public lookup cannot see which application sent a message, whether that application applies DKIM signing, whether SPF aligns with the visible From domain, or how a receiving mailbox provider handled an individual delivery. Use the [DMARC learning hub](/learning/dmarc) for the protocol context behind the record. A DMARC record is a DNS TXT record published at `_dmarc.<domain>`. [RFC 7489 defines DMARC record discovery and policy processing](https://datatracker.ietf.org/doc/html/rfc7489). The record can express a requested policy, but the public record alone does not prove that all mail streams will pass DMARC. ![Bulk DMARC inventory interpretation matrix](/images/editorial/bulk-dmarc-checker/bulk-dmarc-checker-result-map.webp "1200x829") *Source: Palisade.* ## How to run the check ### 1. Prepare a clean domain list Use one organizational or sending domain per line. Remove URLs, mailbox addresses, IP addresses, and duplicate domains before submitting the list. Keep a separate note of the system owner for each domain, such as a corporate mail platform or marketing sender, because the DNS result does not identify the operational owner. If your list exceeds the tool's supported batch size, split it into named batches. Preserve the original domain list so that you can run the same check after remediation. ### 2. Submit a batch to a bulk checker Open a checker that explicitly supports multiple domains and submit one batch. Read the displayed result scope before acting on it. For example, dmarc.cc says it shows results only for the first 50 submitted domains, so a larger list needs more than one run or an email-verified scan tier. Do not assume a result is absent because the domain has no record. First confirm that the tool actually evaluated that domain in the submitted batch. ### 3. Confirm a finding with a direct DNS lookup For a domain that needs follow-up, query the DMARC owner directly. Replace the example domain with the domain under review. ```bash dig +short TXT _dmarc.yourdomain.com ``` This command returns the public DNS answer visible through the resolver you use. It does not prove that the authoritative server has the same answer, that DNS has fully propagated everywhere, or that a sender uses the domain correctly. > Do not replace a DMARC record based only on a batch summary. First capture the existing TXT answer and identify the team or service that owns mail for the domain. ## How to interpret the results ### A DMARC result is present A present DMARC result means the checker found a public record at the DMARC DNS owner for that domain. Review the returned policy field as an inventory attribute, then move to message and report evidence before deciding whether the policy is appropriate. Under [RFC 7489](https://datatracker.ietf.org/doc/html/rfc7489), DMARC evaluation uses identifier alignment and authentication results. A visible record does not establish that SPF or DKIM will authenticate and align for every sender. ### A DMARC result is missing or unclear A missing or unclear result is a priority for direct verification. Check the submitted domain spelling, query `_dmarc.yourdomain.com`, and inspect the authoritative DNS provider if the public resolver answer is unexpected. Do not infer the correct record value from another domain in the batch. DMARC reporting destinations, policy choices, and authorized sending paths are domain-specific. ### An SPF result needs review A bulk result that identifies an SPF issue narrows the next task, but it does not identify the sender that caused it. Use the [Palisade SPF checker](/tools/spf) to inspect the public SPF record for one domain, then inspect a delivered message from the sender under investigation. SPF can pass while DMARC still fails if the SPF-authenticated domain does not align with the visible From domain. The [email authentication guidance for Gmail](/learning/authenticate-email-for-gmail) explains why authentication needs to be checked in the context of the actual sending path. ### The policy field needs review A policy field is an attribute of the published DMARC record. It is not a remediation threshold by itself. A domain with a policy value still needs evidence that legitimate mail streams authenticate and align. A domain without a useful result needs DNS verification and an ownership decision before a record is created or changed. Keep the batch output and the direct DNS response separate from message evidence. Each answers a different question. ## How to act on the result Start with domains where the batch result is missing, unclear, or points to an SPF concern. For each domain, collect four layers of evidence before treating a change as complete: - DNS: query the DMARC owner through the authoritative DNS provider and at least one public resolver. - Vendor: check the sending service's current domain-authentication or verification status. - Message: send a real message through the exact production path and inspect its `Authentication-Results` header. - DMARC: review aggregate-report data after mail has accumulated. [Authentication-Results is standardized by RFC 8601](https://datatracker.ietf.org/doc/html/rfc8601). The receiver adds this field to describe its authentication evaluation. Compare the visible From domain with the domains reported for SPF and DKIM. Do not use a batch lookup as a substitute for that message-level check. When the batch points to an SPF issue, identify the sender first. When it points to a DMARC record issue, preserve the existing record and verify ownership before editing DNS. When a sender's DKIM status is uncertain, use the [Palisade DKIM checker](/tools/dkim) for public-key evidence, then compare the result with the `d=` and `s=` values from a real message. ## How to retest Run the same batch again after the DNS answer changes. Compare only the domains that were included in the original run, and record the time of each check. Confirm the direct DNS query separately. Then send a new message through the same application, sender address, and recipient path that exposed the issue. Inspect the resulting `Authentication-Results` header. After aggregate reports accumulate, use them to determine whether other sources still send mail for the domain. A changed public record is a DNS result. A passing delivered message is message-path evidence. Aggregate reports add evidence about observed sources over time. ## Check individual domains after the bulk inventory Use the [Palisade DMARC checker](/tools/dmarc) to inspect the public DMARC record for a domain that needs follow-up after the batch review. Compare the result with your direct DNS lookup and a delivered message before changing policy. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=dmarc_tools_validation&utm_content=bulk-dmarc-checker) when you need ongoing analysis of DMARC aggregate-report data across domains. Palisade identifies sending sources and authentication or alignment issues, creates prioritized remediation tickets, and can propose the next policy step for human review. It does not change the DMARC policy for you, prove every future message will authenticate, or replace message-level investigation. ## Sources and further reading - [dmarc.cc bulk DMARC checker](https://dmarc.cc) - [DMARC Generator bulk checker](https://dmarcgenerator.com) - [RFC 7489: Domain-based Message Authentication, Reporting, and Conformance](https://datatracker.ietf.org/doc/html/rfc7489) - [RFC 8601: Authentication-Results header field](https://datatracker.ietf.org/doc/html/rfc8601) - [Palisade DMARC checker](/tools/dmarc) ## Frequently asked questions ### Can a bulk DMARC checker prove that every sender is authorized? No, a bulk DMARC checker cannot prove that, because it only reads public DNS records for the domains you submit. It cannot see which applications send mail, how a delivered message authenticated, or how a receiver decided to handle it. Use DMARC aggregate reports to identify the sources actually sending for each domain. ### Does a DMARC record in a bulk result mean DMARC is working? No, a record in the results only means the checker found a published DMARC record at `_dmarc` for that domain. DMARC is working when real messages carry a passing SPF or DKIM result that aligns with the visible From domain. Confirm that with a delivered message, then use aggregate reports to see the sending sources. ### Should I fix every domain with a missing DMARC result immediately? Confirm DNS ownership and the domain's sending role before you publish anything. Run a direct `dig +short TXT _dmarc.yourdomain.com` lookup to check that the batch result is accurate, and ask the responsible team which services send mail for the domain. A parked domain and an active sending domain need different records. ### Can I use a bulk result to change the DMARC policy? No, a batch result is not enough to change a policy, because it only tells you which domains to investigate first. A policy decision needs DNS, vendor, delivered-message, and aggregate-report evidence together. Moving to `p=quarantine` or `p=reject` before you know the legitimate senders can stop real mail. ### Why should I retest with the same domain list? Using the same list makes the before-and-after comparison meaningful. It also helps distinguish a corrected public DNS answer from domains that were not included because of a batch limit. --- # Business email compromise also known as Canonical: https://www.palisade.email/learning/business-email-compromise-also-known-as > Business email compromise, also known as Email Account Compromise, is a transfer-of-funds scam. Learn how BEC differs from phishing and CEO fraud. Business email compromise is also known as Email Account Compromise, or EAC, in [FBI Internet Crime Complaint Center public service announcements](https://www.ic3.gov/PSA/2024/PSA240911). The terms are often paired as BEC/EAC because both involve fraudsters using compromised communications or impersonation to pursue unauthorized transfers of funds. "CEO fraud" is not a full synonym. It names one BEC scenario involving an executive wire-transfer request. ## Quick takeaways - Email Account Compromise, or EAC, is the alternative name most closely paired with business email compromise. - The FBI's IC3 began tracking BEC and EAC as one crime type in 2017 because their techniques became similar. - BEC is distinct from phishing, though phishing messages can help an attacker gather details for a BEC attempt. - A compromised email account can expose financial correspondence, address books, forwarding settings, and mailbox rules. - CEO fraud describes one executive-impersonation BEC scenario, not every type of BEC. - DMARC, SPF, and DKIM help validate email identity, but they do not replace mailbox-access controls or transfer verification. ## How BEC and EAC work The [FBI IC3 BEC information page](https://www.ic3.gov/CrimeInfo/BEC) describes business email compromise as a scam targeting businesses and people involved in transfer-of-funds activity. It is frequently carried out by compromising legitimate business email accounts through social engineering or computer intrusion, with the goal of an unauthorized transfer. IC3's 2017 public service announcement distinguishes the terms historically. BEC described scams targeting businesses that work with suppliers or regularly make wire-transfer payments. EAC described the component targeting individuals who make wire-transfer payments. IC3 says it began tracking the scams as a single crime type in 2017 because their techniques had become increasingly similar. A compromised mailbox can make the fraud more convincing because the attacker can use a legitimate account and learn how the organization communicates. The [2025 IC3 Annual Report](https://www.ic3.gov/AnnualReport/Reports/2025_IC3Report.pdf) also notes that fraudsters can compromise other forms of communication, including phone numbers and virtual meeting applications. BEC commonly involves a financial request, but the visible message alone does not establish how the attacker got access. A sender might impersonate an executive without accessing that executive's mailbox. In another case, the sender may control a legitimate account and reply within an existing conversation. For related education on impersonation and account-based threats, see Palisade's [email threats and impersonation learning hub](/learning/threats). ## When the name changes, and when it does not Use "Email Account Compromise" when referring to the BEC/EAC pairing used in IC3 public service announcements. Use "CEO fraud" only for the executive wire-transfer-request scenario that IC3 identifies as one variant. The same IC3 notice also gives separate names for its supplier-invoice scenario, including "Bogus Invoice Scheme," "Supplier Swindle," and "Invoice Modification Scheme." A practical decision rule is: - If the question is about the broader transfer-of-funds scam against a business or an individual, call it BEC or the IC3-paired term BEC/EAC. - If the attacker has gained access to a real mailbox, describe that mailbox as an email account compromise. - If the request falsely appears to come from an executive, "CEO fraud" can describe that scenario, but it does not cover every BEC case. - If an unsolicited message asks for credentials or personal information, it fits IC3's separate Phishing/Spoofing category unless evidence shows it is part of a broader BEC operation. This distinction matters because the response differs. An impersonated executive request calls for out-of-band payment verification. A compromised mailbox also calls for account investigation, mailbox-rule review, and access remediation. ![Decision flow showing when to use the terms BEC, EAC, CEO fraud, and phishing](/images/editorial/business-email-compromise-also-known-as/business-email-compromise-also-known-as-decision-flow.webp "1200x829") *Source: Palisade.* ## A worked BEC and EAC example IC3 documents five main BEC scenarios, including supplier fraud, executive wire-transfer requests, fraudulent correspondence through compromised email, executive and attorney impersonation, and data theft. The following is a worked classification example, not a message template. ```text Observed request: A finance employee receives an urgent request to change a supplier's payment destination. If the sender only imitates an executive: Classification: BEC scenario, potentially "CEO fraud." If the request arrives inside a real supplier mailbox thread: Classification: BEC involving an Email Account Compromise. If an earlier unsolicited message sought login details: Classification: Phishing may be a precursor, but it is not the same crime type as the later BEC attempt. ``` The [IC3 BEC/EAC scenario notice](https://www.ic3.gov/PSA/2017/PSA170504) says victims may first receive phishing emails seeking details about the business or person being targeted. That makes phishing a possible precursor to BEC, not another name for it. IC3's annual-report taxonomy treats BEC and Phishing/Spoofing as separate crime types. Its definition of phishing covers unsolicited email, text messages, and phone calls that appear to come from a legitimate company and request personal, financial, or login credentials. A phishing event can be harmful on its own, while a BEC event focuses on the unauthorized transfer objective. ## What to check after a suspected compromise Start with the evidence available from the affected account and payment process. - Review mailbox rules and automatic forwarding. The [IC3 cloud-email compromise advisory](https://www.ic3.gov/PSA/2020/PSA200406) says attackers may configure rules that delete key messages or forward mail to an outside account. - Review retained login and mailbox-setting changes. IC3 recommends logging and retaining these changes for at least 90 days, and enabling alerts for suspicious activity such as foreign logins. - Check whether the attacker accessed financial conversations or address books. IC3 says attackers analyze compromised mailboxes for financial-transaction evidence and may use address books to identify additional phishing targets. - Verify payment changes through an independently known contact method before moving funds. A reply to the suspicious message thread is not independent verification. - Confirm that SPF, DKIM, and DMARC are configured as part of the anti-spoofing controls IC3 recommends. For broader context, see [email security](/learning). A public posture check can help identify published-domain gaps after the immediate investigation. You can [assess your email-security posture](/tools/email-security-score), then compare the result with DNS records and the evidence from the actual mailbox. A public check cannot show whether a specific account was compromised, inspect private mailbox rules, or prove why a payment request was fraudulent. ## Continue your email-security review BEC/EAC response begins with the compromised account, the payment request, and the organization’s identity controls. Use Palisade's [email security guide](/learning) to place those controls alongside the wider risks of spoofing, account compromise, and email-based fraud. The guide cannot determine whether a particular mailbox is compromised or approve a payment change. Those decisions require account logs, mailbox evidence, and your organization’s payment-verification process. ## Sources and further reading - [FBI IC3: Business Email Compromise](https://www.ic3.gov/CrimeInfo/BEC) - [FBI IC3 PSA: Business Email Compromise/Email Account Compromise](https://www.ic3.gov/PSA/2024/PSA240911) - [FBI IC3 PSA: BEC/EAC scenarios and terminology](https://www.ic3.gov/PSA/2017/PSA170504) - [FBI IC3 PSA: Cloud-based email-service exploitation](https://www.ic3.gov/PSA/2020/PSA200406) - [FBI IC3 2025 Annual Report](https://www.ic3.gov/AnnualReport/Reports/2025_IC3Report.pdf) ## Frequently asked questions ### What is another name for a business email compromise? Email Account Compromise, or EAC, is the alternative name paired with BEC in [IC3's 2024 public service announcement](https://www.ic3.gov/PSA/2024/PSA240911). IC3 previously described BEC as targeting businesses and EAC as the component targeting individuals who make wire transfers, then began tracking them as one crime type in 2017. IC3's 2025 annual-report definitions use "Business Email Compromise (BEC)" alone. ### What is a business email compromise? A business email compromise is a scam that targets businesses and people performing transfers of funds. According to the [FBI IC3 BEC definition](https://www.ic3.gov/CrimeInfo/BEC), attackers frequently compromise legitimate business email accounts through social engineering or computer intrusion to cause an unauthorized transfer of funds. ### Is BEC the same as phishing? No. IC3 tracks BEC and Phishing/Spoofing as separate crime types in its [2025 Annual Report](https://www.ic3.gov/AnnualReport/Reports/2025_IC3Report.pdf). A BEC operation may begin with phishing messages that collect information about a target, but phishing can also occur independently and does not necessarily involve a transfer-of-funds scam. ### What does a compromised email mean? A compromised email account means an unauthorized party has gained access to the mailbox. The [IC3 cloud-email advisory](https://www.ic3.gov/PSA/2020/PSA200406) says attackers may examine messages for financial information, create rules to delete messages, enable external forwarding, and use address books to target additional people. ### Is CEO fraud another name for all BEC? No. IC3 identifies "CEO Fraud" as an alternative name for a scenario in which a business executive receives or initiates a wire-transfer request. Other BEC scenarios involve supplier invoices, compromised correspondence, attorney impersonation, or data theft, so CEO fraud is narrower than BEC/EAC. --- # Business email compromise is financially motivated Canonical: https://www.palisade.email/learning/business-email-compromise-attacks-are-typically-disruption-motivated-attacks > Business email compromise attacks are financially motivated scams that seek unauthorized fund transfers, not typically disruption-motivated attacks or. No. Business email compromise attacks are typically financially motivated scams, not disruption-motivated attacks. The FBI's Internet Crime Complaint Center defines BEC as a scam targeting people and organizations involved in fund transfers, where account compromise, social engineering, or intrusion leads to an unauthorized transfer of funds. An attack can disrupt operations, but disruption is not the defining objective of BEC. ## Quick takeaways - BEC commonly seeks an unauthorized payment, payroll diversion, gift cards, or changed bank details. - A compromised mailbox can let an attacker observe real invoices, contacts, and payment routines before sending a request. - An urgent request to change payment details or keep a transaction secret is a strong red flag. - Verify significant payment changes through a separate trusted channel before moving money. - DMARC can help stop exact-domain spoofing, but it does not stop every BEC tactic. - The FBI's published BEC scenarios contain five categories, not four. ## How business email compromise works [The FBI IC3 definition of BEC](https://www.ic3.gov/CrimeInfo/BEC) focuses on unauthorized fund transfers. The attacker may compromise a legitimate business email account through social engineering or computer intrusion, then use that access to make a payment request look credible. The fraud often depends on context. In its [published BEC scenarios](https://www.ic3.gov/PSA/2017/PSA170504), IC3 explains that attackers can study selected victims, identify people involved in wire transfers, and learn the protocols used inside the business. A phishing message may first collect details such as names or travel dates. A compromised mailbox can also conceal the fraud. The FBI warned that attackers may configure mailbox rules to delete key messages or enable forwarding to an outside account. They can then impersonate communication between a business and its vendor or customer to redirect pending or future payments to a fraudulent bank account. [IC3's cloud-email-services alert](https://www.ic3.gov/PSA/2020/PSA200406) describes those account-takeover tactics. The financial objective is visible in current reporting. The [2025 IC3 Annual Report](https://www.ic3.gov/AnnualReport/Reports/2025_IC3Report.pdf) records 24,768 BEC complaints and about $3.05 billion in reported losses for 2025. These are self-reported complaints to a US federal reporting channel, not measured total losses, and IC3 says its statistics are an assessment at a point in time that may change. Fortra, reported in the [APWG Q1 2026 phishing report](https://docs.apwg.org/reports/apwg_trends_report_q1_2026.pdf), found that observed BEC attempts most often requested gift cards, wire transfers, or payroll diversion. Those figures describe attempted attacks seen in one vendor's telemetry, not confirmed losses. For broader context on email-borne threats, see Palisade's [email security resources](/learning) and the [email threats hub](/learning/threats). ## When the answer changes A BEC incident can cause disruption. A diverted supplier payment can delay orders, create accounting work, trigger incident response, and damage a business relationship. Those consequences do not change the core classification of the scam when the attacker is trying to obtain money or payment credentials. Use this decision rule: - If the message seeks a payment, altered bank details, payroll change, gift cards, or access that supports a transfer, treat it as potential BEC. - If the primary objective is to disable systems, destroy data, or interrupt operations without a transfer-fraud request, it may be another type of cyber incident rather than BEC. - If the evidence is incomplete, pause the transaction and verify the request outside the email thread. > A payment request that arrives with urgency, secrecy, or changed account details should not be approved from email evidence alone. The FBI recommends using secondary channels or two-factor authentication to verify requests that change account information. Its BEC guidance also says to inspect the actual sender address, especially on mobile devices where address details may be less visible. [IC3's protection guidance](https://www.ic3.gov/CrimeInfo/BEC) supports both checks. DMARC has a narrow but useful role. CISA, NSA, FBI, and MS-ISAC recommend a DMARC policy of `reject` to protect recipients from emails that impersonate a domain. However, [RFC 9989](https://www.rfc-editor.org/rfc/rfc9989) states that DMARC addresses specific forms of exact-domain spoofing and does not address lookalike domains or display-name abuse. A BEC message sent from a compromised legitimate mailbox or a free webmail account can still pass around that control. For the distinction between BEC and related terminology, see [business email compromise also known as](/learning/business-email-compromise-also-known-as). ## Worked example: invoice redirect decision rule Consider a finance employee who receives a message that appears to continue an existing supplier conversation: ```text From: supplier-contact@lookalike-example.com Subject: Updated remittance details Please use the new account details for the invoice due today. This change is confidential. Please confirm once payment is sent. ``` This example is illustrative only. The message has several BEC indicators: a payment-detail change, urgency, secrecy, and a sender address that must be checked carefully. ![Decision flow for validating a suspected business email compromise payment request](/images/editorial/business-email-compromise-attacks-are-typically-disruption-motivated-attacks/business-email-compromise-attacks-are-typically-disruption-motivated-attacks-bec-decision-flow.webp "1200x738") *Source: Palisade.* The appropriate response is to stop the payment change and use a known phone number or other established contact method to confirm it with the supplier. Do not reply to the message or use a contact detail introduced by that message. IC3 specifically recommends out-of-band communication, such as telephone calls, to verify significant transactions. The email alone does not prove fraud. A real vendor can legitimately change banking information. The point of the decision rule is to require independent confirmation before money moves. ## Practical next steps when you see a BEC red flag Start with the evidence in front of you: - If you have a suspicious payment request, verify it through a trusted secondary channel before approving or changing payment details. - If you can access the mailbox involved, review forwarding settings and mailbox rules for unexpected changes. Preserve relevant evidence according to your incident process. - If the sender claims to use a company domain, compare the complete email address with a known prior address. Do not rely on the display name. - If your domain is being impersonated, review SPF, DKIM, and DMARC. The FBI recommends configuring those controls to help prevent spoofing and validate email, but they do not prove that every BEC message will be blocked. - If you need a broader explanation of attacker methods and business impact, read the [Business Email Compromise (BEC) attacks: 2025 guide](/learning/what-is-the-complete-guide-to-business-email-compromise-bec-attacks-in-2025). ## Review the email-security controls around impersonation A BEC payment request needs an independent transaction check first. After the immediate risk is contained, use Palisade's [email security guidance](/learning) to review the controls that reduce exact-domain impersonation. Email authentication does not prove whether a particular payment request is legitimate, detect every compromised mailbox, or stop lookalike-domain and display-name fraud. ## Sources and further reading - [FBI IC3: Business Email Compromise](https://www.ic3.gov/CrimeInfo/BEC) - [FBI IC3: The 5 Billion Dollar Scam](https://www.ic3.gov/PSA/2017/PSA170504) - [FBI IC3: Cloud-based email services BEC alert](https://www.ic3.gov/PSA/2020/PSA200406) - [FBI IC3 2025 Annual Report](https://www.ic3.gov/AnnualReport/Reports/2025_IC3Report.pdf) - [RFC 9989: DMARC](https://www.rfc-editor.org/rfc/rfc9989) - [APWG Phishing Activity Trends Report, Q1 2026](https://docs.apwg.org/reports/apwg_trends_report_q1_2026.pdf) ## Frequently asked questions ### What are the 4 types of attacks? No. IC3 does not publish a four-type BEC taxonomy. Its [2017 BEC public service announcement](https://www.ic3.gov/PSA/2017/PSA170504) identifies five main scenarios: business working with a foreign supplier, a business executive receiving or initiating a wire-transfer request, business contacts receiving fraudulent correspondence through compromised email, business executive and attorney impersonation, and data theft. ### What are the common tactics used in business email compromise attacks? Common tactics include compromising a legitimate business email account through social engineering or computer intrusion, studying payment workflows, impersonating vendors or executives, and redirecting payments to fraudulent accounts. Attackers may also use mailbox rules or automatic forwarding to hide messages, according to [IC3's 2020 alert](https://www.ic3.gov/PSA/2020/PSA200406). ### What is a red flag for a business email compromise? An urgent or secret request to change payment details is a major red flag. Verify the sender's full email address and confirm the request through a known phone number or another trusted channel before approving the transaction, as recommended by [FBI IC3](https://www.ic3.gov/CrimeInfo/BEC). ### What is a business email compromise? Business email compromise is a scam in which an attacker uses compromised accounts, impersonation, or social engineering to induce an unauthorized transfer of funds. The [FBI IC3 definition](https://www.ic3.gov/CrimeInfo/BEC) applies to both businesses and individuals who conduct transfers. ### Does DMARC stop business email compromise? No. DMARC can help receiving systems reject unauthenticated messages that spoof your exact domain when the domain publishes an appropriate policy. [RFC 9989](https://www.rfc-editor.org/rfc/rfc9989) states that DMARC does not address lookalike domains, display-name abuse, or every fraudulent email. Payment verification and account-security controls remain necessary. --- # Is business email compromise the most expensive cyberattack? Canonical: https://www.palisade.email/learning/business-email-compromise-is-the-most-expensive-cyberattack > Business email compromise ranks second by total losses in the FBI's 2025 figures, behind investment fraud, but leads every category on loss per complaint. No. By the most widely cited loss figures, the FBI's Internet Crime Complaint Center, business email compromise ranks second, not first. IC3's 2025 report records $3,046,598,558 in BEC losses against $8,648,617,756 for investment fraud. BEC does lead on one measure: average loss per complaint, at roughly $123,000, the highest of any crime type IC3 tracks. "Most expensive" may mean total reported losses, loss per incident, recovery cost, or business disruption, and those measures rank attacks differently. See the broader [email threats and impersonation hub](/learning/threats) for related security topics. ## Quick takeaways - In the FBI's 2025 figures, BEC losses were $3.05 billion, second to investment fraud at $8.65 billion. - The average BEC complaint reported about $123,000 in losses, the highest of any crime type IC3 tracks. - Reported losses do not necessarily equal total losses, incident response costs, or operational disruption. - A single large breach and a category of fraud cannot be ranked together without a stated methodology. - "Largest cyberattack" has no single answer unless the measurement is defined first. - Claims that a percentage of incidents begin with email require a source that defines both "incident" and its sample. - An email-security review can identify controls to examine, but it does not prove that BEC is prevented. ## How an "most expensive" claim works The phrase "most expensive cyberattack" combines two decisions that must be explicit: what counts as the attack category, and what counts as cost. A category-level claim compares many events over a reporting period. A single-event claim compares one incident against another. A loss claim may count money reported by victims, while an operational-cost claim may include investigation, recovery, legal work, downtime, or other impacts. Without the same measurement across every item being compared, the ranking is not reliable. A quotable statement should therefore include all of the following: - The source that collected the data. - The reporting period. - The definition of BEC used by that source. - The loss metric. - The attack categories included in the comparison. - Any stated limits, such as underreporting or incomplete cost capture. Cisco's homepage states that it observes "750B Security events observed daily, across networks." That statement describes the scale of Cisco's observations. It does not provide a BEC loss ranking, a comparison methodology, or a definition of cost. [Cisco's security overview](https://cisco.com) therefore cannot support the conclusion that BEC is the costliest cyberattack. Likewise, Darktrace describes its platform as providing "Unified visibility, continuous behavioral monitoring, and autonomous response across your entire enterprise." That product description does not rank cyberattack categories by financial loss. [Darktrace's product overview](https://darktrace.com) is not evidence for a BEC cost comparison. ## When the answer changes The answer can change only when a source makes the ranking testable. Use this decision rule: - If an official report compares BEC with other attack categories using the same reported-loss metric and period, describe BEC's rank exactly as that report states it. - If a source reports BEC losses without comparing categories, say that it reports BEC losses. Do not add a rank. - If a source identifies one expensive incident, describe it as a single incident. Do not use it to rank an attack category. - If a source uses a different measure, such as records exposed, affected people, downtime, or ransom demand, keep that measure separate from financial loss. - If the source does not define its population or method, treat its ranking as unsupported. This distinction matters for adjacent questions too. [Business email compromise versus phishing](/learning/business-email-compromise-vs-phishing) is a separate classification question. It does not establish which category costs more. Similarly, an article about [another name for business email compromise](/learning/what-is-a-different-name-used-for-business-email-compromise) can clarify terminology without proving a loss ranking. > Do not turn a headline, vendor marketing statement, or isolated incident figure into an industry-wide ranking. The comparison method must be available to readers. ![Decision flow for deciding whether a business email compromise cost claim has enough evidence to publish](/images/editorial/business-email-compromise-is-the-most-expensive-cyberattack/business-email-compromise-is-the-most-expensive-cyberattack-decision-rule.webp "1200x676") *Source: Palisade.* ## What the FBI's 2025 figures actually show The IC3 annual report is the source that makes this ranking testable, because it publishes losses and complaint counts for every crime type it tracks, over the same period, using the same self-reported metric. For 2025 it records $3,046,598,558 in BEC losses across 24,768 complaints, inside a total of $20.877 billion across 1,008,597 complaints. Ranked by total reported losses, investment fraud is far larger at $8,648,617,756. The report states the order plainly: investment-related fraud was the largest component of losses, followed by business email compromise and tech support scams. So the popular claim fails on total losses. It holds on a different measure. Dividing IC3's published losses by its published complaint counts gives an average reported loss per complaint: | Crime type | Average reported loss per complaint | |---|---| | Business email compromise | $123,005 | | Investment fraud | $118,500 | | Data breach | $109,826 | | Tech and customer support scams | $44,664 | | Ransomware | $8,950 | | Phishing and spoofing | $1,127 | BEC has the highest average of any category, and roughly fourteen times the average of a ransomware complaint. IC3 does not publish these averages, so treat them as calculated from its figures rather than quoted from the report. Three caveats travel with every number above. The data is self-reported complaints to a United States federal channel, not measured losses. Each complaint is counted under a single crime type, so a phishing email that ends in a fraudulent wire appears once, not twice. And IC3 describes its own statistics as an assessment taken at a point in time, which may change. The honest published claim is therefore one of these: BEC is the second-costliest crime type in the FBI's 2025 figures; or the average BEC complaint reports the largest loss of any category; or BEC is the most expensive attack on business email, which is a narrower class than "cyberattack." ## Worked evidence rule for a BEC cost claim Use a claim only when it can be expressed with the source's own scope and metric. ```text Publishable claim shape: [Official source] reports [amount or rank] for [defined BEC category] during [reporting period], measured as [defined loss metric], compared with [defined attack categories or population]. Do not publish: "Business email compromise is the most expensive cyberattack." unless the cited source explicitly supports that exact comparison. ``` The first shape gives readers a way to assess the claim. The second omits the source, period, metric, and comparison class. The same rule applies to statements such as "90% of cyber incidents begin with email" or "a stated percentage of cyberattacks use email." Those figures need a primary study that defines what counted as an incident or attack, who was measured, and how the percentage was calculated. A percentage without those details cannot establish a general fact about all organizations. ## What to check before using a BEC cost claim Start with the source named in the statement. Look for the report itself, rather than a summary page, and record the reporting period and definition of loss. Then check whether it compares BEC against other categories under the same method. If the evidence concerns your own organization rather than an industry-wide ranking, keep the question operational: - Identify the business process that handles payment, supplier, payroll, or account-change requests. - Record which verification step is required before that process releases money or changes details. - Review the organization’s broader [email security controls](/learning) alongside the approval process. - Preserve the relevant evidence for incident response and follow the organization’s reporting procedure when fraud is suspected. A public posture check can be a useful starting point for an email-security discussion. [Check an email-security score](/tools/email-security-score) to review the domain input it accepts before using the result in a wider control review. That check does not detect every BEC attempt, prove that a payment request is legitimate, monitor a production environment continuously, or establish the cost of any attack category. ## Sources and further reading - [FBI IC3 annual reports](https://www.ic3.gov/AnnualReport/Reports). The 2025 Internet Crime Report is the source for every loss and complaint figure above. - [APWG Phishing Activity Trends Report, Q1 2026](https://docs.apwg.org/reports/apwg_trends_report_q1_2026.pdf). Attack volume and BEC delivery methods. - [CISA, NSA, FBI and MS-ISAC phishing guidance](https://www.cisa.gov/sites/default/files/2023-10/Phishing%20Guidance%20-%20Stopping%20the%20Attack%20Cycle%20at%20Phase%20One_508c.pdf). The recommended control set, including DMARC at reject. - [Palisade email security guide](/learning) - [Palisade email security score checker](/tools/email-security-score) ## Frequently asked questions ### What do business email compromise attacks rely most heavily on? Business email compromise relies most heavily on ordinary email accounts rather than technical exploits. Fortra's data in the APWG Q1 2026 report found 72% of BEC attacks were launched from a free webmail domain, with Gmail accounting for 53% of those. The most common payout method was gift cards at 48%, ahead of wire transfers at 19%, and the average wire request was $42,663. Those figures describe attempted attacks observed by one vendor, not confirmed losses. ### What is the largest cyberattack in history? The answer changes with the measure you pick, because "largest" can mean reported financial loss, people affected, records exposed, duration, or business disruption. Measured by money reported to the FBI in 2025, investment fraud leads at $8,648,617,756, with business email compromise second at $3,046,598,558. Name your metric first, then use a source that compares events under that same metric. ### Where do 90% of all cyber incidents begin? The usual answer given is email, but nobody publishes the study behind the 90% figure, so it works as a slogan rather than a statistic. A number worth citing would define what counts as an incident, name the population measured, state the period, and explain how the percentage was calculated. Until you can find that source, call email a common starting point and leave the number off. ### What percent of cyber attacks use email? There is no dependable single percentage, because threat reports, incident datasets, and security telemetry each define "cyberattack" differently and count email's role differently. The FBI's IC3 files each complaint under one crime type, so a phishing email that ends in a fraudulent wire is counted once, not twice. Quote a percentage only when the source states its definition, sample, and period. ### Does an email-security score prove a company is protected from BEC? No, an email-security score cannot prove that, because it reviews public domain evidence rather than the payment and approval steps that BEC targets. Most BEC attempts succeed through a convincing request sent to a person, not a flaw in DNS. Use the score to open a control review, then check how your team verifies payment, supplier, and account-change requests. --- # Can email addresses be spoofed? Canonical: https://www.palisade.email/learning/can-email-addresses-be-spoofed > Can email addresses be spoofed? Yes. Learn how displayed From addresses can be forged, how DMARC helps, and how to check a suspicious email. Yes. An attacker can put an email address they do not control in the visible `From` field, so a message can appear to come from a colleague, bank, or service. SMTP was designed to permit flexible sender fields, not to prove the displayed author. SPF, DKIM, and DMARC help receivers test whether the visible domain is authorized, but authentication alone does not prove that a message is safe. ## Quick takeaways - A visible `From` address is a claim made in the message, not proof of who sent it. - SPF checks the SMTP envelope sender or HELO identity, not necessarily the address a reader sees. - DKIM can authenticate a signing domain without proving that domain is the visible author. - DMARC requires an aligned SPF or DKIM pass for the visible `From` domain. - A DMARC pass validates authorized use of a domain for that message. It is not a safety or inbox-placement guarantee. - Lookalike domains and deceptive display names can still mislead readers even when DMARC protects an exact domain. ## How email address spoofing works [SMTP's security section](https://www.rfc-editor.org/rfc/rfc5321#section-7.1) states that mail can be created to trick a naive recipient into believing it came from somewhere else. The sending side chooses both the SMTP envelope return path and the message header `From` field. That flexibility supports legitimate cases such as a system sending mail on behalf of a person, but it also permits impersonation. The visible `From` field identifies the author of the message under [RFC 5322](https://www.rfc-editor.org/rfc/rfc5322#section-3.6.2). It is different from the `Sender` field, which identifies the mailbox responsible for transmission. A mail app commonly shows the `From` field first, which makes it a useful target for fraud. A simplified spoofed message can look like this: ```text From: Finance team <finance@yourdomain.com> Sender: mailer@unrelated-example.com To: employee@recipient.example Subject: Urgent payment approval ``` This illustration does not establish whether the message authenticated. It shows why reading the display name or visible address by itself is insufficient. [DMARC's current specification](https://www.rfc-editor.org/rfc/rfc9989#section-4.2) describes the RFC 5322 `From` address as a field that has been trivially forged throughout email's history. DMARC addresses that problem by checking whether an SPF or DKIM result passes and aligns with the domain in the visible `From` address. ![Flow showing a visible From address, SPF and DKIM authentication identities, then DMARC alignment with the From domain](/images/editorial/can-email-addresses-be-spoofed/can-email-addresses-be-spoofed-authentication-flow.webp "1200x829") *Source: Palisade.* SPF and DKIM each answer a narrower question. [RFC 7208](https://www.rfc-editor.org/rfc/rfc7208) explains that SPF evaluates the SMTP `MAIL FROM` identity and, where needed, the HELO or EHLO identity. An SPF pass can therefore be valid for an envelope domain that differs from the visible `From` domain. [DKIM](https://www.rfc-editor.org/rfc/rfc6376) lets a signing domain claim responsibility for a message, while separating the signer's identity from the purported author. DMARC adds the connection that matters to the recipient: at least one passing SPF or DKIM domain must align with the visible author domain. Under [RFC 9989's alignment rules](https://www.rfc-editor.org/rfc/rfc9989#section-3.2.10), relaxed alignment means the domains share an organizational domain, while strict alignment requires identical domains. ## When a spoofed address is more or less likely Use this decision rule: treat the visible sender as unverified until the receiving service shows authentication details that support the sender's domain, and still assess the message's request, links, and context. A suspicious message can use several different forms of deception: - An exact-domain spoof uses your real address, such as `ceo@yourdomain.com`, without authorization. DMARC is designed to help with this case. - A display-name spoof uses a familiar name while the underlying address belongs to another domain. - A lookalike-domain message uses a domain that resembles the real one, such as a spelling variation or a visually similar character. DMARC has a clear limit. [RFC 9989's anti-phishing section](https://www.rfc-editor.org/rfc/rfc9989#section-2.2) says it combats specific forms of exact-domain spoofing, but does not address visually similar domains or abuse of the human-readable display name. For Gmail users, [Google's authentication guidance](https://support.google.com/mail/answer/180707) says a question mark beside the sender's name means the message is not authenticated. Gmail also exposes "Mailed by" and "Signed by" information in message details. This is a Gmail-specific indicator, not a rule for Outlook or Apple Mail. If you inspect raw headers, look for an `Authentication-Results` field added by your own receiving system. [RFC 8601](https://www.rfc-editor.org/rfc/rfc8601) defines that field for recording authentication results. Do not trust an arbitrary copy found in a forwarded message or supplied by an attacker. The same RFC warns that malicious senders can forge a convincing-looking authentication-results field if a receiving system fails to remove it. For the header-by-header walkthrough and the visible signals that give a forgery away first, see [how to spot an email sender spoof](/learning/email-address-spoofing-prevention). ## A worked authentication example Consider a message that displays `billing@yourdomain.com`: ```text From: Billing <billing@yourdomain.com> Authentication-Results: mx.recipient.example; spf=pass smtp.mailfrom=mailer.unrelated-example.com; dkim=pass header.d=unrelated-example.com; dmarc=fail header.from=yourdomain.com ``` This is an illustrative evidence object, not a copied production header. The SPF and DKIM checks passed for `unrelated-example.com`, but neither authenticated identity aligns with `yourdomain.com`, the domain shown in `From`. The result is a DMARC failure for the visible domain. The reverse result also needs care. A DMARC pass means the domain owner authorized use of that visible domain for the message. [RFC 9989](https://www.rfc-editor.org/rfc/rfc9989) states that this does not make a message safe or desirable, and it does not guarantee inbox placement. A compromised legitimate account can send an authenticated phishing message. ## What to check next If you received a suspicious email, preserve it and use your mail provider's phishing-reporting control. Do not reply, open unexpected attachments, or use links in a message that asks for credentials, payment, or urgent action. Compare the visible address with the full address and inspect provider-authentication details where your mail app offers them. If you own the impersonated domain, start with [Palisade's email security guidance](/learning) and review the wider [email threats hub](/learning/threats). Check whether SPF, DKIM, and DMARC are published, then confirm that legitimate production messages pass with alignment. A public [email security score check](/tools/email-security-score) can inspect published domain controls, while [guidance for blocked email](/email-deliverability/why-are-my-emails-being-blocked) covers delivery failures that occur after a receiver evaluates a message. For stronger protection against exact-domain spoofing, publish DMARC only after legitimate senders are understood and tested. [CISA's phishing guidance](https://www.cisa.gov/sites/default/files/2023-10/Phishing%20Guidance%20-%20Stopping%20the%20Attack%20Cycle%20at%20Phase%20One_508c.pdf) recommends `p=reject` for sent email and explains that DMARC reports can identify apparent forgery sources. A reject policy can disrupt legitimate mail that still fails DMARC, so validate each real sending path before moving policy. ## Review your domain's email-security controls A spoofed visible address is only one signal. Use the email security guide to understand the controls your domain needs, then inspect its public DNS posture with the security-score tool. [Review email-security controls](/learning) A public check cannot prove why one received message was delivered, whether a header was forged before delivery, or whether every production sender is authenticated and aligned. ## Sources and further reading - [RFC 5321: Simple Mail Transfer Protocol](https://www.rfc-editor.org/rfc/rfc5321#section-7.1) - [RFC 5322: Internet Message Format](https://www.rfc-editor.org/rfc/rfc5322#section-3.6.2) - [RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance](https://www.rfc-editor.org/rfc/rfc9989) - [RFC 8601: Message Header Field for Indicating Message Authentication Status](https://www.rfc-editor.org/rfc/rfc8601) - [Google Gmail: Check if your Gmail message is authenticated](https://support.google.com/mail/answer/180707) - [CISA phishing guidance](https://www.cisa.gov/sites/default/files/2023-10/Phishing%20Guidance%20-%20Stopping%20the%20Attack%20Cycle%20at%20Phase%20One_508c.pdf) ## Frequently asked questions ### What does a spoofed email address look like? A spoofed email can show the exact address of a real person or organization in the visible `From` field. It can also use a familiar display name with an unrelated address, or a lookalike domain that differs slightly from the real domain. Check the full address and authentication details rather than relying on the displayed name. ### How do you know if an email is spoofed? You cannot determine that from the visible sender alone. Check your mail provider's authentication details, inspect a trusted `Authentication-Results` header when available, and compare the full address, request, links, and expected context. In Gmail, a question mark next to the sender indicates that the message is not authenticated. ### Can someone spoof my own email address? Yes. Someone can place your address in a message's visible `From` field without controlling your mailbox. SPF, DKIM, and an aligned DMARC policy reduce exact-domain spoofing. A `p=reject` DMARC policy asks receivers to reject messages that fail DMARC, but it does not stop display-name impersonation or lookalike domains. ### What happens if I open a spoofed email? Opening an email does not by itself prove that your account or device is compromised. Risk increases if you open an attachment, enter credentials on a linked site, approve a payment request, or follow instructions from the sender. Report the message through your mail provider and use known contact details to verify any urgent request. ### Does a DMARC pass mean an email is legitimate? No. A DMARC pass means the visible domain was authorized for that message through aligned SPF or DKIM. It does not assess whether the content is truthful, whether an account was compromised, or whether the message is safe to act on. --- # Cheap email warmup: how to evaluate the offer Canonical: https://www.palisade.email/learning/cheap-email-warmup > Cheap email warmup is only worth considering when its testing, mailbox coverage, account handling, and limits match evidence from your real sending. Cheap email warmup is not a buying category you can judge by price alone. A lower-cost service may offer mailbox activity, inbox or spam tests, mailbox management, or outreach integrations, but those are different services with different evidence. Choose one only after you can identify what it observes, which providers it covers, and how you will separate its activity from results produced by your actual sending program. ## Quick takeaways - A warm-up vendor's price does not establish inbox-placement results, safety, or suitability for your domain. - EmailWarmup.com markets personalized warm-up, mailbox coverage, and spam-placement tests, but those are vendor-described features rather than independent outcome evidence. - Authentication for your sending domain needs separate checks for SPF, DKIM, and DMARC. - Inbox and spam tests are snapshots of the mailboxes and conditions included in that test. - A useful buying decision compares observable scope before comparing cost. - Your production messages and their delivery evidence remain the basis for evaluating delivery problems. ## How cheap email warmup offers work Email warmup is commonly marketed as part of a broader set of outbound and deliverability products. For example, [Instantly lists Inbox Placement, Deliverability, and Email Accounts](https://instantly.ai/) among products for outreach workflows. That positioning tells you the category often combines several jobs. It does not establish that any one service improves a particular domain's placement. [EmailWarmup.com describes "Personalized Email Warmup"](https://emailwarmup.com/) and says its matching considers industry and copy. The same vendor says it covers professional-to-professional Google and Microsoft mailboxes, plus personal Gmail, Outlook, and Yahoo mailboxes. Treat those statements as a description of the vendor's offered scope. They do not prove how a receiving provider will handle your production mail. EmailWarmup.com also advertises ["Unlimited free email spam tests"](https://emailwarmup.com/) and says those reports cover inbox, promotions, and spam placement for "50+ ESPs," along with domain and IP list appearance. A test can be useful evidence about the addresses and conditions included in that run. It cannot establish a receiver's private reputation decision, future inbox placement, or the behavior of every production message. Warm-up activity is also only one possible part of a wider [email deliverability](/email-deliverability) program. Authentication, message content, sending patterns, recipient engagement, and each receiver's local decisions are separate questions. Use the [deliverability learning hub](/email-deliverability) when you need to investigate those wider factors rather than turn a vendor purchase into a diagnosis. ## When a cheap option is worth considering The answer changes when you can compare like with like. Price becomes meaningful only after the services under consideration have a stated scope you can inspect. Use this decision rule: - Consider a lower-cost offer when it clearly states the mailbox providers or test coverage it includes, the type of mailbox monitoring or replacement it provides, and the workflow it integrates with. - Pause when the offer describes a result, such as better placement or reputation, without showing what evidence it collects from your own sending path. - Reject a comparison based only on price when the billing terms, mailbox limits, cancellation terms, or trial conditions are not available for review. - Keep warm-up activity separate from authentication work. A vendor's statement that its mailboxes can be secured with SPF, DKIM, and DMARC does not show that your existing sending domain has valid authentication. EmailWarmup.com markets ["Get Mailboxes with 24/7 Replacement"](https://emailwarmup.com/) and says those mailboxes can be "fully secured with SPF, DKIM, and DMARC." That is a claim about the vendor's mailbox offering. It is not evidence that a buyer's domain, ESP, or production sending path is authenticated correctly. For a narrower discussion of claims associated with automated warm-up, see [AI email warmup: what it is and what it cannot prove](/learning/ai-email-warmup). The practical question is still the same: what evidence would show whether your real messages authenticate and reach their intended recipients? ## A worked evaluation rule Before you compare two cheap email warmup offers, record the advertised scope and the evidence you will use after purchase. This prevents a feature list from becoming an unsupported assumption about delivery results. ```text Warm-up offer evaluation, illustrative only Offer scope: - Provider or mailbox coverage: ____________________ - Inbox or spam test coverage: ______________________ - Account handling or replacement: __________________ - Outreach or sending-workflow integration: __________ Production evidence to keep separate: - SPF, DKIM, and DMARC status for yourdomain.com - Delivered-message headers from the real sender - Delivery evidence from the receiving provider - Results from the actual sending path over time Decision: Compare price only after the offer scope is equivalent. Do not treat warm-up activity as proof of production placement. ``` ![Decision flow for comparing warm-up service scope with separate production authentication and message evidence](/images/editorial/cheap-email-warmup/cheap-email-warmup-decision-rule.webp "1200x718") *Source: Palisade.* The distinction matters because a service can test mailboxes or manage accounts without proving that your sending application uses the intended authenticated domain. A passing test also does not show whether an important production message passed SPF or DKIM with the alignment needed for DMARC. ## What to check before you buy Start with the evidence you already have. - If you have a domain but no current authentication inventory, check its public configuration first. You need to know whether SPF, DKIM, and DMARC are present before assigning a delivery problem to warm-up activity. - If you have delivered messages from the affected application, retain redacted message headers and compare their authentication results with the domain's DNS records. - If a vendor offers placement testing, ask which mailbox providers and folders are included, then treat the output as a test result for that stated coverage. - If you operate several sending domains or client domains, document which source sends for each domain. One warm-up account does not establish the state of another domain or application. A public configuration check is a useful starting point, especially before paying for a service marketed around deliverability. It is still not a production-message test. A DNS result cannot show whether your application signed a specific message, which route it took, or how a receiver will place it. ## Check the domain before attributing the problem to warm-up Run the sending domain through Palisade's security score to inspect its publicly visible email-authentication configuration before you conclude that warm-up is the missing variable. [Check your domain's email security score](/tools/email-security-score) A public security check cannot prove inbox placement, inspect a receiver's private reputation decision, or confirm that every message from your production sender uses the expected authentication path. If your team needs to keep inventory and remediation work organized across multiple domains, [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=email_deliverability&utm_content=cheap-email-warmup). Palisade analyzes DMARC aggregate-report data, identifies sending sources and authentication or alignment issues, and creates prioritized remediation tickets. It can propose a next policy step, but a human reviews the evidence and applies any DNS change. It does not prove an individual receiver's placement decision or control a warm-up vendor's service. ## Sources and further reading - [EmailWarmup.com product page](https://emailwarmup.com/) - [Instantly product page](https://instantly.ai/) - [Palisade email security score](/tools/email-security-score) - [Email deliverability guide](/email-deliverability) ## Frequently asked questions ### Is cheap email warmup the same as an inbox-placement test? No, they are two different services that produce different evidence. EmailWarmup.com sells both warm-up activity and spam tests, and a placement test reports only on the mailboxes and folders included in that run. It does not tell you where your production messages will land. ### Can a warm-up provider secure my existing sending domain? No, a warm-up provider configures the mailboxes it supplies, not the domain you already send from. EmailWarmup.com says its own mailboxes can be secured with SPF, DKIM, and DMARC, which is a statement about its product rather than about your domain. Check your sending domain's own SPF, DKIM, and DMARC records separately. ### Should I compare warm-up vendors by price per mailbox? Compare price per mailbox only once the offers match on mailbox coverage, testing scope, account handling, and integrations. A cheaper mailbox that covers fewer providers is not the same product. Take the current pricing, limits, and billing terms from each vendor's own pricing information. ### Does warm-up prove that my messages will reach the inbox? No, because warm-up activity runs on the vendor's mailboxes and says nothing about your production mail. The vendors describe features rather than published placement outcomes, and a receiver's placement decision depends on factors outside any warm-up service's stated scope. ### What should I check before buying an email warmup service? Check the sending domain's public SPF, DKIM, and DMARC configuration, then retain evidence from messages sent through the real production path. Compare that evidence with the service's stated coverage before treating price as a useful comparison. --- # Check DMARC alignment Canonical: https://www.palisade.email/learning/check-dmarc-alignment > Check DMARC alignment by comparing a delivered message's From domain with SPF and DKIM identities, then inspect published adkim and aspf settings. To check DMARC alignment, inspect the trusted `Authentication-Results` header on a delivered message, then compare the visible `From` domain with the SPF `smtp.mailfrom` domain and DKIM `header.d` domain. DMARC passes when either SPF or DKIM both passes and aligns under the published DMARC policy. Use a DNS check separately to see whether the domain publishes strict or relaxed alignment settings. ## Quick takeaways - DMARC requires an aligned SPF pass or an aligned DKIM pass, not merely an SPF or DKIM pass. - The visible `From` domain is the domain DMARC compares against. - SPF alignment compares the `From` domain with the SPF-authenticated `smtp.mailfrom` identity. - DKIM alignment compares the `From` domain with the DKIM signing domain in `header.d`. - Relaxed alignment permits an organizational-domain match. Strict alignment requires an exact domain match. - A public DMARC record check cannot parse message headers or prove that a delivered message aligned. ## What this tool checks The [Palisade DMARC checker](/tools/dmarc) checks the public DMARC record published at `_dmarc.yourdomain.com`. Use it to inspect the policy and determine whether the record includes `adkim` or `aspf` alignment settings. The checker answers a DNS question: what policy and alignment mode does the domain publish right now? It cannot inspect a message's `From`, `Return-Path`, SPF identity, DKIM signature, or receiver-added authentication result. It also cannot prove the production sending path, confirm every sender, or explain why a specific mailbox provider accepted or rejected one message. For message-level evidence, use a message delivered through the path you are investigating. Open its raw headers in the receiving system and find the `Authentication-Results` field added by a trusted receiver or gateway. [RFC 8601 defines `Authentication-Results` and warns that recipients must establish which instances they trust](https://www.rfc-editor.org/rfc/rfc8601.html). Do not treat a copied header from an untrusted source as proof of authentication. ## How to run the check ### 1. Collect a delivered-message sample Send a new message through the exact application, ESP, gateway, and recipient path you need to validate. Open the message's raw headers in the receiving system. Record these values without exposing message content or recipient data: - The domain in the visible `From:` address. - The receiver's `Authentication-Results` result for `spf`, `dkim`, and `dmarc`. - The SPF identity shown as `smtp.mailfrom`, when present. - The DKIM signing domain shown as `header.d`, when present. - The domain named after `header.from` in the DMARC result, when present. A header can contain multiple `Authentication-Results` fields. Start with the result added by the receiving system you trust. Preserve the complete authentication-related lines for the incident record, but redact addresses, message IDs, IP addresses, and any customer content before sharing them. ### 2. Inspect the public DMARC record Enter the visible `From` domain in the [Palisade DMARC checker](/tools/dmarc). Review the published `p`, `adkim`, and `aspf` tags. If `adkim` or `aspf` is omitted, the DMARC specification defines relaxed alignment as the default. You can independently query the public record with an example lookup: ```bash dig +short TXT _dmarc.yourdomain.com ``` A record can have this structural shape: ```text v=DMARC1; p=none; adkim=r; aspf=r ``` > Use the record generated for your own domain. Do not copy DNS values, reporting addresses, or policy settings from another organization. ![Palisade DMARC checker showing a public DNS record check](/images/editorial/check-dmarc-alignment/check-dmarc-alignment-palisade-tool.png "1280x720") *Source: [Palisade DMARC checker](/tools/dmarc), checked 2026-08-13.* This public DNS check establishes the published policy settings. It cannot parse a delivered message or prove that its SPF or DKIM identity aligned. ### 3. Compare the message identities Compare the visible `From` domain with each passing authentication path. [RFC 9989 defines DMARC identifier alignment and the relationship between the RFC 5322 From domain, SPF, and DKIM](https://www.rfc-editor.org/rfc/rfc9989.html). For SPF, compare `From:` with `smtp.mailfrom`. A passing SPF result only supports DMARC if those domains align under `aspf`. For DKIM, compare `From:` with `header.d`. A passing DKIM result only supports DMARC if those domains align under `adkim`. If the receiver recorded `dmarc=pass`, identify which aligned path supplied the pass. If it recorded `dmarc=fail`, check both paths before changing DNS. One path may pass authentication but fail alignment while the other path may be absent, fail, or also be unaligned. ![DMARC alignment decision map for SPF and DKIM evidence](/images/editorial/check-dmarc-alignment/check-dmarc-alignment-decision-map.webp "1200x676") *Source: Palisade.* ## How to interpret the results ### SPF passes and aligns An SPF pass can support DMARC when the `smtp.mailfrom` domain matches the visible `From` domain under the domain's `aspf` mode. Under strict SPF alignment, the domains must match exactly. Under relaxed SPF alignment, they can share the same organizational domain. For example, `From: alerts@yourdomain.com` and `smtp.mailfrom=bounces.yourdomain.com` can align in relaxed mode, but do not align in strict mode. Confirm the receiver's own result before treating this as the path that passed DMARC. ### SPF passes but does not align This result means the receiving system accepted the SPF-authenticated identity, but that identity cannot satisfy the SPF branch of DMARC for the visible `From` domain. A common next step is to determine whether the sender can use a custom return-path domain that aligns with the domain in `From:`. Do not add an unrelated service to the root SPF record solely because its messages fail DMARC. The problem may be the envelope identity rather than authorization. Check whether DKIM provides an aligned pass before changing SPF. ### DKIM passes and aligns A DKIM pass can support DMARC when `header.d` aligns with the visible `From` domain under `adkim`. This is often the relevant path when a sending platform uses its own return-path domain but signs with your domain or an aligned subdomain. The DKIM signature must be present in the delivered message and the trusted receiver must report the result. A public DKIM record alone does not prove that the application used the matching selector or key. ### DKIM passes but does not align A DKIM signature can verify while its `header.d` domain does not align with the visible `From` domain. In that case, the DKIM branch does not support DMARC. Review the sender's authenticated-domain or custom-DKIM configuration and use the domain it generated for that account. If the sender cannot sign with an aligned domain, determine whether an aligned SPF path is available before changing the visible `From` domain or the DMARC policy. ### Both authenticated paths fail to supply alignment When neither SPF nor DKIM supplies a passing aligned identifier, the message cannot pass DMARC. The receiving system's `dmarc=fail` result is the evidence to investigate first. Follow an [email authentication failure diagnosis](/learning/email-authentication-failure) with the same delivered-message path, rather than assuming a public DNS record explains the failure. A single failed message does not establish that every sender is failing. It may identify one application, configuration, or routing path that needs separate review. ## How to act on the result Start with the evidence that failed: - If SPF passed but did not align, review the sender's envelope sender or custom return-path configuration. Change only the sending path that produced the message, then send a new message through that same path. - If DKIM passed but did not align, review the sender's DKIM signing-domain configuration. Use the exact DNS records generated for your account and domain. Do not reuse selectors or CNAME targets from another tenant. - If SPF or DKIM did not pass, identify whether the sender failed to authenticate, the DNS record is missing, or the message used a different identity than expected. - If the message has an aligned pass but the public checker shows unexpected `adkim` or `aspf` values, resolve the DNS discrepancy before considering a stricter policy. - If you only need to inspect the policy record, use the [DMARC record checking guide](/tools/dmarc). Its DNS workflow cannot establish alignment for a particular delivered message. Keep the four evidence layers separate: - DNS: query the authoritative record and at least one public resolver after a change. - Sender: confirm the sending service accepted and verified the intended authentication domain. - Message: inspect a newly delivered message from the same production path. - DMARC: review aggregate-report evidence after reports accumulate to see whether other sources show the same issue. A green sender status is not a delivered-message check. A delivered-message pass is also not proof that every application using the domain will pass. ## How to retest Repeat the public record lookup after DNS propagation, then send a new message through the same application and route. Inspect the trusted receiver's new `Authentication-Results` field and compare the same identifiers again. The expected change depends on the repair. A corrected return-path or signing domain should produce an SPF or DKIM identity that aligns with the visible `From` domain under the published `aspf` or `adkim` setting. If the receiver still reports `dmarc=fail`, preserve the new header evidence and revisit both authentication paths. Use the [DMARC learning hub](/learning/dmarc) for the policy implications after you know which sources pass and align. Do not move from monitoring to enforcement based on one sample message. ## Turn recurring sender evidence into reviewable work One delivered message can identify an alignment path, but it cannot inventory every legitimate source that sends as the domain or show how aggregate-report evidence changes over time. [Palisade's documented DMARC Agent workflow](https://docs.palisade.email/guides/fixing-authentication-issues/) analyzes DMARC aggregate-report data, identifies sources and authentication or alignment issues, and creates prioritized remediation tickets for human review. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=article_assisted&utm_content=check-dmarc-alignment) Palisade does not authorize senders, apply DNS or DMARC policy changes, reproduce a receiver's private decision, or guarantee delivery. ## Sources and further reading - [RFC 9989: Domain-based Message Authentication, Reporting, and Conformance](https://www.rfc-editor.org/rfc/rfc9989.html) - [RFC 8601: Authentication-Results header field](https://www.rfc-editor.org/rfc/rfc8601.html) - [Palisade DMARC checker](/tools/dmarc) ## Frequently asked questions ### What is DMARC alignment? DMARC alignment is the comparison between the domain in the visible `From:` address and an authenticated SPF or DKIM domain. SPF uses the `smtp.mailfrom` identity, while DKIM uses the signing domain in `header.d`. At least one passing identity must align for DMARC to pass. ### How do I check if my DMARC is working? Inspect a trusted receiver's `Authentication-Results` header on a delivered production message. Confirm its `dmarc` result, then identify whether aligned SPF or aligned DKIM supplied the pass. Check the public DMARC record separately to see the published policy and alignment modes. ### How to correct DMARC? Correct the authentication path that failed to provide an aligned pass. Configure the sender to use an aligned return-path domain for SPF, an aligned signing domain for DKIM, or both. Retest with a newly delivered message through the same sender and recipient path before changing DMARC policy. ### What is required when strict DMARC alignment is enabled? Strict SPF alignment requires the `smtp.mailfrom` domain to exactly match the visible `From` domain. Strict DKIM alignment requires `header.d` to exactly match the visible `From` domain. A subdomain that would align under relaxed mode does not satisfy strict alignment. ### Does a passing SPF result mean DMARC passes? No. SPF must both pass and align with the visible `From` domain to satisfy the SPF branch of DMARC. A passing aligned DKIM result can still satisfy DMARC when SPF does not align. ### Can a DMARC record checker prove message alignment? No. A DMARC record checker can show the public policy and `adkim` or `aspf` settings. It cannot parse a delivered message's headers, identify the actual SPF or DKIM domains used, or prove the receiver's DMARC evaluation. --- # Check email address deliverability Canonical: https://www.palisade.email/learning/check-email-address-deliverability > Check email address deliverability by verifying address, MX, and mailbox signals, then separate valid results from actual inbox placement today. To check email address deliverability, run the address through an email-verification service before sending. These services can test syntax, the recipient domain's MX records, and mailbox-related signals without delivering a message. A positive result can reduce the chance of sending to an invalid address, but it does not prove that a future campaign will reach the inbox. [Email deliverability](/email-deliverability) also depends on the sending domain, message, recipient policy, and receiver decisions. ## Quick takeaways - Email verification checks address-related signals before you send a message. - A valid MX record shows that a domain publishes mail-routing records, not that a specific mailbox will accept mail. - Vendor result labels are not universal, so act on the detailed reason code where one is available. - An inconclusive result needs a separate handling rule, not an assumption that the address is invalid. - Recheck lists because an address that was usable can later become dormant or unavailable. - Inbox placement requires a delivered-message test and broader sender-domain evidence. ## What this tool checks An email-verification service assesses whether an address appears usable without sending an email. [Email Hippo's verifier documentation](https://tools.emailhippo.com) describes a sequence that checks formatting, the domain's MX records, a connection to the receiving mailbox without delivery, disposable-provider signals, and bounce history. That makes verification useful for list hygiene. It can help separate obvious bad addresses from addresses that need review before a campaign sends. It cannot see your production sending path, prove that your application will sign mail correctly, continuously observe address status, or explain why a particular mailbox provider placed a message in spam. For the broader distinction between address validity and inbox arrival, use the [email deliverability learning hub](/email-deliverability). Address verification is one pre-send check within that larger operating problem. ![Decision map for address-verification results and next actions](/images/editorial/check-email-address-deliverability/check-email-address-deliverability-result-map.webp "1200x829") *Source: Palisade.* ## How to run the check ### 1. Start with the exact address you plan to contact Copy the address from the source system that will supply your send list. Keep the original value available for comparison, especially if the address was entered manually or imported from a form. Do not replace a failing address with a guessed variant. A changed local part, domain, or plus-address suffix can point to a different mailbox or have provider-specific handling. ### 2. Submit the address to an email-verification service Use an email verifier that documents what its result means. Email Hippo states that its free verifier can check whether an email address exists and identify fake emails and possible bounces without sending an email. Its free verifier documents a maximum of 100 daily checks. Treat the returned classification as a vendor-specific assessment. Email Hippo documents the labels "OK, Bad, or Unverifiable." Verifalia documents a different set of categories: "Deliverable, Undeliverable, Risky, or Unknown." The labels overlap in intent but do not carry identical rules across providers. You can independently inspect the recipient domain's public MX records with a repeatable lookup: ```bash dig +short MX yourdomain.com ``` A returned MX answer confirms public DNS routing information for `yourdomain.com`. It does not confirm that `person@yourdomain.com` exists or that the mailbox will accept your message. ### 3. Keep the address result with its timestamp Record the address, result label, any detailed status, provider, and date of the check in your list-management process. Email Hippo notes that email-data validity can change over time and recommends checking lists regularly. > Do not delete an address solely because an MX lookup fails once. Confirm the exact domain spelling and inspect the authoritative DNS answer before treating the address as permanently unusable. ![Email Hippo email verifier](/images/editorial/check-email-address-deliverability/check-email-address-deliverability-shot-2.png "1600x900") *Source: [Email Hippo email verifier](https://tools.emailhippo.com), checked 2026-08-13.* ## How to interpret the results ### An address is reported as OK or Deliverable Email Hippo uses "OK" and Verifalia uses "Deliverable" for positive outcomes in their respective systems. Treat either result as evidence that the provider found no disqualifying issue under its documented checks. Do not treat it as proof of inbox placement. This is an inference from the distinction between address verification and deliverability: a verifier can assess address and mailbox-related signals, while inbox arrival also depends on the sending domain, authentication, content, traffic pattern, and the recipient provider's private filtering decision. ### An address is reported as Bad or Undeliverable Email Hippo's "Bad" and Verifalia's "Undeliverable" categories indicate that the service found a reason the address should not be treated as a normal send target. Check the detailed reason in the provider's result before taking action because the evidence supporting that category can differ. Correct a clear transcription error at the source if you have independent confirmation of the intended address. Otherwise, suppress the address from the next send and retain the result record so the decision can be reviewed later. ### An address is reported as Unverifiable, Risky, or Unknown These labels are not interchangeable across providers. Email Hippo documents "Unverifiable," while Verifalia documents "Risky" and "Unknown" among its categories. Do not convert them into a universal pass or fail rule. Put these addresses into a review segment with a defined sending policy. The right action depends on the provider's detailed status, your consent record, and the cost of a possible bounce. If the address belongs to an existing customer or user, use an approved confirmation path rather than guessing from a verification result. ### The recipient domain has MX records MX records direct mail for a domain. [MXToolbox describes an MX lookup as listing MX records in priority order from the domain's authoritative name server](https://mxtoolbox.com). This evidence is useful when a verifier reports a domain-level issue or when you need to check whether a domain is configured to receive email. It is not mailbox evidence. A domain can have valid MX records while a particular recipient address is unavailable, restricted, dormant, or filtered. ## How to act on the result Use a repair threshold based on the observed category and your own documented list policy, rather than an invented universal bounce-rate target. Before using a verifier, separate basic address syntax from mailbox evidence with [valid characters for an email address](/learning/valid-characters-for-email-address). - For an invalid syntax or obvious domain typo, correct the source data only when an independent record confirms the intended address. Otherwise remove it from the immediate send audience. - For a bad or undeliverable result, suppress the address from the campaign and investigate the source of the data. Repeatedly importing the same invalid values will recreate the problem. - For an unverifiable, risky, or unknown result, keep the provider's detailed explanation and apply your review policy. Do not label the mailbox nonexistent without more evidence. - For a positive result, continue to test the actual sending program. A verified recipient list does not validate sender authentication, message construction, or inbox placement. If campaign placement is the concern, compare address hygiene with the broader criteria in [how to choose an email deliverability service](/learning/best-email-deliverability-service). A list checker addresses recipient quality. It does not replace evidence from the sender domain and delivered messages. ## How to retest Run the same address through the same verifier after correcting source data or after the provider's documented retry interval. Compare the new result with the earlier timestamp and detailed status. Then test a real message through the same production application, authenticated sending domain, and recipient-provider path that matter for the campaign. Inspect the delivered message and its receiver-added authentication results. Address verification and message delivery are separate evidence layers. For recurring programs, recheck older lists before reuse because address validity can change. A previous positive verification result should not be treated as permanent evidence. ## Check the sending domain behind a list-quality issue After you have separated invalid and inconclusive addresses, inspect the sending domain's email-authentication posture with the [Palisade Email Security Score](/tools/email-security-score). This is useful when list hygiene is not the whole explanation for delivery problems and you need a domain-level security check alongside real-message evidence. [Check the sending domain's email security score](/tools/email-security-score) A domain-level security check does not verify an individual mailbox, repair a recipient list, continuously monitor every sending path, or guarantee inbox placement. For ongoing DMARC work, Palisade is agentic DMARC software that analyzes aggregate-report data, identifies sending sources and alignment issues, and proposes the next policy step for human review. ## Sources and further reading - [Email Hippo email verifier](https://tools.emailhippo.com) - [Verifalia email verification](https://verifalia.com) - [MXToolbox MX lookup](https://mxtoolbox.com) - [Email deliverability](/email-deliverability) - [Palisade Email Security Score](/tools/email-security-score) ## Frequently asked questions ### How to check deliverability of email? Use an email-verification service to check formatting, domain and MX availability, and mailbox-related signals before sending. Then send a real message through the production path to assess delivery evidence. A successful verification result is useful for list hygiene, but it does not prove inbox placement. ### What is the 60 40 rule in email? No verified email standard or provider rule in the available documentation defines a universal "60 40 rule in email." Do not use the phrase as a delivery threshold or list-cleaning policy without identifying the source, product, or program that defines it. ### What is the +1 Gmail trick? No verified provider documentation establishes a deliverability rule called the "+1 Gmail trick." Do not alter recipient addresses or assume that address variants have the same mailbox behavior without current provider documentation and a test of the intended sending path. ### Is there an application that checks email addresses for deliverability? Yes. [Email Hippo's verifier](https://tools.emailhippo.com) says it can identify fake emails and possible bounces without sending an email. [Verifalia](https://verifalia.com) also documents real-time and bulk email verification categories. These applications assess address-related signals, not guaranteed inbox placement. ### Do MX records prove an email address is deliverable? No. MX records show that a domain publishes mail-routing information. They do not prove that a specific mailbox exists, will accept a message, or will place it in the inbox. ### Should I check an email list only once? No. Email Hippo states that email-data validity can change at any time and recommends checking lists regularly. Recheck before important sends and keep the result date with each verification record. --- # Client DMARC remediation workflow Canonical: https://www.palisade.email/learning/client-dmarc-remediation-workflow > Client DMARC remediation workflow for MSPs: collect evidence, assign owners, approve changes, validate message paths, and report exceptions. A client DMARC remediation workflow gives an MSP one repeatable way to turn domain evidence into owned work across a portfolio. Create a record for each client domain, separate observed evidence from assumptions, assign each issue to the party that controls it, obtain client approval before DNS changes, validate the real sending path, and keep unresolved items in an exception register. ## Quick takeaways - A portfolio workflow needs a separate evidence record for every client domain and sending path. - Public DNS checks are useful intake evidence, but they do not prove a production message path. - The MSP can coordinate remediation, while clients, DNS hosts, and sending platforms retain distinct responsibilities. - Client approval should be recorded before a controlled DNS change or a change to a sender configuration. - An exception remains active until it has an owner, a decision, and a future review date. - This workflow is a Palisade operating framework, not an external DMARC requirement. ## Operating context and ownership This workflow is for an MSP or multi-client IT team that manages recurring DMARC remediation work. It differs from a single-domain checklist because each client has separate approval rights, DNS access, sending systems, business-critical mail flows, and escalation paths. The MSP owns the operating record: intake quality, evidence collection, issue triage, coordination, change documentation, and recurring review. The client owns business decisions, authorization, and any access that the service agreement does not delegate. The DNS host publishes approved record changes. A sending-platform owner controls that platform's authentication settings and can provide a delivered-message sample. Receiving mailbox providers make their own delivery and policy decisions. Use [what is DMARC](/learning/what-is-dmarc) for protocol background. This article focuses on the service workflow around remediation rather than explaining the protocol itself. Define the service boundary at onboarding. Record whether the MSP may prepare DNS changes, submit changes after written approval, configure a sender platform, or only provide evidence and recommendations. A technically correct recommendation can still remain blocked when authority is unclear. ![Portfolio decision flow showing intake, evidence triage, client approval, controlled change, validation, and exception review](/images/editorial/client-dmarc-remediation-workflow/client-dmarc-remediation-workflow-portfolio-flow.webp "1200x980") *Source: Palisade.* ## Evidence to collect Create one working record for every client domain. Keep the evidence source with the observation so a later reviewer can distinguish a public DNS answer from a client statement or a delivered-message result. Collect: - Client name, business owner, technical approver, and escalation contact. - Domain and known sending paths in scope. - DNS host and the person or team authorized to approve changes. - Public DMARC, SPF, and DKIM evidence where relevant. - Sender owner, observed authentication evidence, and the next action. - Proposed change, approval state, validation result, and rollback condition. - Exception owner, reason, and review date. Use the [DMARC checker](/tools/dmarc) when the immediate question is whether a domain has a published DMARC record. These checks inspect public DNS evidence. They do not identify every legitimate sender, prove that a platform uses a configured record, monitor the client continuously, or prove a receiving provider's private delivery decision. Keep the operating record portable enough to work in a PSA, ticket system, spreadsheet, or client report: ```yaml client: example-client domain: yourdomain.com evidence: dns_check: public record result message_path: redacted delivered-message result client_confirmation: known sender confirmed by client owner: sender-platform-owner next_action: request proposed remediation details approval_status: pending-client-approval verification_result: not-yet-tested exception_owner: client-technical-approver review_on: 2026-09-01 ``` Treat this as a working framework. The field values should reflect the service agreement and the client's actual authority model, not a generic ticket label. ## How to run the workflow ### 1. Confirm scope and ownership **Owner:** MSP service owner. **Input:** Client domain list, contacts, service boundary, and known sending systems. **Output:** An approved scope record with a named business approver, technical approver, DNS owner, and escalation route. Start with the domains the client expects the service to cover. Do not assume that a parent domain, subdomain, parked domain, or acquired brand domain belongs in the same remediation queue. Record exclusions and the reason for each exclusion. Ask the client to identify important sending paths such as marketing, support, billing, application, and internal systems. Mark each path as client-confirmed, report-observed, message-verified, unknown, or retired. These labels prevent a one-time onboarding list from being mistaken for current production evidence. ### 2. Normalize evidence by domain and sender **Owner:** MSP analyst. **Input:** Public DNS checks, aggregate-report observations, client inventory, and redacted delivered-message evidence where available. **Output:** A normalized sender and issue list with dated evidence. Aggregate-report data can help identify sending sources and prioritize investigation. It does not replace a real delivered-message check when the question is whether an exact production path authenticated as expected. For each observed source, record what is known and what remains unknown. An unrecognized source is an investigation item, not proof of unauthorized mail. A platform listed by the client is also not proof that it currently sends with the domain. Use [DMARC audit template for MSPs](/learning/dmarc-audit-template-for-msps) when the portfolio needs a consistent review artifact before remediation tickets are assigned. ### 3. Assign remediation to the controlling party **Owner:** MSP analyst assigns; client, DNS host, or sender owner acts. **Input:** Normalized issue list and the defined service boundary. **Output:** One owner-specific remediation proposal per issue. Write the issue in observable terms. For example, identify the domain, sender, available evidence, requested action, approval requirement, and test needed after the change. Avoid broad tickets such as "fix DMARC." They do not tell the recipient what they control or how the MSP will verify completion. The sender owner may need to provide platform-specific configuration details or a new delivered-message sample. The DNS owner may need to publish an approved change. The client approver may need to accept an exception when the business cannot yet remediate a path. ### 4. Prepare a client approval package **Owner:** MSP service owner. **Input:** Proposed remediation, evidence, affected business path, rollback condition, and test plan. **Output:** A client decision: approve, defer, reject, or request more evidence. The approval package should state what will change, who will make the change, what evidence supports it, what can break, and how the team will recognize a failed result. Record the previous state before a change so the rollback path is clear. > Do not publish a DNS or sender-configuration change based only on a green public-record check. Confirm that the client has approved the change and that the affected sending path has a defined retest. For a portfolio policy change, use [DMARC policy rollout across client domains](/learning/dmarc-policy-rollout-across-client-domains) to keep each client's approval and evidence separate from the broader portfolio target. ### 5. Make the controlled change and retain the record **Owner:** Authorized DNS or sender-platform owner. **Input:** Client-approved change request and change window. **Output:** A dated change record with the before state, after state, actor, and rollback condition. The MSP should record the approved change and the evidence needed for post-change review. The client, DNS host, or sender platform may perform the actual action depending on access and contract terms. Do not turn a remediation proposal into an implied authorization. The client remains responsible for approvals outside the delegated service scope, and the sender platform remains responsible for its own configuration behavior. ### 6. Validate the same production path **Owner:** MSP analyst, with the sender owner where needed. **Input:** Public DNS result, vendor status if available, and a real message from the affected production path. **Output:** A validation result or an exception with a next action. Validate at the applicable layers: - **DNS:** Check the published record through the authoritative source and a public resolver where the service process permits. - **Vendor:** Record the sending platform's current authentication or verification result if the platform provides one. - **Message:** Review a redacted delivered message from the exact production path when the issue concerns actual authentication behavior. - **DMARC:** Review accumulated aggregate-report evidence after the relevant data becomes available. A vendor indicator is not proof of a delivered-message result. A DNS lookup is not proof that an application is signing or using the intended path. Keep these layers separate in the client record. ## Investigate this with your coding agent Use this when the MSP already has redacted inventory, ticket, and runbook artifacts but needs a consistent remediation-register schema. Prepare only redacted examples and confirm that no active incident or client authorization decision is being delegated. ```agent Problem: Build a proposed remediation register for a multi-client DMARC service where evidence, ownership, approval, validation, and exceptions are currently inconsistent. Evidence: Redacted domain inventory, existing ticket fields, remediation runbook, DNS change templates, and example aggregate-report or delivered-message evidence with private data removed. Repository scope: Inspect the approved MSP operations repository, read-only inventory exports, and remediation ticket schema. Constraints: Inspect before editing. Do not apply changes until I approve the proposed diff. Do not access credentials, private keys, tokens, unredacted headers, customer data, DNS systems, PSA systems, or production incidents. Propose CSV or JSON fields for client/domain, sender, owner, authentication evidence, proposed change, approval status, verification result, exception owner, and review date. Requested output: Diagnosis of current field gaps, a minimal proposed schema, mappings to existing artifacts, validation rules, rollback considerations, and unknowns. Verification: Validate the proposed schema against redacted sample records and confirm that each record requires an owner, approval state, verification result, exception owner when blocked, and review date. Stop if: Credentials, private data, client authorization, production mutation, an active incident, or missing redacted evidence is required. ``` ## Exceptions and escalation Keep an exception register for work that cannot safely move forward. An exception is not a closed ticket. It is a documented decision with an owner and review date. Escalate when: - The client cannot confirm whether an observed sender is legitimate. - No party can demonstrate ownership of the DNS zone or sending platform. - The requested change affects a business-critical path without a safe test. - A sender owner cannot provide the evidence needed for validation. - The client defers a decision but the domain remains in scope. - A remediation result conflicts with the available production-message evidence. The service owner decides how the item is handled within the agreement. The client approver accepts business risk or authorizes a change. The DNS host and sender platform control their respective systems. The receiving mailbox provider controls its own handling decision. Use a simple decision path: if ownership is known and approval exists, proceed to the controlled change and validation. If evidence is incomplete, request the missing artifact and set a review date. If the client declines or cannot approve the work, retain the item as an exception and report it clearly. ## Reporting and success measures Use a monthly operational review and a client-facing quarterly summary. The monthly artifact should show domain status, open remediation work, evidence gaps, approvals pending, validation outcomes, and overdue exceptions. The quarterly summary should explain what changed, what remains blocked, and which client decisions are required next. Measure service process health without treating one number as proof that every future message will authenticate: - In-scope domains with a named client approver and DNS owner. - Open remediation items with dated evidence. - Issues without an assigned controlling party. - Approved changes with recorded before state, after state, and validation result. - Exceptions without a future review date. - Domains where expected evidence stopped arriving. Use [DMARC QBR reporting: an MSP decision workflow](/learning/dmarc-qbr-reporting) to turn the operational register into a client decision document. Keep technical evidence in the service record and present decisions, risk, and ownership clearly in the client summary. ## Turn client remediation records into a recurring service queue A portfolio remediation workflow needs more than a one-time DNS check. Palisade is agentic DMARC software that analyzes DMARC aggregate-report data, identifies sending sources and authentication or alignment issues, and creates prioritized remediation tickets. It can propose the next policy stage when the evidence indicates readiness, while a human reviews the evidence and applies the change. [Book a demo](https://calendly.com/sam-palisade/30min) or [start with Palisade](https://app.palisade.email/signup) to discuss a multi-client DMARC workflow built around domain ownership, remediation evidence, client approval, and exception review. Palisade does not authorize client changes, change DNS policy without the required access and approval, prove every future message will authenticate, or guarantee how receiving systems handle mail. ## Sources and further reading - [Palisade documentation](https://docs.palisade.email/) - [DMARC audit template for MSPs](/learning/dmarc-audit-template-for-msps) - [DMARC policy rollout across client domains](/learning/dmarc-policy-rollout-across-client-domains) - [DMARC QBR reporting: an MSP decision workflow](/learning/dmarc-qbr-reporting) ## Frequently asked questions ### What should an MSP collect before starting client DMARC remediation? An MSP should collect the client and domain scope, client approver, DNS owner, known sending paths, public-record evidence, sender ownership, proposed actions, approval state, validation result, exception owner, and review date. The purpose is to create a traceable operating record, not to assume that one DNS result proves the production path. ### Does a public DMARC check prove that a client's mail is fixed? No. A public DMARC check can inspect published DNS evidence. It does not prove that every sending platform uses the intended configuration, that an exact production message path authenticated, or how a receiving mailbox provider will handle a future message. ### Who approves a client DMARC remediation change? The client should approve changes that fall outside the authority delegated to the MSP. The MSP can prepare evidence, coordinate the change, and document validation. The DNS host and sending-platform owner control their systems unless the client has explicitly delegated that access. ### When should an MSP keep a remediation item as an exception? Keep an item as an exception when required evidence, ownership, approval, or a safe test path is missing. The record should name the exception owner, explain the decision or blocker, and include a future review date. ### Can aggregate reports replace a delivered-message check? No. Aggregate reports can help identify sources and prioritize remediation. A delivered-message check remains useful when the question concerns the authentication result for an exact production path. --- # DKIM fail with domain Canonical: https://www.palisade.email/learning/dkim-fail-with-domain > DKIM fail with domain is not a complete diagnosis. Collect the trusted message result and selector evidence, then repair and retest the same path. `DKIM fail with domain` is an incomplete diagnosis, not a repair instruction. It may refer to a failed delivered-message result, a sender's domain configuration, or a DNS key lookup, but the phrase does not identify which. Preserve the trusted result from the received message and the sending-domain details first. Then change only the component that the evidence identifies and retest through the same production path. ## Quick takeaways - `DKIM fail with domain` does not identify a specific DKIM failure mode. - A received message's trusted authentication result is stronger evidence than a screenshot or a generic status label. - Keep the sending domain, selector, sender, route, and test time together in the incident record. - Do not replace DNS values or sender settings until the failing layer is known. - A public DKIM lookup can inspect published DNS, but it cannot prove that a sender signed a delivered message. - DKIM is one part of [email authentication](/learning), so a DKIM result alone does not settle every DMARC question. ## What does the failure mean? The observable symptom is the literal phrase: ```text DKIM fail with domain ``` That text does not state where it came from, whether it was added by a receiving system, or which domain it refers to. It is therefore insufficient to identify a DNS issue, a sender configuration issue, a signature issue, or a DMARC alignment issue. Before changing a record or enabling a setting, collect the original message source from the receiving mailbox or the sender's official diagnostic view. Record the exact failure text, the domain shown with it, the sending application, the sending time, and the recipient system. If the phrase came from a ticket or copied alert, trace it back to the original evidence. Use the [DKIM learning hub](/learning/dkim) for background on the protocol and operational terminology. For this failure, the immediate task is narrower: establish whether the phrase describes a real delivered message, a published DNS record, or a sender-side setup status. ![Decision flow for separating a DKIM failure phrase into message evidence, DNS evidence, sender evidence, and a same-path retest](/images/editorial/dkim-fail-with-domain/dkim-fail-with-domain-diagnostic-flow.webp "1200x829") *Source: Palisade.* ![Evidence checklist for diagnosing DKIM fail with domain](/images/editorial/dkim-fail-with-domain/dkim-fail-with-domain-evidence-checklist.webp "1200x696") *Source: Palisade.* ## What usually causes it? ### The phrase was copied without the original message evidence A ticket subject, notification summary, or chat message can omit the details needed to diagnose a DKIM result. Without the complete trusted result and the message path, a specific cause remains unknown. Treat this as an evidence gap, not as proof that the DNS record is wrong. Ask for the complete original source or the sender's documented status page before changing any configuration. ### The domain in the phrase is unclear A message can involve more than one domain. The visible From address, the sender account, and a DNS record under investigation may not be the same value. The phrase does not say which one failed. Write down the exact domain as displayed in the original evidence. Do not infer it from a company name, a website domain, or a mailbox address that was not shown with the failure. ### The sender or route has not been identified A domain can send mail through more than one application or provider. One route may be under investigation while another is unaffected. The phrase does not identify the application, relay, campaign platform, or recipient that produced it. Start with the failed message's source and map the route used for that message. A configuration change made for a different sender can create a new failure without repairing the original one. ### A DNS lookup is being treated as delivered-message proof A public lookup can be useful when the available evidence identifies a domain and selector. It can help inspect what is publicly visible for that DNS name. It cannot show whether the exact sender used that selector, whether a message was signed, or how one recipient evaluated a delivered message. This distinction matters when an operator sees a public result that appears normal while the production message still fails. The two checks answer different questions. ### DKIM and DMARC are being combined before either result is established DKIM and DMARC are related email-authentication concerns, but the phrase alone does not establish a combined failure. If the message evidence later shows that DKIM passed, investigate the separate domain relationship relevant to DMARC with the [DMARC alignment guide](/learning/check-dmarc-alignment). Do not describe that as a DKIM repair unless the original evidence supports it. ## How do I diagnose the failure? ### 1. Preserve the original failure context Save the original message source or the original sender diagnostic output. Keep a redacted working copy for tickets and retain the unredacted original only where your organization permits it. Capture these fields without filling gaps from memory: - Exact failure text - Domain shown with the result - Sender application or account - Sending timestamp and recipient system - Full message route, if available - Whether the message was forwarded or relayed - Any selector value shown in the original evidence Do not use a rewritten or summarized version of the failure as the technical record. ### 2. Identify the domain that the evidence actually names Compare the domain in the failure evidence with the visible From domain and the domain configured in the sending application. Record differences rather than assuming they are equivalent. If the sender's account settings show generated DKIM DNS values, use the provider's current official documentation and the values generated for that account. Do not substitute an example selector, another account's DNS target, or a value copied from an unrelated domain. > Changing a DKIM DNS record before identifying the sender and exact domain can interrupt mail for an otherwise working route. Keep the previous value and an approved rollback path before any DNS change. ### 3. Separate DNS evidence from message evidence When the original evidence includes a domain and selector, use the [DKIM checker](/tools/dkim) to inspect the public DNS side of the investigation. Record the lookup time and the exact input used. A DNS check is useful only for the named lookup target. It does not prove that the production sender used that record, that the sender applied a signature, that the receiving system trusted a result, or that future messages will pass. Keep the DNS result alongside the received-message evidence. Do not replace one with the other. ### 4. Confirm the sender's current status Use the sending provider's official account documentation and status view for the exact sender account. Check whether its displayed domain or selector matches the evidence from the failed message. If the sender account is not known, stop before changing sender-side settings. Identify the application that sent the failed message first. This may require a mail administrator, campaign owner, or the team that operates the outbound service. ### 5. Compare one controlled same-path test After the evidence identifies the likely affected route, send a new test through the same application, domain configuration, recipient type, and relay path. Do not treat a test from another provider or an unrelated mailbox as confirmation. Record the new message source and compare it with the original evidence. The result should answer one bounded question: did the same path produce the same observable failure after the specific repair? ## How do I fix it? ### Repair the sender configuration only when it is the identified layer If the sender's official status identifies a domain configuration problem for the same account and route, use that provider's current instructions and the account-generated DNS values. This changes sender authentication configuration. Do not publish, reuse, or adapt generated selectors, CNAME targets, public-key values, or tokens from another account. Those values are account-specific. ### Repair DNS only when the named lookup target is the issue If the investigation identifies a public DNS issue for the same domain and selector, correct only that record through the authoritative DNS provider. Preserve the prior value and confirm the exact target before saving. A DNS change affects published authentication material. It does not prove that the sender has begun using the corrected configuration, and it does not explain a recipient's private delivery decision. For DNS-management context, the [GoDaddy DKIM record guide](/learning/add-dkim-record-godaddy) can help when GoDaddy is the authoritative DNS provider. Use the sender's official setup instructions for the actual values. ### Repair the sending path only when the failing application is known If the original evidence points to one sender or relay, make the smallest approved change in that route. Keep unrelated sending applications unchanged until they have their own evidence. Do not loosen a DMARC policy as a DKIM repair. A DMARC policy change affects requested enforcement. It does not establish a missing DKIM fact or correct an unknown sender configuration. ### Escalate an unresolved receiver decision with the original evidence If public DNS and sender configuration appear consistent but the same recipient still reports the failure, retain the original message source and escalate through the relevant sender or recipient support channel. The receiver's own evidence is needed to explain its decision. Do not claim that a public lookup proves why an individual recipient rejected or filtered one message. ## How do I validate the repair? Repeat the test through the exact application and route that produced `DKIM fail with domain`. Check the result in four separate places where applicable: - DNS: confirm the intended record through the authoritative DNS provider and a public lookup. - Vendor: confirm the sending provider's current domain or authentication status for the same account. - Message: inspect a newly delivered message from the same production path. - DMARC: after data accumulates, review aggregate-report evidence for the sending source and domain. A passing sender status is not proof of a delivered-message result. A passing DNS lookup is not proof that the application signed the message. Keep the repaired test, the original failure, the change record, and rollback details together. ## Check the public DKIM evidence for this domain If your original evidence identifies a domain and selector, inspect the published record before changing it. [Check the DKIM record](/tools/dkim) A public DKIM check cannot inspect private keys, prove that the sending application signed the message, monitor every production route, or explain why one recipient reported this failure. If the DNS record is present but your team needs to track which production sources still show authentication or alignment issues over time, [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=email_authentication&utm_content=dkim-fail-with-domain). Palisade analyzes DMARC aggregate-report data, identifies sending sources and authentication or alignment issues, and creates prioritized remediation tickets. A human reviews the evidence and applies any change. ## Sources and further reading - [Palisade DKIM checker](/tools/dkim) - [Palisade DKIM learning hub](/learning/dkim) - [Email authentication guide](/learning) - [Check DMARC alignment in a delivered message](/learning/check-dmarc-alignment) - [How to add a DKIM record in GoDaddy DNS](/learning/add-dkim-record-godaddy) ## Frequently asked questions ### How to fix a DKIM failure? Repair the one layer your evidence names, then resend through the same sending path. If the sending platform reports a domain or DKIM setup problem, publish the DNS values it generated for that account. If the published record for the named selector is missing or wrong, correct that single record at the authoritative DNS provider. Get the domain, sender, route, and selector from the original message result before you change anything. ### How to enable DKIM for your domain? Generate DKIM keys inside the platform that sends your mail, publish the DNS record it gives you at the selector it names, then turn signing on and send a test message. Follow that provider's current documentation for the exact steps. Use only the values generated for your own account, because selectors, DNS targets, keys, and tokens are account-specific and cannot be copied from another domain. ### What does it mean if an email fails DKIM? A DKIM failure means the receiving system could not verify the message's signature against the public key published in DNS for the signing domain and selector. It can follow from a missing or wrong DNS record, a message the sender never signed, or a change made to the message while it was relayed or forwarded. The phrase `DKIM fail with domain` does not say which of those happened, so read the trusted result in the received message. ### How to fix DKIM and DMARC? Fix the DKIM problem on the affected sending path first, then check whether the signing domain aligns with the visible From domain for DMARC. Those are two separate repairs, and each needs its own evidence from a delivered message. Never loosen a DMARC policy in place of a DKIM fix, because that hides the failure instead of correcting it. ### Can a DKIM checker prove that my email will pass DKIM? No, a DKIM checker cannot prove that, because it only reads the public DNS record for the domain and selector you type in. It cannot see the private key, confirm that your application signs the messages it sends, or predict how a recipient will judge the next one. Pair the lookup with a real delivered message from the same production path. --- # How to set up DKIM for Google Workspace Canonical: https://www.palisade.email/learning/dkim-google-workspace > DKIM G Suite setup: generate a Google Workspace DKIM key, publish its TXT record, start authentication, and validate a delivered message now. Set up DKIM for Google Workspace in the Admin console at [Apps > Google Workspace > Gmail > Authenticate email](https://knowledge.workspace.google.com/admin/security/set-up-dkim). Select the sending domain, generate its DKIM record, publish the exact TXT host and value Google provides, then select Start authentication. The [DKIM selector](/learning/glossary/dkim-selector) and public key are generated for that Google Workspace account and domain, so do not reuse values from another tenant, domain, or example. ## Quick takeaways - Google Workspace DKIM setup requires access to the Admin console and the domain's authoritative DNS. - Google documents a 24 to 72 hour wait for DKIM key generation after Gmail is first enabled. - Google Workspace offers 2048-bit and 1024-bit DKIM keys and recommends 2048-bit keys when DNS supports them. - Publish the generated TXT record before selecting Start authentication. - A public DKIM record does not prove that the production Gmail path signs mail or that DKIM aligns for DMARC. - Validate DNS, Google Workspace status, a newly delivered message, and DMARC reports as separate checks. ## What should I check before configuring Google Workspace? Confirm that Google Workspace sends the mail in scope. Employee mailbox mail, marketing-platform mail, and transactional mail can use different systems and different DKIM keys. This guide covers mail sent through Google Workspace Gmail. You need a Google Workspace administrator account with the permissions required to manage Gmail settings, plus approval and access to edit the sending domain's authoritative DNS zone. Google's [DKIM setup instructions](https://knowledge.workspace.google.com/admin/security/set-up-dkim) state that Gmail must be enabled and can require 24 to 72 hours before a DKIM key is available for a newly activated service. Identify the visible From domain you expect to protect. A domain alias or subdomain may need its own selection in the Admin console and its own DNS change. If outbound mail passes through a gateway that modifies headers or message bodies, include that route in testing because a modification after signing can invalidate a DKIM signature. > Copy DNS values from the account and domain you are configuring. Do not publish selectors, targets, tokens, or hostnames from another account or from an online example. For protocol background before making the DNS change, see [what DKIM is and how it works](/learning/dkim). ## Which setup method should I use? Use the DKIM record generated in the Google Workspace Admin console for the exact domain that sends mail. Google documents `google` as the default selector, but a different selector is appropriate when `google._domainkey` is already in use for that domain. Select a 2048-bit key if the DNS provider supports the record length. Use 1024-bit only when the DNS provider cannot support the longer key. Google Workspace uses a TXT record for this setup. Do not replace an active selector just to match an example. If an existing Google Workspace DKIM key needs replacement, use a separate selector and follow a controlled key-rotation change so messages already in transit can still be verified. The controls below show the documented Google Workspace DKIM configuration context. The path and labels were checked against Google's official setup guidance on 2026-08-13. ![Google Workspace DKIM controls showing the Authenticate email configuration context](/images/editorial/dkim-google-workspace/google-workspace-dkim-controls.png "1750x1450") *Source: [Set up DKIM](https://knowledge.workspace.google.com/admin/security/set-up-dkim), checked 2026-08-13.* ## How do I configure DKIM for Google Workspace? Google's sender guidance says all senders to Gmail need either SPF or DKIM, while bulk senders that send 5,000 or more messages per day to Gmail personal accounts need SPF, DKIM, and DMARC. Review [Google's sender guidelines](https://support.google.com/a/answer/81126) separately if that threshold applies to your organization. ### 1. Open Authenticate email In the Admin console, open [Apps > Google Workspace > Gmail > Authenticate email](https://knowledge.workspace.google.com/admin/security/set-up-dkim). The path is verified from Google's official documentation. Select the domain used in the visible From addresses for the Google Workspace mail route you will test. Check the selected domain before generating anything, especially when the account has multiple domains or aliases. ### 2. Generate the DKIM record Select Generate New Record. Choose the selector and key length, then generate the record. Google displays the DNS host name and TXT record value to publish. Copy the complete values to the approved DNS change. The value is account-specific configuration, even though the public key is intentionally published in DNS. Do not place a generated key in a reusable DNS template. ### 3. Publish the Google Workspace DNS record Google's [DKIM instructions](https://knowledge.workspace.google.com/admin/security/set-up-dkim) provide the host and value for the selected domain. DKIM verifiers query the selector under `_domainkey`, and [RFC 6376 defines the DKIM public-key record syntax](https://www.rfc-editor.org/rfc/rfc6376). **Record type:** `TXT` **Host, illustrative only:** ```text google._domainkey ``` **Value, illustrative only:** ```text v=DKIM1; k=rsa; p=<public-key-generated-by-google-workspace> ``` > Do not publish this example. Generate the real host and complete TXT value in the Google Workspace Admin console for the account and domain you are configuring. Some DNS providers append the zone name automatically. If your DNS zone is `yourdomain.com`, entering `google._domainkey.yourdomain.com` into a host field that appends the zone can create `google._domainkey.yourdomain.com.yourdomain.com`. Check the final fully qualified owner name before saving, then compare the published record with Google Workspace using [Google's DKIM troubleshooting guidance](https://knowledge.workspace.google.com/admin/security/troubleshoot-dkim-issues). ![Google Workspace DKIM record fields showing the DNS host and TXT value area](/images/editorial/dkim-google-workspace/google-workspace-dkim-record-fields.png "1600x900") *Source: [Set up DKIM](https://knowledge.workspace.google.com/admin/security/set-up-dkim), checked 2026-08-13.* ### 4. Start authentication in Google Workspace Wait until the exact generated TXT record resolves publicly, then return to Authenticate email and select Start authentication. Google documents that the Admin console can take up to 48 hours to recognize a correct DNS update. Record the time the DNS answer appeared and the time authentication was started. If Google still reports a DNS issue, compare the authoritative DNS answer with the complete generated value before editing the record again. ### 5. Send a real test message Send a new message through the same Google Workspace path that users or customers receive. Send it to a mailbox where you can inspect the raw message source. Do not use a message sent before authentication started. Google notes that a message sent from an account to itself might not be signed, so use a separate receiving mailbox for this test. Test each materially different path, including any outbound gateway or relay. ## How does this setup affect DMARC? DKIM helps DMARC only when the domain in the passing DKIM signature aligns with the visible From domain. A signature can pass cryptographic validation yet fail [DMARC alignment](/learning/glossary/dmarc-adkim-aspf) if its `d=` domain is unrelated to the From domain. [RFC 9989 defines the alignment test](https://www.rfc-editor.org/rfc/rfc9989.html). Use the [DMARC checker](/tools/dmarc) to inspect the published DMARC policy before changing it. A public policy lookup does not show which production senders are aligned or whether a receiver accepted a particular message. For the alignment failure case, see [why a DKIM signature can fail DMARC alignment](/learning/dkim-cname). ## How do I validate the setup? ### Check public DNS Query the exact selector Google generated, including the sending domain: ```bash dig +short TXT google._domainkey.yourdomain.com ``` Compare the authoritative DNS response and at least one public resolver response. You can also use Palisade's [DKIM checker](/tools/dkim) to inspect the publicly available record. A public lookup confirms DNS visibility. It does not prove Gmail is using that selector. ### Check the vendor status in Google Workspace Return to Authenticate email and confirm that authentication is active for the selected domain. This confirms that the Google Workspace account accepted the DNS configuration for that domain. A green Google Workspace status is not proof that every outbound route signs mail. A gateway, relay, or separate sender can use a different configuration. ### Inspect a delivered message Open a newly delivered test message and inspect its raw headers. In a Gmail test mailbox, use [Show original](https://support.google.com/mail/answer/29436) to open them. Confirm that `DKIM-Signature` includes the expected signing domain and selector. Then find the receiver-added authentication result. [RFC 8601 defines the Authentication-Results field](https://www.rfc-editor.org/rfc/rfc8601.html), including `dkim=` results and the `header.d=` and `header.s=` properties used to identify the signing domain and selector. ```text Authentication-Results: receiver.example; dkim=pass header.d=yourdomain.com header.s=google ``` Accept the DKIM setup only when the delivered message shows the expected selector, a trusted receiver result reports `dkim=pass`, and the signing domain aligns with the visible From domain when DKIM is expected to satisfy DMARC. ### Review DMARC reports After aggregate reports accumulate, review Google Workspace traffic separately from other sources that send as the same domain. [RFC 9990 defines the source-level authentication and alignment results in aggregate reports](https://www.rfc-editor.org/rfc/rfc9990.html). They do not replace investigation of an individual failed message. ## Troubleshooting ### Google Workspace cannot generate a DKIM record Confirm that Gmail is enabled for the domain and that the account has the required administrative access. Google documents a 24 to 72 hour wait before key generation can become available after Gmail is activated. ### The DKIM record does not resolve Check the full owner name in authoritative DNS. A duplicated zone suffix, a truncated TXT value, or a record published under the wrong domain are likely causes. If a checker reports no record, compare the queried name with the generated host and review [how to fix a missing DKIM record](/learning/no-dkim-record-found). ### Google Workspace still reports a DNS update problem Compare the exact TXT content from Authenticate email with the authoritative DNS answer. Google documents up to 48 hours for its status to reflect the DNS update. Do not generate a second key or replace the record before confirming that the selected domain, selector, and complete public key match. ### DKIM passes but DMARC fails Compare the visible From domain with `header.d=` in the receiver's Authentication-Results header. A passing DKIM signature from another domain does not provide DKIM alignment for DMARC. Investigate the aligned signing domain before changing the DMARC policy. ### A direct Google Workspace message passes but gateway mail fails Compare raw headers from a direct Gmail route and the gateway route. The gateway may modify signed content, remove a signature, or re-sign with another domain. This is an inference from the differing message evidence, not a Google Workspace diagnosis. Configure the final signing point after required modifications, then retest that same route. ## Check the published Google Workspace DKIM record, then track the remaining senders Use the [DKIM checker](/tools/dkim) to inspect what public DNS returns for the domain and selector you configured. Compare that result with the Admin console and a new delivered message before treating the change as complete. A DNS lookup cannot prove that Google Workspace signs every production message, that the DKIM domain aligns for DMARC, or how a recipient will handle future mail. For IT teams and MSPs that need to identify all sending sources from DMARC aggregate-report data and prioritize the next review, [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=vendor_setup&utm_content=dkim-google-workspace). A human should still review the evidence and apply any DNS or policy change. ## Sources and further reading - [Google Workspace Help: Set up DKIM](https://knowledge.workspace.google.com/admin/security/set-up-dkim) - [Google Workspace sender guidelines](https://support.google.com/a/answer/81126) - [RFC 6376: DomainKeys Identified Mail signatures](https://www.rfc-editor.org/rfc/rfc6376) - [RFC 8601: Authentication-Results header field](https://www.rfc-editor.org/rfc/rfc8601.html) - [RFC 9989: DMARC](https://www.rfc-editor.org/rfc/rfc9989.html) - [RFC 9990: DMARC aggregate-report format](https://www.rfc-editor.org/rfc/rfc9990.html) - [Gmail Help: View a message's full headers](https://support.google.com/mail/answer/29436) ## Frequently asked questions ### Do I need a separate DKIM record for each Google Workspace domain? Yes. Generate and publish the DKIM record for each domain that sends through Google Workspace. The generated selector and public key are associated with the selected domain and Google Workspace account. ### Can I use the default `google` DKIM selector? Yes, if `google._domainkey` is not already in use for that domain. Google documents `google` as the default selector. Use a different selector when an existing active key would conflict, especially during key rotation. ### Does a published Google Workspace DKIM record prove that mail is signed? No. A public TXT record proves only that DNS returns a DKIM public key at that selector. Confirm actual signing by inspecting a newly delivered message from the production Google Workspace route. ### Can DKIM pass while DMARC fails? Yes. DKIM can pass cryptographically while its signing domain does not align with the visible From domain. DMARC requires an aligned SPF or DKIM identifier to pass. ### Should I replace my SPF record when I set up Google Workspace DKIM? No. DKIM setup does not require replacing SPF. Keep one SPF policy record for the domain and merge authorized sending services into that existing record when SPF changes are needed. ### How long does Google Workspace DKIM activation take? Google documents that the Admin console can take up to 48 hours to recognize a correct DNS update after you publish the DKIM record. DNS propagation and the domain's authoritative configuration can also affect when the record becomes visible. --- # DMARC alignment failure Canonical: https://www.palisade.email/learning/dmarc-alignment-failure > DMARC alignment failure means a delivered message lacks an aligned authentication result. Inspect the message path, isolate the sender, repair it, and. A DMARC alignment failure means the receiving system did not accept an authentication result as aligned with the visible From domain for that delivered message. Start with the received message and the exact production sender that created it. Then isolate whether the sender's SPF path, DKIM signing identity, or both need correction. Do not change the DMARC policy to hide the failure. ## Quick takeaways - A DMARC alignment failure must be investigated from evidence tied to the failed message and sending path. - A public DNS record can confirm what is published, but it cannot prove how one message was authenticated by a receiver. - Treat each application, ESP, CRM, and relay as a separate sending source until evidence shows otherwise. - A passing test from a different route does not validate the production route that failed. - Keep technical repair separate from DMARC enforcement policy changes. - Recheck DNS, vendor status, delivered-message evidence, and DMARC reporting after the repair. ## What does the failure mean? DMARC gives domain owners control over how their domains are used in email, according to [dmarcian's overview of DMARC](https://dmarcian.com/). In an operational investigation, an alignment failure is a message-specific signal: the visible From domain and the authentication evidence available to the receiver did not produce the result the receiver required for DMARC. The exact error text and trusted received-message header determine the next step. Preserve them before editing DNS or sender settings. A rendered mail client view is not enough because it can omit the authentication evidence and delivery path details needed for diagnosis. The available evidence establishes the intended outcome, but it does not establish a universal error string or a provider-specific mapping. Record the receiver's wording exactly in the incident ticket: ```text DMARC alignment failure ``` This label identifies the incident category. It does not prove whether the issue is SPF, DKIM, a sender configuration, forwarding, a subdomain, or a receiver-specific decision. Use the [DMARC learning hub](/learning/dmarc) for the broader protocol and policy context. For a focused diagnosis, keep the question narrow: which production source sent the message, what domain appeared in From, and what authentication evidence did the receiving system report? ![Decision flow for isolating a DMARC alignment failure from a delivered message, sender path, DNS review, and same-path retest](/images/editorial/dmarc-alignment-failure/dmarc-alignment-failure-diagnostic-flow.webp "1200x980") *Source: Palisade.* ## What usually causes it? ### A third-party sender uses a different authentication identity A marketing platform, CRM, help desk, billing service, or transactional sender can send mail using your visible From domain while relying on its own sending infrastructure. The narrowest investigation is to identify the specific platform and compare its documented domain-authentication setup with the message that failed. Do not assume every vendor behaves the same way. The supplied SendGrid support landing page identifies troubleshooting as a support category, but it does not document an alignment-specific cause or repair. Use the documentation for the exact sender in your route before changing its configuration. ### The SPF path for the production sender does not match the intended domain SPF-related alignment issues are often route-specific. A message sent directly by one platform can differ from a message relayed through another system, even when both use the same visible From address. This is an inference until you inspect the received message and the sender's documented configuration. Check the exact return-path or envelope-sender setting generated for that sender. Do not replace an SPF record based on a generic example because that can remove authorization for another legitimate source. The [Brevo SPF alignment guide](/learning/brevo-spf-alignment) is useful when Brevo is the identified source. It is not evidence for another sender's setup. ### The DKIM signing identity for the production sender is not the intended domain A sender may be configured to sign with a vendor-managed domain instead of a domain you control. Another common operational issue is that the sender has generated DNS records, but the records were not published correctly or the sender has not verified them. The available material supports that publishing SPF, DKIM, and DMARC records is part of a DMARC implementation workflow, as described by [dmarcian's DMARC implementation overview](https://dmarcian.com/). It does not establish the correct record values for your vendor. Obtain the current values from that vendor's authenticated setup screen or official documentation. ### A subdomain or alternate sending path was overlooked Production mail can leave through a subdomain, regional service, separate business unit, or fallback relay. A test sent from the main domain may pass while a less common route still fails. This is a common investigation branch, not a documented provider conclusion. Compare the exact sender identity, application, route, and visible From domain across both passing and failing messages before making a domain-wide change. ### The team changed policy instead of fixing the sender Changing the DMARC policy affects enforcement and reporting. It does not repair the sender configuration that produced the failed result. Keep the incident focused on the authentication and identity evidence first. > Do not loosen the DMARC policy as a first response to an alignment failure. A policy change can alter how receivers handle mail while leaving the underlying sender configuration unresolved. ## How do I diagnose the failure? ### 1. Preserve the received message and receiver evidence Save the full raw source of the failed message from the receiving mailbox or security system. Keep the original in an access-controlled location. In the investigation record, capture the visible From address, sender application, timestamp, recipient provider, Message-ID, and the receiver's exact failure wording. Redact recipient addresses, customer data, tokens, and message content before sharing evidence outside the incident team. Do not rely on a screenshot of the inbox because it may not show the information required to connect the failure to a sender. ### 2. Identify the exact production sending source Map the message to one sending application or service. Start with the business event that sent it, such as a campaign, support notification, invoice, password reset, or application alert. Write down each handoff in the route: ```text application -> sender platform -> outbound relay -> recipient provider ``` For each stage, identify the owner and whether that stage can set the visible From address, send the message, or apply authentication. This prevents a team from editing the DNS record for one platform when the failed mail came from another. ### 3. Separate public DNS evidence from message evidence Check the published DMARC record for the visible From domain with the [Palisade DMARC checker](/tools/dmarc). Record the result alongside the timestamp of the failed message. A public check can show the record available to the checker. It cannot prove the exact production sending path, the receiver's private decision, whether a sender used the expected identity, or whether future messages will pass. Compare the public result with the preserved received-message evidence before changing anything. ### 4. Review the identified sender's current domain-authentication setup Open the official setup documentation or authenticated settings for the platform that sent the failed message. Confirm the configuration against the platform's own generated values and verification status. Do not copy DNS values from another account, online example, or old ticket. DKIM selectors, CNAME targets, and verification values can be tenant-specific. If the vendor shows a DNS record to publish, use the value generated for your account and retain the prior DNS state for rollback. ### 5. Test one controlled message through the same path Send a small controlled test from the same application, same sender configuration, and same visible From domain. Use the same recipient provider when possible. Avoid validating with a mail client that takes a different route or applies a different sender identity. The useful result is a comparable delivered message, not a generic claim that the domain has a record. ### 6. Compare passing and failing sources If one message passes and another fails, compare the sending applications, configured domains, return paths, DKIM settings, relays, and subdomains. The first meaningful difference is a lead for investigation, not proof by itself. The [guide to checking DMARC alignment in a delivered message](/learning/check-dmarc-alignment) can help keep this comparison centered on message evidence instead of DNS assumptions. ![Evidence checklist for diagnosing a DMARC alignment failure across message headers, sender configuration, DNS, and retesting](/images/editorial/dmarc-alignment-failure/dmarc-alignment-failure-evidence-checklist.webp "1200x582") *Source: Palisade.* ## How do I fix it? ### Repair the identified sender's domain-authentication setup When the failed source is a third-party platform, use that platform's current official setup instructions to configure the domain-authentication option it provides. Publish only the DNS values generated for your own account, then wait for the vendor to show its own verification result. This repair changes sender authentication configuration and DNS. It does not change DMARC enforcement by itself. ### Correct the sender identity used by the affected application When the failed message comes from an application with multiple From-domain or sending-domain choices, set the affected production path to use the approved domain configuration. Make the smallest change that affects the confirmed sender and retain the old configuration until the same-path retest succeeds. Do not apply the change to unrelated applications without evidence. A shared visible From domain does not prove that all applications use the same authentication setup. ### Publish the vendor-generated DNS records accurately If the sender's setup identifies missing or incorrect records, correct only the affected record set. Confirm the hostname, record type, and value against the sender's current account-generated instructions. The following is illustrative only. Do not publish this example as a production record. Your sender generates the real values: ```text TXT example._domainkey.yourdomain.com v=DKIM1; k=rsa; p=example-public-key-from-your-sender ``` A DNS correction changes published authentication data. It does not prove that the sender is signing messages or that every sending path now uses the corrected configuration. ### Keep enforcement changes out of the repair Do not present a more permissive DMARC policy as the solution. If business continuity requires a temporary policy decision, document it separately from the technical repair, the owner approving it, and the conditions for reversing it. A temporary policy decision affects requested enforcement. It does not establish that the sender now has aligned authentication. ## How do I validate the repair? Repeat the original delivery path after the sender configuration or DNS correction is complete. Send a new message from the same application, through the same platform and relay, with the same visible From domain. Preserve the new raw message and compare it with the failed copy. Validate at four layers: - Check the affected DNS record through the authoritative DNS path and at least one public resolver. - Confirm the sender platform's current verification or authentication status, using its own account-generated configuration. - Inspect the new delivered message from the same route and retain the receiver's authentication evidence. - Review DMARC aggregate reporting after data has had time to accumulate for that sender. A green vendor status does not replace a delivered-message check. A passing message does not prove that every application, subdomain, or future sender will authenticate correctly. The [bulk DMARC checker](/learning/bulk-dmarc-checker) can help when the operational task is reviewing multiple published domains, but it does not replace source-by-source message validation. ## Check the DMARC record behind this alignment failure Use the [Palisade DMARC checker](/tools/dmarc) to inspect the published DMARC record for the visible From domain before changing policy. Compare that public DNS result with the received message and the affected sender's verified configuration. [Check the DMARC record](/tools/dmarc) A DMARC record check cannot prove why one receiver rejected one message, repair a third-party sender, monitor every production source, or guarantee future delivery. If the same domain has multiple sending sources or the failure returns after one repair, Palisade is agentic DMARC software that analyzes DMARC aggregate-report data, identifies sending sources and authentication or alignment issues, and creates prioritized remediation tickets. It can propose the next policy step from the evidence, while your team reviews and applies changes. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=dmarc_troubleshooting&utm_content=dmarc-alignment-failure) Palisade does not autonomously change your DMARC policy, repair every sender, or guarantee a receiver's delivery decision. ## Sources and further reading - [dmarcian: DMARC overview](https://dmarcian.com/) - [Palisade DMARC learning hub](/learning/dmarc) - [Palisade DMARC checker](/tools/dmarc) - [Check DMARC alignment in a delivered message](/learning/check-dmarc-alignment) ## Frequently asked questions ### Does a DMARC alignment failure mean the DMARC record is missing? No. A domain can publish a DMARC record and still have a failed message path. Check the received message, the exact sender configuration, and the published record separately. ### Can a DMARC checker prove why a receiver rejected a message? No. A public DMARC check can inspect the published record, but it cannot inspect the receiver's private decision or replace the raw message evidence from the failed delivery. ### Should I change DMARC to `p=none` to fix alignment? No. Changing the DMARC policy changes requested enforcement. It does not correct the sender identity, sender authentication setup, or message path that produced the alignment failure. ### Can one sender pass while another sender using the same From domain fails? Yes. Different applications and third-party platforms can use different sending paths and domain-authentication configurations. Validate each production source with a delivered message from that source. ### Is a vendor's verified status enough to close the incident? No. Vendor verification is one validation layer. Send a new message through the same route, inspect the received evidence, and then review DMARC reporting after it accumulates. --- # DMARC authentication failure: how to diagnose and fix it Canonical: https://www.palisade.email/learning/dmarc-authentication-failure > DMARC authentication failure means a message did not meet DMARC checks. Inspect the received headers, repair the failed SPF or DKIM path, and retest. A DMARC authentication failure means the receiving system could not find an aligned SPF or DKIM result that passed for the message's visible From domain. Start with the received message's authentication evidence, then trace the failing SPF or DKIM path to the system that sends the message. Repair that path and send a new test through the same production route. ## Quick takeaways - DMARC evaluates the visible From domain against authenticated SPF or DKIM identifiers. - A DMARC failure is message evidence, not proof that a DNS record alone is wrong. - The received message's trusted `Authentication-Results` field is the strongest place to start. - Repair the failing SPF or DKIM path before considering a DMARC policy change. - A public DNS check can show the published record, but cannot prove a receiver's decision for one message. - DMARC reports can help identify sending services and IP addresses after report data accumulates. ## What does the failure mean? A DMARC authentication failure occurs when a receiver evaluates a message and cannot use an aligned SPF or DKIM result to satisfy DMARC. [RFC 7489 defines DMARC identifier alignment and evaluation](https://datatracker.ietf.org/doc/html/rfc7489), while [RFC 8601 defines the `Authentication-Results` message header](https://datatracker.ietf.org/doc/html/rfc8601) that receivers can use to record authentication results. The evidence to preserve is the receiver-added authentication result from the exact message that failed. This is an illustrative shape, not a provider error string: ```text Authentication-Results: receiver.example; spf=fail smtp.mailfrom=mail.yourdomain.com; dkim=fail header.d=mail.yourdomain.com; dmarc=fail header.from=yourdomain.com ``` A result like this identifies the domains and mechanisms the receiver evaluated. It does not by itself identify why a sending application selected that envelope domain, why a DKIM signature failed, or what action a particular receiver took. DMARC is separate from SPF and DKIM, but it depends on them. SPF evaluates the SMTP envelope sender or HELO identity. DKIM evaluates a signature attached to the message. DMARC checks whether a passing SPF or DKIM identity aligns with the domain shown to the recipient in the From field. For broader context, see the [DMARC learning hub](/learning/dmarc) and [what DMARC is](/learning/dmarc-cyber-security). ![Decision flow for diagnosing a DMARC authentication failure from receiver headers through SPF and DKIM repair paths](/images/editorial/dmarc-authentication-failure/dmarc-authentication-failure-diagnostic-flow.webp "1200x676") *Source: Palisade.* ## What usually causes it? ### SPF did not pass for the production sending path An SPF result can fail when the sender uses an envelope domain whose published SPF authorization does not cover the IP address or service used for that message. The failure may also be limited to one application, region, relay, or fallback route. Treat the header's `smtp.mailfrom=` value as the identity to investigate. The visible From domain is not enough to establish what SPF evaluated. The [DMARC specification's SPF alignment rules](https://datatracker.ietf.org/doc/html/rfc7489#section-3.1) explain why a passing SPF result still needs an aligned identifier for DMARC. ### DKIM did not pass on the received message A DKIM result can fail because the receiver cannot retrieve a usable public key, the signature is invalid, or a later system changed signed message content. The header's `header.d=` and DKIM selector identify the signing domain and selector to inspect. A DNS record check can help confirm that a public key is published, but it cannot prove that the sending application used the matching private key or that the message remained unchanged after signing. Keep the full raw message source because rendered email hides relevant headers and MIME details. ### SPF or DKIM passed but did not align A message can show a passing SPF or DKIM result and still fail DMARC if the authenticated domain does not align with the visible From domain. This is common when an application sends with a provider-owned envelope domain or signs with a domain unrelated to the brand shown in From. Alignment is a protocol result, not a cosmetic comparison. Confirm the actual values in `smtp.mailfrom=`, `header.d=`, and `header.from=` before changing DNS or sender settings. ### The wrong message path was tested A successful test from a marketing platform does not validate transactional mail, a helpdesk, a CRM, a forwarding service, or an employee mail route. Different applications can use different return paths, DKIM selectors, relays, and signing behavior. This is an inference from the message path, not a receiver-specific diagnosis. Compare the failed message's headers with a passing message from the same application and recipient route. ### A forwarding or intermediary path changed the evidence Forwarding and intermediary handling can affect SPF results because the receiver sees the forwarding server's connection rather than the original sender's. DKIM may remain useful when the signature survives the path, but the received headers determine what happened for that message. Do not assume an original outbound test represents the forwarded copy. ## How do I diagnose the failure? ### 1. Preserve the received message evidence Export the raw source of the failed message before making changes. Record the visible From domain, `Authentication-Results`, `Return-Path`, `DKIM-Signature`, relevant `Received` fields, Message-ID, sending application, recipient provider, and timestamp. Use authentication results added by the receiving system you trust. A forwarded copy may contain authentication results written by another server for a different point in the route. ### 2. Identify the DMARC identity and failed mechanism Read `header.from=` in the DMARC result first. Then compare it with the SPF identity in `smtp.mailfrom=` and the DKIM signing identity in `header.d=`. Use this decision rule: ```text DMARC result: fail SPF pass and aligned: investigate DKIM only if another requirement needs it DKIM pass and aligned: investigate SPF only if another requirement needs it Neither aligned result: repair the SPF path, the DKIM path, or both ``` Do not decide from a DNS record name alone. The received message establishes which identifiers the receiver evaluated. ![DMARC authentication failure diagnostic flow showing message evidence, identity checks, DNS inspection, and repair paths](/images/editorial/dmarc-authentication-failure/dmarc-authentication-failure-dmarc-authentication-failure-diagnostic-flow.png "1600x900") *Source: Cloudflare, https://blog.cloudflare.com/dmarc-management-ga/.* ### 3. Map the sender that produced the failed message Name the application, service account, relay, gateway, and final outbound provider that handled the message. Then identify where the envelope sender is selected and where DKIM signing happens. If the message comes from a platform you do not administer directly, use its documented domain-authentication workflow and its current status page or configuration screen. A green vendor status is useful vendor evidence, but it is not a delivered-message check. ### 4. Inspect the relevant DNS record For the DMARC policy, look up the TXT record at `_dmarc.yourdomain.com`. For SPF, inspect the TXT record for the envelope domain. For DKIM, inspect the selector named in the received `DKIM-Signature`. Use a public check to inspect the published DMARC record: [Check the published DMARC record](/tools/dmarc) A public record check cannot prove which production source sent the failed message, why a receiver evaluated that message as failed, or whether future messages will authenticate. ### 5. Compare a passing and failing message from the same service Send a controlled new message from the same application and compare its raw headers with the failed message. Look for changes in the From domain, envelope sender, DKIM `d=` domain, selector, relay, or intermediary path. Redact addresses, message content, identifiers, and tenant-specific DNS values before sharing the evidence with others. ## How do I fix it? ### Repair the SPF authorization for the actual envelope domain When SPF fails, update the sending service configuration or the SPF record for the envelope domain that appears in `smtp.mailfrom=`. Use the provider-generated values for that account. Do not copy another organization's include mechanism, return-path host, or DNS target. This repair changes SPF authentication. It does not automatically establish DMARC alignment if the envelope domain remains unrelated to the visible From domain. > Do not remove SPF mechanisms or replace a production record without mapping every authorized sender. An incomplete SPF change can interrupt legitimate mail. ### Configure aligned DKIM signing for the sender When DKIM fails or uses a non-aligned signing domain, configure the sending platform to sign with a domain aligned with the visible From domain where its documentation supports that setup. Publish the vendor-generated selector record, then confirm the new message shows the expected `header.d=` value and a passing DKIM result. This repair changes DKIM authentication and can establish DMARC alignment. It does not repair an unrelated SPF failure. ### Correct the application-specific From or return-path setup When SPF or DKIM passes but does not align, correct the application setting that chooses the visible From domain, return-path domain, or DKIM signing domain. Make one change at a time, then resend from that application. Do not loosen `p=` as a repair. Changing the DMARC policy changes requested enforcement or reporting behavior. It does not make SPF pass, validate a DKIM signature, or align an identifier. ### Isolate a post-signing message change When a signature fails only after a gateway, disclaimer service, mailing list, or security product handles the message, identify the first post-signing modification. Remove the confirmed modification if it is unnecessary, or place DKIM signing after the required transformation. This repair addresses DKIM verification. Keep a rollback path for routing or signing changes, and test each outbound route that depends on the changed stage. ## How do I validate the repair? Send a new message through the same application, sender identity, gateway path, content type, and recipient provider that produced the failure. Inspect the new raw source and confirm the receiver reports an aligned passing SPF or DKIM result for the visible From domain. Validate at four layers: - Check authoritative DNS and at least one public resolver for the intended DMARC, SPF, or DKIM record. - Confirm the sending vendor reports the domain or authentication configuration as verified where that status exists. - Inspect `Authentication-Results` in a newly delivered message from the exact production path. - Review DMARC aggregate reports after data accumulates to see whether the source continues to appear and how it authenticates. [DMARC aggregate reports identify the services and IP addresses sending on a domain's behalf](https://www.rfc-editor.org/rfc/rfc9990.html). They are useful follow-up evidence, but they do not replace a received-message check for the incident you are fixing. ## Keep the published policy separate from the message failure Check the current DMARC record before changing DNS, then compare it with the failed message's authentication identifiers. [Inspect the DMARC record](/tools/dmarc) A record inspection can reveal the public policy syntax, but it cannot repair a failed sender configuration or determine a receiver's private disposition for one message. If repeated reports show that multiple production senders need authentication or alignment work, [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=dmarc_troubleshooting&utm_content=dmarc-authentication-failure). Palisade autonomously analyzes DMARC aggregate-report data, identifies sending sources and authentication or alignment issues, and creates prioritized remediation tickets. It can propose the next policy step, while your team reviews the evidence and applies the change. Palisade does not change the DMARC policy itself or guarantee how a receiver will handle a future message. ## Sources and further reading - [RFC 7489: Domain-based Message Authentication, Reporting, and Conformance](https://datatracker.ietf.org/doc/html/rfc7489) - [RFC 8601: Authentication-Results header field](https://datatracker.ietf.org/doc/html/rfc8601) - [Palisade DMARC checker](/tools/dmarc) - [RFC 9990: DMARC Aggregate Reporting](https://www.rfc-editor.org/rfc/rfc9990.html) ## Frequently asked questions ### What causes DMARC failure? DMARC failure occurs when the receiver cannot find a passing SPF or DKIM result that aligns with the message's visible From domain. The received `Authentication-Results` field shows which SPF, DKIM, and DMARC identifiers the receiver evaluated. ### How to solve DMARC issue? Start with the failed message's raw headers, identify whether SPF, DKIM, or alignment failed, and repair the configuration for the sending application that produced it. Then resend through the same path and inspect the new receiver-added authentication results. ### What is DMARC authentication? DMARC authentication is the evaluation of whether a message has an aligned passing SPF or DKIM result for the visible From domain. [RFC 7489 describes the DMARC evaluation and alignment model](https://datatracker.ietf.org/doc/html/rfc7489). ### How do I fix authentication failed on my email? Open the recipient's raw message headers and find which check actually failed: SPF, DKIM, or alignment with the visible From domain. Repair the narrowest thing that result names, which is usually the sending application's envelope domain, its DKIM signing setup, or one DNS record. Then send a new message from the same application and read the fresh authentication results the receiver adds. ### Does a passing DMARC record check prove email will pass DMARC? No, a passing record check does not prove your mail will pass DMARC, because it only reads the policy published in DNS. It cannot show whether an application uses an aligned envelope sender or an aligned DKIM signature, and it cannot predict how a receiver will judge the next message. A delivered message's `Authentication-Results` header is the evidence that settles it. --- # DMARC failure for domain: how to diagnose it Canonical: https://www.palisade.email/learning/dmarc-failure-for-domain > DMARC failure for domain results need domain-specific DNS and message evidence. Collect the failure signal, isolate its scope, then retest the same path. A DMARC failure for a domain is not specific enough to fix from a scan label alone. Start with the exact result, then collect the domain's public DMARC DNS answer and a redacted received-message header or aggregate-report evidence from the affected sending path. Repair only the condition those records show, then send a new test through that same path. For broader context, see the [DMARC learning hub](/learning/dmarc). ## Quick takeaways - A scan result can identify a DMARC policy concern, but it does not prove why a particular message failed. - Preserve the exact scan result, DNS response, and trusted received-message evidence before changing records. - A public DMARC lookup checks published DNS, not every sending service that uses the domain. - A reporting-address authorization issue is distinct from a general domain authentication failure. - Do not loosen a DMARC policy as a substitute for identifying the failing sending path. - Retest with a new message sent through the same application, route, and recipient path. ## What does the failure mean? "DMARC failure for domain" can describe a result from a domain-security scan, a received-message authentication result, an aggregate-report finding, or a receiver rejection. Those are different evidence types. They do not support the same repair. One published domain scan presents a separate DMARC result with this exact string: ```text DMARC Policy: Score 0 of 10 ``` [The published scan result](https://easydmarc.com) shows that a domain-security scan can assess DMARC policy separately from SPF and DKIM. It does not identify an affected message, the sender that produced it, or a mailbox provider's decision. Treat the scan as a signal to collect evidence, not as an instruction to change DNS. Record the domain name, the time of the result, and the exact text. Then determine whether the issue is limited to the published record, appears in a real received message, or appears in DMARC reporting. A reporting destination can introduce its own authorization problem. If the concern is specifically about an external reporting address, use the focused guidance on [DMARC RUA and RUF domain authorization](/learning/dmarc-rua-ruf-domain-authorization). Do not treat that issue as proof that all mail sent by the domain has failed. ![Diagnostic flow for separating a DMARC scan result from DNS evidence, received-message evidence, and same-path validation](/images/editorial/dmarc-failure-for-domain/dmarc-failure-for-domain-diagnostic-flow.webp "1200x829") *Source: Palisade.* ## What usually causes it? ### The result is only a policy scan result A scan can report a DMARC policy result independently of SPF and DKIM. That result can justify inspection of the public DNS record, but it does not establish a message-level cause. This is the most likely interpretation when the only evidence is a score, warning, or dashboard label. The narrow next step is to save the exact result and inspect the published DMARC record. Do not change the record merely to change a scan score. ### The failing path has not been identified A single domain can send mail through more than one application, provider, or route. A scan of public DNS does not show which production source generated the message under review. This is an operational inference from the evidence gap. Identify the application, sending service, recipient provider, approximate send time, and Message-ID for the affected message. Without those details, a broad DNS change can affect mail that was not involved in the failure. ### The evidence comes from a different message copy Forwarded, resent, or modified copies may not represent the original production path. A scan result also cannot substitute for the recipient's received message. Use the complete raw source from the receiver for the exact affected message. Keep private addresses, tokens, and customer data out of tickets or shared diagnostics. A screenshot of a mail client does not preserve the header evidence needed to compare paths. ### A reporting-address issue is being treated as a sending failure DMARC reporting configuration and production message authentication are separate areas of investigation. If the observed failure concerns an aggregate-report destination, isolate that authorization question before making claims about messages sent by the domain. Keep the evidence sets separate. A corrected reporting destination does not prove that a sender's messages will pass later checks, and a delivered message does not by itself validate every reporting destination. ### A receiver rejection is being inferred from a public lookup A public DNS result can reveal the record published at the time of the lookup. It cannot prove a receiver's private decision about one message or predict future placement. If the observable symptom is a rejection, preserve the exact rejection text and the received-message evidence. The related guide for [550 message rejected due to sender's DMARC policy](/learning/550-message-rejected-due-to-senders-dmarc-policy) is useful only when that is the actual symptom. ## How do I diagnose the failure? ### 1. Preserve the strongest available evidence Start with the received message if one exists. Save its complete raw source and record the Message-ID, sending time, sender application, sending domain, recipient provider, and delivery outcome. If no message is available, preserve the scan result exactly as shown. State that the current evidence is a DNS or scan observation, not a message-level finding. Avoid filling gaps with assumptions about SPF, DKIM, alignment, or a receiver's policy. ### 2. Inspect the published DMARC record Run the sending domain through the [DMARC checker](/tools/dmarc). Save the result with the lookup time and compare it with the domain in the observed failure. The check can inspect a public DNS answer. It cannot inspect private sender configuration, identify every application using the domain, prove a continuous state, or explain a single receiver decision. Use a structural record shape only as a comparison aid: > Do not publish this example as a production record. The correct values and any reporting destinations must be based on the domain's own approved configuration. ```text Illustrative only Host: _dmarc.yourdomain.com Type: TXT Value: v=DMARC1; p=none ``` Record what the checker returns without copying values from another tenant or provider account. If the result differs across tools, note each tool, time, and resolver behavior before editing DNS. ### 3. Tie the result to one sending path Map the affected path in plain language: ```text application -> sending service -> outbound route -> recipient provider ``` For each stage, record the owner and the evidence available. The purpose is to distinguish a public-record concern from a problem confined to one service or route. Do not infer the responsible service from the visible From address. Use the received message, approved service logs, or aggregate-report evidence that is available to the domain owner. ### 4. Separate a reporting issue from a sending issue If the evidence concerns report delivery or a reporting destination, diagnose that configuration separately. The [DMARC RUA and RUF domain authorization guide](/learning/dmarc-rua-ruf-domain-authorization) covers that narrower question. If the evidence concerns a received message, keep the raw header and the sending-path record together. This prevents a reporting repair from being mistaken for a repair to the production mail path. ### 5. Define the smallest supported change Write down the exact condition supported by the evidence and the change that addresses only that condition. Include the owner, expected result, rollback step, and the same path that will be used for retesting. If the evidence only shows a scan score, the supported action may be continued investigation rather than a DNS change. That is a valid outcome. ## How do I fix it? ### Correct only the confirmed domain configuration issue When the public lookup identifies a record issue that the domain owner can verify, correct that specific DNS configuration through the authorized DNS process. Preserve the prior value and change window so it can be restored if the change causes an unexpected result. This changes published DNS. It does not prove that every sender uses the intended configuration or that a receiver will accept every future message. ### Repair the confirmed sending path When received-message or report evidence identifies one production source, make the smallest approved change in that source's configuration or route. Keep the change scoped to the source and domain involved. Do not apply a domain-wide change because one application is suspected. A sender-specific repair requires evidence from that sender's actual production path. ### Treat reporting authorization as a separate repair When the evidence identifies a reporting-address authorization issue, repair that authorization through the owning domain's approved DNS process. Do not reuse account-generated destinations, tokens, or hostnames from examples or other tenants. This repair changes reporting configuration. It does not repair an unrelated received-message failure. > Do not reduce the DMARC policy to make a scan warning disappear. A policy change affects requested enforcement. It does not identify the source of a domain-specific failure or repair an unverified sending path. ## Investigate this with your coding agent Use this after collecting a public DNS result and a redacted header from the affected message. Remove recipient addresses, tokens, private keys, and customer content before sharing either input. ```agent Problem: A domain has a reported DMARC failure, but the available evidence may be limited to a public DNS result and one redacted received-message header. Evidence: Domain name, lookup timestamp, public DMARC DNS result, redacted Authentication-Results and relevant message headers, Message-ID, sending application, and recipient outcome. Repository scope: Read-only inspection of the domain's public DNS record and the supplied redacted message-header text. Constraints: Inspect before editing. Do not apply changes until I approve the proposed diff. Do not request or process private keys, tokens, unredacted headers, customer data, or production credentials. Requested output: Diagnosis, minimal proposed change, rollback, and unknowns. Verification: Run a new lookup after any approved DNS change and send a new test through the same application, outbound route, and recipient path. Stop if: Credentials, private data, production mutation, or missing evidence is required. ``` ## How do I validate the repair? Repeat the same diagnostic path that produced the original result. If the original evidence was a public lookup, perform a new lookup after the authorized DNS change and record the result and time. If it was a received message, send a new message through the same application, service, route, and recipient provider. Check four layers where they apply: - DNS: confirm the published result through the authoritative DNS process and at least one public lookup. - Vendor: check the sender platform's current status when the platform provides a relevant verification state. - Message: inspect the new received message from the same path, not a forwarded copy or a different test service. - DMARC: review aggregate-report evidence after data has had time to accumulate. A green vendor status is not a received-message check. A passing public lookup is not proof that the application sent through the expected route. Keep the new evidence with the original incident record and compare only like-for-like tests. ## Check the DMARC record before expanding the fix If the evidence so far is a policy score or public-record result, [check the domain's DMARC record](/tools/dmarc) before changing a sender configuration. Compare the result with the exact domain and sending path under review. For an ongoing estate of domains or senders, Palisade is agentic DMARC software that analyzes DMARC aggregate-report data, identifies sending sources and authentication or alignment issues, and creates prioritized remediation tickets. It can propose a next policy step when the evidence supports it, while a human reviews the evidence and applies any change. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=dmarc_troubleshooting&utm_content=dmarc-failure-for-domain) A public DMARC check and Palisade's report analysis do not prove why one receiver rejected one message, repair a sender automatically, or guarantee future delivery. ## Sources and further reading - [Published domain-security scan showing a DMARC Policy result](https://easydmarc.com) - [Palisade DMARC checker](/tools/dmarc) - [DMARC learning hub](/learning/dmarc) - [DMARC RUA and RUF domain authorization](/learning/dmarc-rua-ruf-domain-authorization) ## Frequently asked questions ### Does a DMARC scan score prove that messages are failing? No, because a scan score describes the published record rather than any message that was actually sent. It cannot name the message, the sending service behind it, a recipient's decision, or a future delivery result. Collect a received message or aggregate-report evidence before you act on a score. ### Can I fix a domain DMARC failure by changing the policy? No, because the policy controls the enforcement a domain requests, not the reason a message failed. Collect the public DNS answer and evidence from the affected sending path first, then change only the condition that evidence supports. ### Should I start with the DNS record or the message header? Start with the received message whenever you have one, because it is the only evidence that shows what happened on the real sending path. Fall back to a public DNS lookup when the only evidence you hold is a scan result or a concern about the published record. ### Can a DMARC checker identify every sender that uses my domain? No, because a checker reads public DNS, and DNS does not list the applications sending for your domain. To build that inventory, review DMARC aggregate-report data once enough of it has accumulated. ### Is a reporting-address issue the same as a sending failure? No, a reporting-address authorization issue is a separate question about where DMARC reports are allowed to be sent. Diagnose it on its own, and do not read it as evidence that messages from the domain failed authentication. --- # DMARC feedback type auth failure Canonical: https://www.palisade.email/learning/dmarc-feedback-type-auth-failure > DMARC feedback type auth failure needs the original report or message evidence before a repair. Preserve the evidence, identify its source, and retest. `DMARC feedback type auth failure` is not enough evidence to identify a DMARC fault or choose a repair. Preserve the complete report, its delivery context, and any related received-message headers before changing DNS or policy. The phrase may refer to a report field, a recipient-specific diagnostic, or another system's label. The narrowest safe next step is to obtain the original evidence and identify the specification or provider that produced it. ## Quick takeaways - The phrase `feedback type auth failure` does not identify a specific DNS, SPF, DKIM, alignment, or DMARC-policy fault on its own. - Do not change a DMARC policy to make an unclear failure label disappear. - Save the original report or message source before forwarding, editing, or copying fragments into a ticket. - The system that generated the label is part of the evidence needed to interpret it. - A public DMARC record check can inspect a published record, but it cannot explain an individual report label without the report itself. - Validate any repair through the same production sending path that produced the evidence. ## What does the failure mean? The observable symptom is the exact text below: ```text feedback type auth failure ``` That text alone does not establish what failed. It does not show a sending domain, an SPF result, a DKIM result, an identifier-alignment result, a policy disposition, or the receiver that generated the text. The [RFC Editor describes the RFC Series as the authoritative source for RFCs](https://www.rfc-editor.org/). A reliable interpretation needs the canonical specification that defines the field or the original receiver or reporting-system evidence that contains it. Without either, assigning the phrase to a DMARC authentication condition would be an inference, not a documented diagnosis. Keep the evidence in its original form. A copied label can lose the surrounding header fields, report metadata, sender identity, timestamp, or provider context needed to determine its meaning. The foundational [DMARC learning guide](/learning/dmarc) can help distinguish DMARC records, authentication outcomes, and reporting concepts once you know which artifact you have. ![Diagnostic flow for preserving the original feedback, identifying its producing system, matching it to authoritative documentation, and retesting the same sending path](/images/editorial/dmarc-feedback-type-auth-failure/dmarc-feedback-type-auth-failure-diagnostic-flow.webp "1200x906") *Source: Palisade.* ## What usually causes it? ### The phrase was separated from its original report A ticket, chat message, or monitoring alert may retain only a short label. That can remove the fields needed to establish whether the text belongs to a DMARC feedback report, a message-authentication result, or an application-specific status. This is the most likely explanation when no original report, complete raw message, or provider diagnostic accompanies the phrase. It is an evidence limitation, not a documented DMARC failure mode. ### A reporting or receiving system used its own label A mailbox provider, security gateway, reporting service, or internal tool can display its own status labels. The available material does not identify a provider that defines `feedback type auth failure`, so the label cannot be treated as universal DMARC terminology. The [Google Workspace Help Center](https://knowledge.workspace.google.com/) is a general support entry point. It does not, by itself, define this phrase or provide a repair path for it. Treat a provider label as provider-specific until that provider's current documentation or original diagnostic confirms its meaning. ### The evidence may concern message authentication, not the published DMARC record A published DMARC record and a received message are different evidence layers. A record can be syntactically present while the exact production message still has an authentication or alignment issue. The inverse can also occur when a copied alert refers to a historical condition rather than the record currently visible in DNS. This is an inference from the missing context. Do not assume that editing the DMARC record will address the phrase. ### The label may refer to a report-delivery or processing problem The available text does not show whether `auth failure` describes a reported event, a report-delivery issue, or processing performed by the system that displayed it. A product marketing page is not a protocol definition. For example, the [Valimail website](https://valimail.com/) does not provide a canonical definition of this exact label. Do not map the phrase to report delivery, SPF, DKIM, or alignment until the producing system's evidence supports that mapping. ![Evidence checklist for diagnosing an unclear DMARC feedback label](/images/editorial/dmarc-feedback-type-auth-failure/dmarc-feedback-type-auth-failure-diagnostic-flow.webp "1200x630") *Source: Palisade.* ## How do I diagnose the failure? ### 1. Preserve the complete original artifact Obtain the original feedback report, alert payload, or raw message that contains `feedback type auth failure`. Keep its unmodified copy in the incident record. Record where it came from, when it was received, the affected domain, and the system that displayed it. If the text came from a received email, save the full source rather than a screenshot. If it came from a dashboard or API, export the available event details and retain the exact field names. Redact recipient addresses and customer data before sharing evidence outside the team. ### 2. Identify the system that produced the label Determine whether the phrase came from a mailbox provider, a DMARC-report processor, a gateway, an ESP, or an internal alerting system. Look for the report sender, product name, API endpoint, message headers, or dashboard URL that establishes origin. Do not use a generic web search result as the definition. Find the producing system's official documentation or support diagnostic that uses the same wording. If you cannot identify the producer, keep the incident classified as unresolved evidence rather than as a DMARC authentication failure. ### 3. Separate DNS evidence from message evidence Inspect the artifact for a domain, a message identifier, a timestamp, and any stated authentication result. Only then decide which layer needs inspection. - If the artifact identifies a published DMARC record problem, inspect the record. - If it identifies a delivered or rejected message, preserve the receiver's message evidence and follow that exact sending path. - If it identifies a reporting-system issue, use that system's documented diagnostic process. - If it identifies none of these, request the full artifact before making a change. The [DMARC aggregate report format guide](/learning/dmarc-aggregate-report-format) is useful when the evidence is confirmed to be an aggregate report. It does not establish that this phrase comes from one. ### 4. Compare the exact domain and timestamp Match the evidence to the production sender, visible From domain, sending service, recipient system, and time of the event. Avoid testing a different domain or a manually forwarded copy of the message. A current public DNS result can differ from the state at the time the event occurred. Record both the incident time and the time of any later DNS lookup. This keeps a later record change from being mistaken for the cause of an earlier label. ### 5. Determine whether alignment evidence exists If the original artifact names an alignment failure, use the complete message and the source documentation that defines the result. The [DMARC alignment failure guide](/learning/dmarc-alignment-failure) covers the related troubleshooting topic. Do not assume alignment failed merely because the phrase contains `auth failure`. When the original evidence has no explicit authentication or alignment result, stop the diagnosis at that point. Request the missing report or provider diagnostic. ## How do I fix it? ### Repair the evidence collection first When only the phrase is available, the repair is to recover the original report, message source, or provider diagnostic. This does not change authentication, alignment, reporting, or enforcement. It gives you the evidence needed to select a technical repair safely. Document the source system and preserve a redacted incident copy. If the source cannot provide additional evidence, record that the condition remains unclassified. ### Apply only the repair supported by the identified source Once official documentation or complete evidence defines the condition, change only the component it identifies. A message-authentication issue needs message-path evidence. A published-record issue needs DNS evidence. A reporting-system issue needs the reporting system's documented remedy. > Do not relax the DMARC policy as a response to an unexplained label. A policy change affects requested enforcement. It does not establish why this phrase appeared or repair an unknown authentication condition. Keep a rollback plan for any confirmed change. Record the previous DNS record, sending configuration, or reporting configuration before changing it. Revert the specific confirmed change if the same sending path produces a new failure or interrupts expected mail flow. ### Do not treat a public lookup as proof of the incident A public record check can help inspect the currently published DMARC record after the evidence identifies a domain. It cannot inspect a private report payload, prove an individual receiver's decision, repair authentication, or show every production sender that used the domain at the incident time. ## How do I validate the repair? Repeat the same sending path that produced the original evidence. Use the same application, sending domain, recipient system, and message type where possible. Preserve the new report or raw message alongside the original. Validate at the applicable layers: - Check authoritative DNS and at least one public resolver when the confirmed repair changed a DMARC record. - Check the producing provider's current status when its documentation identifies a provider-side condition. - Check the full received-message evidence when the issue concerns a delivered or rejected message. - Review DMARC aggregate reporting after data accumulates when the confirmed issue concerns production sending sources. A successful retest means the original, identified condition no longer appears on the same path. It does not guarantee future authentication, delivery, or a receiver's private placement decision. ## Check the published DMARC record after you identify the domain If the original evidence identifies the sending domain, use the [DMARC checker](/tools/dmarc) to inspect the record currently published for that domain. Compare the result with the preserved report or message evidence before changing policy. [Check the published DMARC record](/tools/dmarc) A DMARC record check cannot define `feedback type auth failure`, inspect a private feedback report, prove why one receiver produced a label, or replace same-path message evidence. ## Sources and further reading - [RFC Editor and the RFC Series](https://www.rfc-editor.org/) - [Google Workspace Help Center](https://knowledge.workspace.google.com/) - [Valimail](https://valimail.com/) - [Palisade DMARC learning guide](/learning/dmarc) - [Palisade DMARC checker](/tools/dmarc) ## Frequently asked questions ### How do I fix DMARC authentication failure? Work out which check failed before you change anything, because DMARC fails when neither SPF nor DKIM produces a passing result that aligns with your From domain. Read the `Authentication-Results` header on a real failing message, or the aggregate report row for that source, to see which of the two broke. Then fix that one sending service and retest through the same path. ### What causes DMARC failure? DMARC fails when neither SPF nor DKIM gives a passing result that aligns with the domain in your visible From address. In practice that usually means a sending service nobody added to SPF, a DKIM signature that is missing or signed with a different domain, or forwarding that breaks SPF along the way. The report or the message headers will tell you which of those it was. ### How to solve DMARC issue? Classify the issue first, then fix only what the evidence names. Work out whether you are looking at a problem in the published DNS record, an authentication failure on a real message, or a reporting problem, because each has a different fix and a different owner. Never loosen the DMARC policy as a shortcut around the diagnosis. ### How to authenticate DMARC? Publish a DMARC TXT record at `_dmarc.yourdomain.com`, then make SPF or DKIM pass and align for every service that sends as your domain. DMARC has nothing of its own to authenticate: it reads the SPF and DKIM results and checks whether either one matches your visible From domain. Confirm it worked by sending through the same path again and reading that message's authentication results. --- # DMARC Microsoft 365 Canonical: https://www.palisade.email/learning/dmarc-microsoft-365 > DMARC Microsoft 365 setup requires verified Microsoft admin guidance, account-specific DNS values, and four-layer validation before publishing changes. DMARC for Microsoft 365 must be configured from current Microsoft documentation and the specific Microsoft 365 tenant that sends mail. The available Microsoft Learn landing page identifies Learn as Microsoft's official documentation platform, but it does not provide a Microsoft 365 DMARC procedure, current admin-center path, DNS records, or sender requirement. Do not publish a DMARC record or change Microsoft 365 authentication settings from an example. ## Quick takeaways - A Microsoft 365 DMARC configuration needs current Microsoft documentation for the tenant and sending path in scope. - DNS values for a sending domain must come from the account and domain being configured. - A public DNS result does not prove that Microsoft 365 signs or sends a delivered message as expected. - A vendor status indicator does not replace inspection of a newly delivered message. - DMARC reporting is separate evidence from DNS, vendor status, and message-header results. - Use the [DMARC learning hub](/learning/dmarc) for Palisade guidance on the wider DMARC policy workflow. ## What should I check before configuring Microsoft 365? First, establish which Microsoft 365 sending path is in scope. A domain can be used by employee mail, applications, relays, marketing platforms, or other services. Each path needs its own evidence before an authentication or DMARC policy change is accepted. Confirm that the person making the change has authority to access the Microsoft 365 tenant and the authoritative DNS zone for the visible From domain. Keep a change record with the domain, tenant, sending path, DNS owner, approver, test mailbox, and rollback owner. Microsoft's [Learn platform](https://learn.microsoft.com/) is the appropriate official documentation location to use when confirming the current Microsoft 365 process. Do not infer a current admin-center path or setting name from an old procedure, a search result, or another tenant. > Copy DNS values from the account and domain you are configuring. Do not publish selectors, targets, tokens, or hostnames from another account or from an online example. For broader vendor setup planning, see Palisade's [vendor email authentication guidance](/learning/esp-setup). It can help separate the sender that creates a message from the domain and DNS zone that must be validated. ## Which setup method should I use? Use the method documented by Microsoft for the exact Microsoft 365 sending path and tenant. The available official material does not establish whether Microsoft 365 provides an automatic DMARC setup method, a manual DNS workflow, a dedicated-IP option, or a current authentication screen for this task. Do not choose a method based on an account-generated value from another organization. A copied selector, CNAME target, token, hostname, or TXT value can point at the wrong tenant or fail to authenticate the intended sending path. ![Four evidence layers required before accepting a Microsoft 365 DMARC change](/images/editorial/dmarc-microsoft-365/dmarc-microsoft-365-validation-flow.webp "1200x829") *Source: Palisade.* ## How do I configure SPF and DKIM for Microsoft 365? A publishable Microsoft 365 procedure requires Microsoft's current official instructions for the tenant's sender configuration. The available material does not support a current UI path, an SPF value, DKIM selector names, DKIM CNAME targets, verification controls, or a Microsoft-specific test procedure. ### 1. Confirm the current Microsoft 365 documentation Open the current Microsoft documentation that applies to the Microsoft 365 service and sending path in scope. Record the page title, URL, checked date, required role, and the exact settings path before making a change. Do not treat a general documentation landing page as proof of a specific configuration path. The relevant Microsoft page must describe the actual setting and the tenant context where it applies. ### 2. Select the exact sending domain Confirm the visible From domain for the messages that need authentication. Keep mailbox-hosted mail, application mail, relay traffic, and third-party mail using the same domain separate until each route has been tested. The selected domain must match the DNS zone that the authorized administrator can edit. If another team owns the DNS zone, stop until the proposed records and rollback plan have been reviewed. ### 3. Copy the DNS records from the Microsoft 365 tenant Copy only the DNS records generated or documented for the selected tenant and domain. Do not use example records as production configuration. A structural record format is shown below for change-review purposes only. It is not a Microsoft 365 record and must not be published. **Record type:** `TXT` **Host (illustrative only):** ```text _dmarc.yourdomain.com ``` **Value (illustrative only):** ```text v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com ``` > Do not publish this example as a Microsoft 365 configuration. Use the exact record and reporting destination approved for your domain, and obtain Microsoft-specific DKIM values from the current Microsoft 365 documentation or tenant interface. Before saving any DNS change, inspect existing records at the same owner name. A DNS provider may append the zone name to the host field, which can create a duplicated domain name if a fully qualified host is pasted into a relative-host field. Record the final fully qualified name that the provider will publish. Do not replace an existing SPF, DKIM, or DMARC record merely to match an example. The current Microsoft documentation and the domain's existing records must determine whether the change is additive, a replacement, or a staged migration. ### 4. Verify the configuration in Microsoft 365 Return to the tenant interface or documented Microsoft verification path after public DNS answers with the intended record. Record the exact status, timestamp, selected domain, and any error text without altering it. A positive Microsoft status is useful vendor evidence. It does not prove that a real message from every production route has the expected authentication result. ### 5. Send a real test message Send a new message through the exact production path after the configuration change. Deliver it to a mailbox where an authorized operator can inspect the raw source and preserve a redacted copy with the change record. Do not accept a test message sent before the change, a message from a different system, or a message whose route cannot be identified. A configuration can appear correct in DNS while a separate sending route continues to use different authentication behavior. ## How does this setup affect DMARC? DMARC depends on evidence from the actual sending path and the visible From domain. A published DMARC record is only public DNS evidence. It does not show which production sources use the domain, which messages authenticate, or how a receiving mailbox evaluates an individual message. Use Palisade's [DMARC checker](/tools/dmarc) to inspect the public DMARC record for the sending domain after DNS changes. Compare that result with the exact delivered message and the Microsoft 365 tenant evidence. A record check cannot prove the production sending path, a receiver's private decision, future placement, or continuous authentication state. ## How do I validate the setup? ### Check public DNS Query the exact owner names authorized for the selected domain. Compare the authoritative DNS answer with at least one public resolver and retain the results with the change record. Use the [DMARC checker](/tools/dmarc) for a public record check, then compare it with the authoritative response for the exact domain. A public check is a point-in-time DNS observation. ```bash dig +short TXT _dmarc.yourdomain.com ``` ### Check the Microsoft 365 status Use the current Microsoft tenant interface or documented verification process for the selected domain. Record the current status and any exact error text. Do not treat a green status as delivered-message evidence. It only shows that the Microsoft process accepted the configuration state it evaluated. ### Inspect a delivered message Inspect raw source from a newly delivered message sent through the production path. Preserve a redacted copy of the message headers with the domain, route, timestamp, and test result. Compare the visible From domain with the authentication results added by the receiving mailbox. If the message does not contain enough trusted receiver-added evidence to establish the result, do not infer that the configuration works. ### Review DMARC reports Review DMARC aggregate-report data after reports accumulate for the sending domain. Separate Microsoft 365 traffic from other sources that use the same visible From domain. Palisade analyzes DMARC aggregate-report data, identifies sending sources and authentication or alignment issues, and creates prioritized remediation tickets. It can propose the next policy step when the evidence supports it. A human reviews the evidence and applies any DNS or DMARC policy change. ## Troubleshooting ### The current Microsoft 365 path cannot be confirmed Use the official Microsoft documentation for the tenant's exact service and sending path. Do not follow an unverified admin-center path or rely on a screen capture without a current official source. Capture the documentation URL, checked date, required role, and exact setting labels before proceeding. If those details cannot be confirmed, pause the change. ### DNS does not return the intended record Check whether the DNS interface expects a relative host name or a fully qualified name. A provider that appends the zone can publish a duplicated owner name when the full domain is entered in the host field. Compare the authoritative answer with the intended fully qualified owner name before editing the value again. ### Microsoft 365 status and DNS results disagree Record both results, including the selected domain and the exact DNS owner queried. Confirm that the tenant, domain, and sending path are the same in both checks. Do not replace records repeatedly while the evidence is inconsistent. Resolve the mismatch between the authoritative answer and the current Microsoft instructions first. ### The public DMARC record is present but the delivered message remains unclear A public record does not establish the result for a particular message. Send a new message through the exact path under review and inspect its raw source in a mailbox that exposes the needed header evidence. If another service also sends as the domain, test that service separately. One successful route cannot establish the behavior of the others. ## Check the DMARC record behind the Microsoft 365 change After you have identified the sending domain and published an approved DNS change, use Palisade's [DMARC checker](/tools/dmarc) to inspect the public DMARC record. Compare the result with authoritative DNS, Microsoft 365 status, and a new delivered message from the same sending path. A passing record check does not prove that Microsoft 365 is signing every route, repair a tenant configuration, monitor later DNS drift, or guarantee receiver acceptance. For teams that need to identify every sending source using a domain and work through authentication or alignment issues over time, [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=vendor_setup&utm_content=dmarc-microsoft-365). Palisade analyzes DMARC aggregate-report data and proposes prioritized remediation work, while your team reviews the evidence and applies the changes. Signup and trial do not require a credit card. ## Sources and further reading - [Microsoft Learn official documentation platform](https://learn.microsoft.com/) - [Palisade DMARC learning hub](/learning/dmarc) - [Palisade vendor email authentication guidance](/learning/esp-setup) - [Palisade DMARC checker](/tools/dmarc) ## Frequently asked questions ### Does Microsoft 365 require DMARC? Microsoft does not publish a blanket DMARC requirement for sending from a Microsoft 365 tenant. The pressure usually comes from the other direction, because the mailbox providers you send to set their own bulk-sender rules and your own security policy may require it anyway. Check Microsoft's current sender-requirements documentation for the exact service you use before treating DMARC as a Microsoft 365 obligation. ### How do I set up DMARC in Microsoft 365? Publish a DMARC TXT record at `_dmarc.yourdomain.com` in the DNS zone for the domain in your From address, starting at `p=none` with a reporting address you control. DMARC is a DNS change rather than a Microsoft 365 setting, so the tenant work is making sure SPF and DKIM are configured there for that same domain. Take the DKIM values from Microsoft's current documentation and your own tenant, because they are generated per tenant and cannot be copied from an example. ### What is Microsoft DMARC? There is no separate Microsoft version of DMARC. DMARC is an open standard, and the phrase normally just means setting up DMARC for a domain that sends through Microsoft 365. What is Microsoft-specific is where you enable DKIM and how the tenant handles your domain, not the DMARC record itself. ### What are DKIM and DMARC in Office 365? DKIM adds a signature to outgoing messages so a receiver can confirm they were not altered and came from your domain. DMARC then reads the SPF and DKIM results, checks whether either aligns with your visible From domain, and tells receivers what to do when neither does. In Office 365 you enable DKIM inside the tenant, while the DMARC record is a DNS change you publish yourself. ### Can a DMARC checker prove Microsoft 365 is configured correctly? No, because a checker only reads the DMARC record your domain publishes. It cannot see how your tenant is configured, which route a real message takes, or whether a receiver will accept your next message. Confirm those with the Microsoft tenant status and the headers of a message you actually sent. --- # Office 365 DMARC monitoring Canonical: https://www.palisade.email/learning/dmarc-monitoring-o365 > Office 365 DMARC monitoring: check the domain's published DMARC record, then validate aggregate reports and real production messages separately. DMARC monitoring for Office 365 starts with the domain that appears in the visible From address, not with an assumed tenant setting. Check the published DMARC record first, then keep DNS publication, any reporting destination, and delivered-message authentication evidence separate. A public DNS lookup can show the current record. It cannot prove that Office 365 sent a particular message with aligned authentication or that a receiving system accepted it. ## Quick takeaways - DMARC monitoring begins with the visible From domain used by the production message. - A DMARC TXT lookup shows what DNS publishes at the time of the query. - A published record does not prove that Office 365 is signing, aligning, or using the expected sending path. - A delivered production message provides separate authentication evidence through its headers. - Aggregate-report data, once available, is separate from DNS and message-header checks. - Do not treat a public checker result as proof of future delivery or a receiver's private filtering decision. ## How DMARC monitoring works for an Office 365 domain DMARC monitoring is an evidence-gathering task. The first object is the DNS record for the domain used in the visible From field. The second is a real message sent through the production Office 365 path. The third is the aggregate-report data that accumulates after receivers process mail for the domain. These layers answer different questions. A DNS result can answer whether a public DMARC record is discoverable and what it currently contains. It cannot show whether the application or service that sent a message used the intended authentication path. A message header can show the authentication result recorded for that delivery path. It is evidence about that message, at that receiver, at that time. It does not inventory every source that may send with the same From domain. Aggregate-report data can help connect sending sources and DMARC outcomes over time. It does not replace a direct check of a business-critical message after a configuration change. For a broader explanation of the protocol and its policy role, see Palisade's [DMARC learning hub](/learning/dmarc). The operational question for Office 365 remains narrower: does the exact domain and production path have evidence at every relevant layer? ![Decision flow for separating DNS, message, and report evidence when monitoring DMARC for an Office 365 sending domain](/images/editorial/dmarc-monitoring-o365/dmarc-monitoring-o365-evidence-flow.webp "1200x829") *Source: Palisade.* ## When the answer changes The correct next check depends on the evidence already available. - If you only have a domain name, inspect the published DMARC record. This establishes the public DNS state, not sending behavior. - If you have a message that was delivered from the production path, preserve its headers and inspect its authentication results. This establishes evidence for that message, not all future mail. - If you have aggregate-report data, compare its sending-source and authentication outcomes with the approved inventory of services that use the domain. - If the visible From domain is a subdomain, start with that exact subdomain. Do not assume that a root-domain lookup answers the policy question for a more specific domain. - If a receiver made a placement, rejection, or filtering decision, use the receiver's own evidence where available. A DNS lookup alone cannot establish why that receiver acted. > Do not change a DMARC policy because a record lookup looks correct. Confirm the exact production sending path first, especially for business-critical mail. A green status in one system is not a replacement for the other layers. The useful decision rule is straightforward: when the question is about DNS, query DNS; when it is about one message, inspect that message; when it is about recurring sending sources, use accumulated reporting evidence. ## Worked evidence example Use the following as an evidence worksheet, not as a universal Office 365 configuration. The values are illustrative only. Do not publish another organization's reporting address or account-generated DNS values. ```text Visible From domain: alerts.yourdomain.com DNS question: Is a DMARC TXT record published for this exact domain? Message question: Does a delivered production message show aligned authentication? Reporting question: Which observed sending sources need review over time? Receiver question: What evidence explains this receiver's handling decision? ``` This worksheet keeps the evidence objects distinct. For example, an operator may discover that `_dmarc.alerts.yourdomain.com` has no usable public record while the organizational domain has one. That is a DNS finding. It does not establish whether a message from `alerts.yourdomain.com` passed or failed DMARC. A second operator may have a delivered message but no record history. The message can be inspected for the exact sending path. It cannot establish whether a future DNS change, new sender, or different Office 365 workflow will behave the same way. A third operator may have report data that identifies a source requiring review. That finding should be compared with the legitimate sender inventory before any policy decision. Do not infer that every observed IP address is authorized merely because it appears in report data. The evidence should stay attributable to its layer. This prevents a common mistake: treating a public record check as a complete Office 365 DMARC-monitoring result. ## Practical next step Start with the evidence you have. If you only know the domain, use the [Palisade DMARC checker](/tools/dmarc) to inspect the published DMARC record. Record the exact domain queried and the lookup time. If production mail uses a subdomain in the visible From field, check that domain too. If you have a delivered production message, preserve the raw headers before changing DNS or sender settings. Compare the visible From domain, the sending path, and the recorded authentication outcomes. Keep private headers, recipient addresses, message content, and tenant identifiers out of tickets or shared documents unless your organization's handling rules allow them. If you already receive aggregate reports, review them against the approved sender inventory and separate known services from sources that need investigation. A report trend may identify work to do. It does not authorize a policy change by itself. For a focused explanation of the record that the lookup returns, use the [DMARC policy guide](/learning/dmarc). For a product overview of ongoing DMARC work, see [Palisade's DMARC Agent](/features/dmarc-agent). ## Check the DMARC record behind your Office 365 domain Use the domain that appears in the visible From address to inspect its current public DMARC record before interpreting message or report evidence. [Check the domain's DMARC record](/tools/dmarc) A public record check does not prove that Office 365 sent an aligned message, collect reports, monitor later DNS changes, or explain a receiver's final handling decision. Palisade can analyze DMARC aggregate-report data, identify sending sources and authentication or alignment issues, and propose prioritized remediation work. A human reviews the evidence and applies any DNS or policy change. ## Sources and further reading - [Palisade DMARC learning hub](/learning/dmarc) - [Palisade DMARC checker](/tools/dmarc) - [Palisade DMARC Agent](/features/dmarc-agent) ## Frequently asked questions ### Does a DMARC lookup prove Office 365 is configured correctly? No. A lookup shows the public DNS record available at the queried domain. It does not prove that a production Office 365 message used the expected authentication path or passed DMARC. ### Should I query the root domain or the visible From subdomain? Yes. Query the exact domain used in the visible From address first. A subdomain can require its own review, so a root-domain result may not answer the operational question. ### Can a delivered message replace aggregate-report monitoring? No. A delivered message is evidence about one delivery path and time. Aggregate-report data can provide a separate view of observed sending sources and outcomes over time. ### Does a passing DMARC result guarantee inbox placement? No. DMARC evidence concerns authentication and alignment for the message. A receiving system can apply additional local decisions when handling mail. ### Can Palisade change a DMARC policy automatically? No. Palisade can analyze DMARC aggregate-report data, identify issues, create prioritized remediation tickets, and propose a next policy step. A human reviews the evidence and applies the change. --- # DMARC MX tools: check the right DNS record Canonical: https://www.palisade.email/learning/dmarc-mx-tools > DMARC MX tools separate DMARC TXT-record checks from MX routing checks, so you can repair the right DNS record, verify public DNS, and retest it. DMARC MX tools answer two different DNS questions. Use a DMARC check to inspect whether the domain publishes the DMARC-related TXT configuration, and use an MX lookup to see where inbound email for the domain is routed and the priority of those mail servers. A good MX answer does not confirm a DMARC policy, and a visible DMARC record does not prove that production messages authenticate. ## Quick takeaways - MX records identify mail-routing destinations and their priority for a domain. - DMARC is commonly configured through DNS TXT records, not MX records. - An MX result and a DMARC result should be treated as separate evidence. - Public DNS checks do not prove the production sending path or a receiver's private delivery decision. - Retest the exact record type you changed after the authoritative DNS answer updates. ## What this tool checks A [DMARC checker](/tools/dmarc) is the appropriate starting point when the question is whether a domain exposes DMARC-related DNS configuration. For broader policy context, see the [DMARC learning hub](/learning/dmarc) and the explanation of [what DMARC is](/learning/what-is-dmarc). An MX lookup answers a different question. [MXToolbox describes an MX lookup as listing a domain's MX records in priority order](https://mxtoolbox.com), while [DNS Checker describes MX records as information about where a domain's email should be routed and mail-server priority](https://dnschecker.org). DNS Checker also identifies SPF, DKIM, and DMARC as configurations commonly carried in TXT records. That difference is a DNS record-type distinction. It does not mean MX routing has no operational relationship to email. A mail flow issue can involve routing, sender authentication, or both. The useful first step is to avoid treating an MX answer as proof of a DMARC configuration. A public check can inspect what DNS returns at the time of the query. It cannot prove which application sent a production message, whether that message was signed, whether the visible From domain aligned, why one receiver rejected it, or what a receiver will decide about a future message. ![Decision map separating DMARC TXT-record checks from MX routing checks](/images/editorial/dmarc-mx-tools/dmarc-mx-tools-record-map.webp "1200x676") *Source: Palisade.* ## How to run the check ### 1. Start with the question you need to answer Choose the DMARC path when you are investigating the domain's DMARC DNS configuration. Choose the MX path when you need to identify inbound mail-routing hosts or their priority. Do not use an MX lookup as a substitute for a DMARC check. The records have different jobs and can both be present while a separate message-path problem remains unresolved. ### 2. Check the domain's DMARC DNS configuration Open the [Palisade DMARC checker](/tools/dmarc) and use the domain you are investigating. Keep a copy of the returned DNS evidence and the time of the check. If the problem concerns a delivered message, collect the raw message headers separately. A DNS result is public-record evidence. It is not evidence that the sending application used the expected authentication setup. ![Generic email-security product overview showing DNS and authentication monitoring concepts](/images/editorial/dmarc-mx-tools/dmarc-mx-tools-shot-1.png "1600x900") *Source: Barracuda documentation product image: https://documentation.campus.barracuda.com/wiki/rest/api/content/5242894/child/attachment/att5242965/download* ### 3. Look up MX routing separately when routing is in scope Use an MX lookup when inbound delivery, mail-server priority, or an expected receiving host is part of the incident. MXToolbox states that its MX lookup queries the domain's authoritative name server, so its statement that changes should appear immediately applies to that specific lookup behavior, not to every DNS resolver or every operational dependency. You can independently ask a public resolver for an example domain's records: ```bash dig +short MX yourdomain.com dig +short TXT _dmarc.yourdomain.com ``` The first command asks for MX records. The second asks for TXT records at the conventional DMARC DNS owner. Treat the commands as separate checks with separate outputs. ### 4. Record what changed before you retest Write down the domain, record type, query time, resolver or tool used, and the exact result. If you changed MX routing, retest MX. If you changed DMARC configuration, retest the DMARC-related TXT result. > Do not replace an MX record because a DMARC check looks wrong, or replace a DMARC-related TXT record because an MX lookup looks wrong. A record-type mix-up can interrupt mail flow. ## How to interpret the results ### An MX answer is present A returned MX answer indicates that the lookup found mail-routing records for the queried domain. The listed preference values help order mail-server destinations. This is routing evidence, not evidence that the domain has published or applied DMARC configuration. If a domain has an MX answer but the DMARC check does not show the expected DNS configuration, investigate the DMARC-related TXT record separately. If the issue is inbound routing, continue with the MX evidence and the receiving mail system's configuration. ### An MX answer is absent or unexpected An absent or unexpected MX result calls for a routing investigation. Confirm that the queried domain is correct, then compare the returned answer with the intended mail-routing configuration in the domain's DNS provider. Do not infer a DMARC failure from this result. DNS Checker identifies MX and TXT as different record categories, so the missing or unexpected MX evidence does not itself tell you whether the domain's DMARC-related TXT configuration is visible. ### A DMARC check shows the expected public DNS configuration A visible DMARC-related DNS result is evidence that a public lookup can retrieve the configuration. It is not a complete authentication test. Move to a real message from the exact production sender and inspect its receiver-added authentication results. Then observe aggregate-report data once it accumulates. Those layers answer questions that a public DNS check cannot: which senders are active, whether authentication or alignment issues occur, and whether the domain is ready for a later policy stage. ### A DMARC check does not show the expected public DNS configuration First confirm the exact domain being checked and inspect the DNS provider's published record for that same domain. Then repeat the public lookup. Keep this diagnosis scoped to record visibility until you have message evidence. If the record has recently changed, do not assume that one public result explains every resolver's answer or every sender's behavior. Compare authoritative DNS evidence, a public lookup, the vendor's verification status where relevant, and a new delivered message from the same production path. ## How to act on the result Repair the record type that matches the evidence. For an MX mismatch, work in the DNS provider or mail-routing configuration. Confirm the intended host names and priority values with the organization that operates inbound mail. Then validate through authoritative DNS and at least one public resolver. For a DMARC-related TXT mismatch, work from the current configuration intended for that domain. Do not copy DNS values from another organization or tenant. After publication, check the DNS answer again, then send a new message through the same production sender and inspect the received headers. PowerDMARC describes a DMARC workflow that includes configuring a policy and aggregate reporting, publishing the record in DNS, observing mail activity, then moving from `p=none` toward `p=quarantine` or `p=reject`. [Its DMARC implementation guidance](https://powerdmarc.com) describes that sequence, but it is not a universal timing rule. Policy changes need evidence from the domain's actual senders and reports. Use a four-layer check before treating a repair as complete: - DNS: confirm the intended record from the authoritative server and a public resolver. - Vendor: check the current authentication or verification status in the applicable sending service. - Message: send a new message through the exact production path and inspect its raw headers. - DMARC: review aggregate-report data after it has accumulated. The [DNS lookup tool](/tools/dns-lookup) can help when you need to inspect TXT and MX answers separately. It still cannot show private receiver policy decisions or prove future inbox placement. ## Investigate this with your coding agent Use this when the public result is unclear and you need an evidence-backed map of what the site can return before changing DNS. Prepare only a redacted domain and the visible result. Do not include message headers, credentials, tokens, or customer data. ```agent Problem: Determine which DMARC DNS record states the Palisade DMARC tool can return for a redacted test domain and whether it also exposes MX evidence. Evidence: Redacted domain, timestamped public tool result, and any non-sensitive DNS response text. Repository scope: Inspect /tools/dmarc, src/app/api/dns/route.ts, and directly related tests or configuration only. Constraints: Inspect before editing. Do not apply changes until I approve the proposed diff. Do not query or expose credentials, private keys, tokens, unredacted headers, or customer data. Do not alter product code or DNS. Requested output: Evidence-backed result mapping, the minimal proposed change if a defect is found, rollback, and unknowns. Verification: Reproduce each documented state with a redacted test domain through the same public tool path and compare its DNS response. Stop if: Credentials, private data, production mutation, or missing evidence is required. ``` ## How to retest Repeat the same record-specific check after the DNS change. For an MX repair, repeat the MX lookup and compare the returned host names and priority order with the intended routing configuration. For a DMARC-related TXT repair, repeat the DMARC check, then test a newly sent production message. A successful public DNS response is one layer of validation, not the final result. If an authoritative DNS response and a public resolver disagree, preserve both timestamps and escalate through the DNS provider before changing unrelated mail settings. If DNS answers match but a real message still fails, investigate the sender configuration and message headers rather than changing MX routing. ## Move from one DNS check to an ongoing DMARC workflow After a DMARC record is visible, the remaining question is which production sources authenticate and align over time. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=dmarc_tools&utm_content=dmarc-mx-tools) to have the DMARC Agent analyze aggregate-report data, identify sending sources and authentication or alignment issues, and create prioritized remediation tickets for review. Palisade can propose the next policy step when the evidence supports it, but a human reviews the evidence and applies any DNS policy change. It does not change DMARC policy on its own, prove every future message will authenticate, or guarantee delivery or inbox placement. ## Sources and further reading - [Palisade DMARC checker](/tools/dmarc) - [MXToolbox MX lookup](https://mxtoolbox.com) - [DNS Checker record lookup guidance](https://dnschecker.org) - [PowerDMARC DMARC implementation guidance](https://powerdmarc.com) - [EasyDMARC overview of email-authentication protocols](https://easydmarc.com) ## Frequently asked questions ### How do I get DMARC for my domain? Publish a DMARC TXT record at `_dmarc.yourdomain.com` with a monitoring policy and an address for aggregate reports, then read the reports that come back. [PowerDMARC's implementation guidance](https://powerdmarc.com) describes observing mail activity before moving from `p=none` to a stricter policy. Base any later policy change on evidence about the domain's actual senders, not on a calendar. ### What is an example of a DMARC? A DMARC record is a DNS TXT record published at `_dmarc.yourdomain.com`. It opens with the version tag, states a policy of `none`, `quarantine`, or `reject`, and usually names a mailbox for aggregate reports, so a monitoring record reads like `v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com`. Treat that shape as illustrative and use the values intended for your own domain rather than copying another organization's record. ### What is DMARC used for? DMARC is used to tell receiving servers how to treat mail that claims to come from your domain without an aligned SPF or DKIM pass, and to send the domain owner reports about that mail. PowerDMARC states that a stricter DMARC policy can help protect against spoofing, phishing, business email compromise, and ransomware. That is a vendor-stated benefit, not a guarantee that every unwanted message will be blocked. ### What is MX, SPF, DKIM, and DMARC? MX records identify where a domain's email should be routed and the priority of mail servers. DNS Checker identifies SPF, DKIM, and DMARC as configurations commonly associated with TXT records, while EasyDMARC describes DMARC, SPF, and DKIM as email-authentication protocols with different roles in an email-security system. ### Does an MX record prove that DMARC is configured? No, an MX record proves nothing about DMARC, because MX records only say where inbound mail for the domain should be routed. DMARC lives in a TXT record at `_dmarc.yourdomain.com`, so check that separately. A delivered message is what shows you how the production sender actually authenticated. --- # DMARC onboarding checklist for MSPs Canonical: https://www.palisade.email/learning/dmarc-onboarding-checklist-for-msps > DMARC onboarding checklist for MSPs: define ownership, inventory domains and senders, collect evidence, manage exceptions, and report each client decision. A DMARC onboarding checklist for MSPs should create one repeatable evidence record for every client domain before anyone recommends a DNS or sender change. Define who owns the client decision, DNS access, and each sending system. Then inventory domains and senders, record the available evidence, assign missing information, and route exceptions to an accountable owner. This turns onboarding into an operating workflow that can be reviewed across a portfolio. ## Quick takeaways - One client can have many domains, sending platforms, approvers, and change windows. - An MSP should record observed evidence separately from a client's stated sender inventory. - DNS ownership, sender ownership, and client approval are different responsibilities. - A public DMARC lookup is useful for visible DNS evidence, but it cannot prove a production sending path or a receiver's future handling decision. - Every incomplete onboarding item needs an owner, a next action, and a review date. - This checklist is a Palisade operating framework, not an external protocol requirement. ## Operating context and ownership DMARC onboarding changes when an MSP manages a portfolio. The work is not a one-time record review for one administrator. The MSP needs a consistent way to determine what is in scope, who can make decisions, which sending paths need evidence, and what must remain blocked until a client or sender owner responds. Start with a service boundary for each client. Record whether the MSP is responsible for collecting evidence only, making technical recommendations, coordinating sender configuration, publishing DNS after approval, or reporting on an established service. The client retains business ownership of its domains and approval decisions unless a written agreement delegates a specific action. Separate these responsibilities in the onboarding record: - The client owner confirms business-critical domains, approves changes, and decides whether an unfamiliar sender is legitimate. - The MSP service owner maintains the evidence register, assigns follow-up work, and records decisions and handoffs. - The DNS host publishes DNS records when an authorized person makes a change. - The sender owner controls settings in the marketing, billing, support, CRM, or application platform that sends mail. - The mailbox provider controls its own message handling decisions. An MSP cannot promise a receiver will accept or place future mail. For client stakeholders who need a protocol primer, link them to [what DMARC is](/learning/what-is-dmarc). Keep that education separate from the operational decision: understanding DMARC does not establish which systems actually send for a client. Centralized records, revision control, and access logs can help an MSP maintain service documentation. [IT Portal describes those capabilities as part of its documentation product](https://itportal.com), but the checklist below is an original Palisade operating framework rather than a requirement imposed by that vendor or by every MSP. ![Checklist flow showing client scope, evidence collection, ownership assignment, exception handling, and reporting for each managed domain](/images/editorial/dmarc-onboarding-checklist-for-msps/dmarc-onboarding-checklist-for-msps-onboarding-flow.webp "1200x829") *Source: Palisade.* ## Evidence to collect Create one working record per domain, then group those records under the client. Do not merge every domain into one generic client status. A parked domain, an active corporate domain, and a domain used only by a billing application can require different owners and decisions. Collect the following before calling a domain onboarded: - Client name, business owner, technical approver, and escalation contact. - Domain and subdomains in scope, including whether each is active, dormant, or awaiting confirmation. - DNS provider, DNS change owner, and the required approval path. - Known sending systems supplied by the client. - Visible DNS evidence for DMARC, SPF, and DKIM where applicable. - Evidence from a real delivered message for important production paths, with private data removed before sharing. - Missing evidence, unresolved sender ownership, and client decisions still required. - A next action, accountable owner, and review date for each open item. Use a public lookup only for the evidence it can inspect. The [DMARC checker](/tools/dmarc) can help an operator inspect a domain's visible DMARC DNS posture. It cannot establish that every production sender uses the intended configuration, continuously monitor the domain, or prove a mailbox provider's private reputation or placement decision. For DNS-side sender evidence, the [SPF checker](/tools/spf) and [DKIM checker](/tools/dkim) can support the same record. Keep the register in a portable format that can move between a PSA, ticket system, documentation platform, or client report: ```yaml client: your-client-name domain: yourdomain.com evidence: dns_status: public-record-check-completed sender_inventory: client-supplied-pending-review message_sample: missing owner: client-technical-approver next_action: confirm-billing-platform-and-provide-redacted-message-header review_on: 2026-08-20 ``` The values above are illustrative only. Do not place customer names, private headers, API tokens, selectors, or DNS change credentials in a shared checklist. ## How to run the workflow ### 1. Confirm portfolio scope **Owner:** MSP service owner. **Input:** client agreement, domain list, and onboarding contacts. **Output:** an approved domain scope with named business and technical contacts. Ask the client to identify domains that send mail, receive mail, redirect to another site, are dormant, or have an uncertain purpose. Mark uncertainty rather than removing it from scope. A domain with no known owner is an onboarding exception, not a completed item. Record the client-approved boundary for the service. This prevents a later assumption that the MSP may edit DNS, access a sender platform, or decide whether a message stream is legitimate. ### 2. Establish the ownership map **Owner:** MSP service owner with the client technical approver. **Input:** scope record and access information. **Output:** a responsibility map for DNS, senders, approvals, and escalations. Assign one accountable party to each domain's DNS access and each known sender. A client may use different teams for marketing, finance, support, and infrastructure. Treat those as separate handoffs even when they use the same domain. Include a backup client contact for business-critical sending paths. If an owner cannot be identified, record `missing-owner` and set a review date. Do not turn an unassigned item into a technical remediation ticket. ### 3. Build the sender inventory **Owner:** client business owner, supported by the MSP. **Input:** client-provided system list, historical documentation, and available message evidence. **Output:** a sender inventory with confidence labels. Classify every sender as `client-confirmed`, `evidence-observed`, `unknown`, `retired`, or `requires-human-approval`. These labels preserve the difference between a platform someone remembers using and a sender supported by current evidence. For each sender, record its business purpose, domain used, technical owner, normal sending frequency, and whether a redacted delivered-message sample is available. Monthly invoices, annual event mail, and emergency notices can disappear from a short observation period. They still need a decision. ### 4. Record DNS and delivered-message evidence **Owner:** MSP technical operator. **Input:** domain names, approved public DNS checks, and redacted message samples. **Output:** dated evidence attached to the correct domain and sender. Check visible DNS records through the authoritative source where access is available and compare with at least one public lookup. Save the result date and the domain queried. A public result is evidence of what was visible at that moment, not proof that an application is signing mail or using a particular return path. For high-impact senders, request a real delivered message from the exact production path. The client should redact addresses, content, message IDs, and other private information before sharing it. Record whether the message evidence supports the sender inventory or raises a question that needs escalation. > Do not publish, replace, or remove a DNS record during onboarding solely because a public checker returns a result. The client approval path and sender evidence remain separate controls. ### 5. Create the exception register **Owner:** MSP service owner. **Input:** missing evidence, unknown senders, unclear ownership, and conflicting records. **Output:** a visible queue with a decision path. Write each exception as an observable condition. “Review DMARC” is too broad. “Billing sender has no client-confirmed owner and no redacted production message evidence” tells the owner what is missing. Set the next action and review date when the item enters the register. The client can confirm the sender, the sender owner can provide configuration evidence, or the client approver can accept that the item remains blocked. The MSP records the decision and does not invent authority that it does not have. ### 6. Make the service decision **Owner:** client approver, with an MSP recommendation. **Input:** completed domain record and open exceptions. **Output:** an onboarding state for each domain. Use clear states such as `ready-for-monitoring`, `evidence-incomplete`, `blocked-by-client-decision`, `blocked-by-sender-owner`, or `out-of-scope`. These are service decisions, not claims that a domain is universally protected or guaranteed to deliver. A domain can be ready for ongoing review while one lower-priority domain remains blocked. Portfolio onboarding does not require an all-or-nothing result, but it does require that exceptions stay visible. ## Investigate this with your coding agent Use this when the client has a redacted configuration repository or operational runbooks that may list domains and sending services. Prepare only approved, redacted repository access and a domain list. Do not include credentials, private keys, tokens, or unredacted customer data. ```agent Problem: Build a read-only onboarding evidence register for managed client domains and known sending systems. Evidence: Redacted domain list, approved repository paths, redacted DNS and sender configuration references, and existing runbook excerpts. Repository scope: Inspect only the approved client configuration repository and operational runbook directories. Constraints: Inspect before editing. Do not apply changes until I approve the proposed diff. Do not cross tenant boundaries, read secrets, change DNS, modify sender settings, or create tickets. Requested output: Diagnosis of each domain's available evidence, a minimal proposed onboarding register, missing owners or sender inventory entries, rollback guidance for any proposed future change, and unknowns. Verification: Compare the register against the client-approved domain scope and retest visible DNS only after a human-approved change. Stop if: Credentials, private data, production mutation, active incident handling, client authorization, or missing approved repository access is required. ``` ## Exceptions and escalation Escalate when the evidence record cannot answer a service decision: - A sender is business-critical but no client owner can confirm it. - DNS access or the authorized DNS change owner is unclear. - A sender owner cannot provide a safe message sample or configuration reference. - A visible DNS result conflicts with client documentation. - A client requests a change without approving the domain scope, rollback condition, or responsible owner. - An active delivery incident appears during onboarding. Use an escalation tree: - If the domain owner is known, request a client decision and set a review date. - If the sender owner is known, request sender-specific evidence and retain the domain in an incomplete state. - If DNS ownership is unknown, route the item to the client technical approver. - If an active incident exists, follow the agreed incident process instead of treating the work as routine onboarding. - If no owner responds, keep the item visible as blocked. Do not silently close it. The MSP can coordinate evidence and recommendations. The client controls business acceptance, the DNS host controls record publication, sender providers control their configurations, and mailbox providers control their receiving decisions. ## Reporting and success measures Use a recurring portfolio review that distinguishes completed evidence from unresolved service work. The cadence is an MSP service-design choice, not a universal SLA requirement. A useful client-facing report includes: - Domains by onboarding state. - Domains with complete ownership records. - Known senders by confidence label. - Exceptions by owner, age, and next review date. - DNS checks and delivered-message evidence collected during the reporting period. - Decisions awaiting client approval. - Changes proposed, approved, or deferred. Do not reduce the report to one score that claims every sender is authentic or every future message will be delivered. The practical measure is whether the MSP and client can identify the current domain state, the supporting evidence, the owner of each unresolved item, and the next decision. ## Turn onboarding evidence into a portfolio service When recurring client onboarding produces a growing queue of domains, sender questions, and remediation decisions, the bottleneck is maintaining a consistent portfolio workflow. [Palisade's MSP offering](/for-managed-service-providers) is the appropriate next conversation for teams that need an operating model for managed DMARC work across clients. [Book a demo](https://calendly.com/sam-palisade/30min) to discuss the portfolio workflow behind your onboarding checklist. [Create a Palisade account](https://app.palisade.email/signup) to begin. A consultation does not prove a production sender is configured correctly, authorize client DNS changes, or guarantee how receiving mailbox providers will handle future mail. ## Sources and further reading - [IT Portal documentation platform](https://itportal.com) - [Palisade for managed service providers](/for-managed-service-providers) - [What is DMARC?](/learning/what-is-dmarc) ## Frequently asked questions ### What should an MSP collect before onboarding a client domain for DMARC work? An MSP should collect the client and technical owners, domain scope, DNS change owner, known senders, visible DNS evidence, available redacted delivered-message evidence, open exceptions, and a next action with a review date. The record should show which facts are confirmed and which still require a client decision. ### Can a DMARC checker complete an MSP onboarding checklist? No, a DMARC checker cannot complete the checklist, because it only reads one domain's public DNS at one moment. Onboarding also needs the client and technical owners, the DNS change approver, the sender inventory, and the open exceptions, and none of that appears in a DNS answer. Use the checker as one evidence item inside the record, not as the record. ### Who approves a DMARC-related DNS change during MSP onboarding? The client approves it, or a delegate the client has explicitly authorized. The MSP collects the evidence, recommends the change, and coordinates the request when its service scope allows that. The DNS host then publishes the record through the authorized access path. ### Should unknown senders be removed from the onboarding record? No, keep unknown senders in the record, because removing one hides an unresolved decision that can hurt the client later. Move each into an exception register with the evidence you have, the owner who must investigate it, the next action, and a review date. An unknown sender is a question waiting for an answer, not noise to clear out. ### Does completed onboarding prove that all client mail will authenticate? No, finishing onboarding does not prove that all client mail will authenticate. It proves the MSP has recorded the current scope, evidence, ownership, and open decisions. Each production sending path still needs its own delivered-message evidence, and every receiving mailbox provider makes its own handling decision. --- # DMARC policy rollout across client domains Canonical: https://www.palisade.email/learning/dmarc-policy-rollout-across-client-domains > DMARC policy rollout across client domains needs an approval-gated MSP workflow for ownership, evidence, exceptions, verification, and reporting. A DMARC policy rollout across client domains needs a portfolio workflow, not a repeated DNS task. An MSP should establish client authority, collect domain and sender evidence, assign each domain to an approval-gated wave, record exceptions, and keep verification evidence with every proposed policy change. This is a Palisade operating framework for multi-client coordination. It is not a replacement for the controlling DMARC standard, sender documentation, or client approval. ## Quick takeaways - Keep each client's domains, evidence, approvals, and exceptions separate. - A published-record check can confirm public DNS, but it cannot confirm sender ownership or a receiver's delivery decision. - Use rollout waves to prevent one client's readiness from becoming another client's deadline. - Record the owner, evidence, next action, review date, and rollback decision for every blocked domain. - Treat a proposed DMARC policy change as a client-approved change request. - Report portfolio progress as dated evidence and open decisions, not as a universal protection score. ## Operating context and ownership A multi-client rollout has several control boundaries. The MSP can maintain the operating record, collect evidence, coordinate remediation, and prepare a proposed change. The client decides what business sending is authorized and approves changes within the agreed service boundary. The DNS host publishes records. Each sending platform controls its own authentication configuration. Receiving mailbox providers make their own message-handling decisions. This division matters when one service desk manages dozens of domains. A domain can have a valid public record while its client has not confirmed a low-volume sender. Another client may have confirmed its senders but lack an authorized DNS change owner. Those are different blockers and should not sit in one undifferentiated queue. Use one service record per client domain. Give every record a named client approver, MSP owner, DNS change owner, and sender owner where applicable. The [Palisade MSP workflow](/for-managed-service-providers) is the appropriate discussion when this becomes a recurring portfolio service rather than a one-domain task. The framework below is Palisade operating guidance, not an external DMARC requirement. Its purpose is to make authority, evidence, and pending decisions visible before a client change is proposed. ![Portfolio rollout workflow showing separate client evidence records, approval-gated waves, exception handling, and post-change review](/images/editorial/dmarc-policy-rollout-across-client-domains/dmarc-policy-rollout-across-client-domains-portfolio-workflow.webp "1200x829") *Source: Palisade.* ## Evidence to collect Start with an intake record that distinguishes reported facts from assumptions. A client-provided sender list is useful, but it is not the same as evidence from a delivered production message or a reporting source. Keep those states separate so an MSP does not close work based on an untested statement. Collect these fields for each domain: - Client name and named technical approver. - Domain and any known related sending domains. - DNS provider, change owner, and approved change path. - Known sending platforms and the business owner for each one. - Public-record evidence, dated when collected. - Redacted delivered-message evidence when the production path must be confirmed. - Open exception, affected business process, owner, next action, and review date. - Proposed rollout wave, approval status, verification check, and rollback note. Use a portable record that can live in a PSA ticket, service register, or client report: ```yaml client: example-client domain: yourdomain.com evidence: public_record: checked-YYYY-MM-DD sender_inventory: client-confirmed delivered_message: pending-redacted-sample owner: msp-service-owner next_action: confirm-sender-owner-and-change-approval review_on: YYYY-MM-DD rollout_wave: evidence-review approval_status: pending rollback_note: client-approved-reversal-path-required ``` A [DMARC record check](/tools/dmarc) is useful when the immediate question is what record is publicly visible for a domain. It cannot prove that a listed platform is an authorized client sender, that the platform uses the expected production path, or that a mailbox provider will handle a future message in a particular way. For a single-domain repair where no policy is published, see [how to address a DMARC policy that is not enabled](/resources-post/resolving-the-issue-dmarc-policy-not-enabled). Portfolio work adds tenancy, approvals, exception ownership, and reporting to that narrower task. ## How to run the workflow ### 1. Establish client scope and authority Owner: MSP service owner. Input: client domain list, contacts, and service agreement. Output: a scoped portfolio record with named approvers and escalation contacts. Confirm which domains are in scope and who can authorize business-sender decisions and DNS changes. Record whether the MSP may only recommend changes or may prepare them for client approval. Do not begin a policy wave for a domain with unclear authority. ### 2. Create separate evidence records Owner: MSP analyst. Input: public DNS results, client sender inventory, and redacted message evidence where available. Output: one dated evidence record per domain. Do not merge evidence across clients just because domains use the same sender. A sender can be authorized for one client and unknown for another. Label the source of each item, such as `client-confirmed`, `public-record`, `message-verified`, `unknown`, or `retired`. ### 3. Classify work into portfolio waves Owner: MSP service owner with client approver. Input: evidence records and open exceptions. Output: an approval-gated work queue. Use operational states such as `intake`, `evidence-review`, `remediation-pending`, `client-approval`, `post-change-review`, and `blocked`. These are workflow states, not protocol-defined DMARC phases. Place domains in a wave only when their evidence and owners are sufficient for the next proposed action. A high-volume unknown sender, a missing DNS owner, and a client awaiting approval should each remain visible for different reasons. ### 4. Assign remediation to the controlling party Owner: the party that controls the observed gap. Input: dated evidence and a specific observed issue. Output: an owner-specific ticket with a retest condition. The MSP should describe the gap and the completion evidence without assigning a technical cause that the available evidence does not prove. Ask the client to confirm business authorization. Ask the sender owner for the configuration evidence it controls. Ask the DNS owner for the approved change record after a client-approved update. A useful ticket states the domain, observed evidence, responsible party, requested action, and the exact retest. “Review sender ownership for yourdomain.com and provide a redacted delivered-message sample after the approved configuration change” is testable. “Fix DMARC” is not. ### 5. Request approval for each proposed change Owner: client approver. Input: current record evidence, sender evidence, exceptions, proposed change, verification plan, and rollback note. Output: recorded approval or rejection. A client policy change should have its own decision record. Include the prior public value, proposed value, intended publication owner, effective time, verification method, and the condition that would trigger a rollback discussion. Do not treat a portfolio target as approval for an individual client domain. > Do not publish a client DNS change based only on a dashboard indicator or a public lookup. Confirm the approved record, the responsible change owner, and the required same-path evidence first. ### 6. Validate the completed wave Owner: MSP analyst and client approver. Input: authoritative DNS evidence, public resolver evidence, vendor status where applicable, redacted delivered-message evidence, and later reporting data. Output: a dated post-change review. Use four independent layers where they apply: - DNS: confirm the published result with the authoritative source and at least one public resolver. - Vendor: review the sender's current verification or authentication status when that sender provides one. - Message: inspect a real delivered message from the exact production path, using redacted headers or authentication evidence. - DMARC: review aggregate-report evidence after data accumulates. A green vendor status is not a delivered-message check. A public lookup is not proof of the production sending path. Keep the review open when a required layer is missing, then record what evidence is still needed. ## Investigate this with your coding agent Use this when the MSP has a redacted inventory and a policy repository or runbook that can be inspected safely. Prepare only client-approved, redacted records and exclude credentials, private keys, tokens, unredacted headers, and customer data. ```agent Problem: Build an approval-gated rollout queue for multiple client domains with missing-evidence flags. Evidence: Redacted client domain inventory, redacted DNS-as-code repository or policy repository, sender inventory, approval owners, exception register, and rollout runbook. Repository scope: Inspect only the portfolio inventory, DNS-as-code repository, sender inventory, and rollout runbook provided for this client service. Constraints: Inspect before editing. Do not apply changes until I approve the proposed diff. Do not cross tenant boundaries, modify DNS, change sender configuration, alter DMARC policy, access secrets, or make production changes. Requested output: Diagnosis of missing ownership or evidence fields, a minimal proposed wave queue, approval owners, verification checks, rollback notes, and unknowns. Verification: A human compares the proposed queue with the authoritative client inventory and applicable standards and provider guidance before approving any change. Stop if: Credentials, private data, production mutation, active incident handling, ambiguous client ownership, or missing authoritative inventory is required. ``` ## Exceptions and escalation Use a visible exception register instead of allowing blocked domains to disappear into ticket notes. Each entry should state the client, domain, observed condition, business impact, owner, requested decision, next review date, and whether the item blocks a proposed wave. Escalate when: - The client cannot confirm whether a sender is legitimate. - The DNS change owner is unknown or cannot approve the publication path. - A business-critical sender has no safe retest window. - Evidence from a delivered message conflicts with the client inventory. - A sender owner cannot provide the information needed for a same-path retest. - A client requests a change without a rollback decision or approval record. The MSP owns the service record and escalation process. The client owns acceptance of business risk and approval of client changes. The DNS host controls publication. The sender controls sender-side configuration. A mailbox provider controls its own handling decision. Use a simple decision path: if evidence identifies an owner, assign the next action and review date. If evidence is incomplete, keep the domain in evidence review. If the business impact is high or the owner is unavailable, escalate to the client approver. If approval is missing, do not advance the domain. ## Reporting and success measures Report on a regular operating cadence that matches the client's service agreement. A monthly portfolio review can show work in progress, while a quarterly client review can summarize decisions, completed waves, and unresolved risks. Use an evidence-based report: - Domains by operational state and named owner. - Sender inventory items by evidence status. - Open exceptions by client, business impact, owner, and review date. - Proposed changes awaiting client approval. - Completed changes with retained before-and-after evidence. - Post-change reviews that still lack DNS, vendor, message, or reporting evidence. Do not turn these fields into a claim that every future message will authenticate or that every receiver will make the same delivery decision. The report is an operating artifact. It shows what the MSP observed, what the client approved, what remains unresolved, and when the next review is due. [Managed DMARC service SLA guidance](/learning/managed-dmarc-service-sla) can help define the service conversation around ownership, escalation, and review. Keep any SLA terms specific to the client agreement rather than applying an invented portfolio-wide target. ## Turn policy rollout records into a managed portfolio workflow When recurring client domains, approvals, sender evidence, and exception queues are creating operational overhead, use [Palisade for managed service providers](/for-managed-service-providers) to discuss the workflow. Palisade is agentic DMARC software that analyzes DMARC aggregate-report data, identifies sending sources and authentication or alignment issues, and creates prioritized remediation tickets. It can propose a next policy step when the evidence indicates readiness. A human reviews the evidence and applies the change. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=msp_operations&utm_content=dmarc-policy-rollout-across-client-domains) Palisade does not authorize client senders, change a client's DMARC policy without human review, control external DNS without the required access and approval, or guarantee how a receiving mailbox provider will handle mail. ## Sources and further reading - [Palisade for managed service providers](/for-managed-service-providers) - [Palisade DMARC checker](/tools/dmarc) - [Managed DMARC service SLA](/learning/managed-dmarc-service-sla) - [DMARC monitoring for MSPs](/learning/dmarc-monitoring-for-msps) ## Frequently asked questions ### What is a DMARC policy for a domain? A DMARC policy is the instruction a domain publishes for receivers to follow when a message fails DMARC: `none` to monitor, `quarantine` to divert, or `reject` to refuse. It is carried in the domain's DMARC TXT record. In a multi-client workflow, record the current public value, the client approval owner, the sender evidence, the verification plan, and the rollback decision before proposing any change. ### Can I have multiple DMARC records on my domain? No, a domain can publish only one DMARC record at its `_dmarc` owner name. [RFC 9989 tells receivers to discard every returned record when more than one is found](https://www.rfc-editor.org/rfc/rfc9989.html), so a duplicate leaves the client with no usable policy at all. Use a public record check to see what is visible, keep the authoritative DNS evidence, and route the correction through the client's approved change process. ### How does DMARC work with subdomains? A subdomain uses its own DMARC record when it publishes one. When it does not, it inherits the parent domain's record, where the `sp` tag sets the policy for inheriting subdomains and the parent's `p` value applies if `sp` is absent. In portfolio work, keep each subdomain as a separate scope and evidence item until the client, DNS owner, and sender owners confirm the intended arrangement. ### What are typical phases for DMARC deployment? Most deployments run in three stages: publish `p=none` with aggregate reporting, fix the senders those reports expose, then move to `quarantine` and `reject`. This MSP framework tracks the same work as intake, evidence review, remediation pending, client approval, post-change review, and blocked exceptions. Those states organize responsibility and evidence, and they do not replace the technical requirements in the controlling standard or provider documentation. ### Should an MSP use one rollout queue for every client? No, one shared queue mixes clients whose approvals, evidence, and risks have nothing to do with each other. Use a single workflow model across the portfolio, but keep separate records for each client's domains, owners, approvals, evidence, and exceptions. Shared reporting has to preserve those tenancy boundaries. ### Can a DMARC checker prove a rollout is complete? No, a DMARC checker cannot prove a rollout is complete, because it only shows the record visible in public DNS at that moment. It cannot confirm client authorization, the production sending path, whether the state holds over time, or whether every sender's evidence has been collected. Completion is a decision recorded against evidence, and the checker supplies one line of it. --- # DMARC report analyzer self hosted Canonical: https://www.palisade.email/learning/dmarc-report-analyzer-self-hosted > DMARC report analyzer self hosted workflow: validate a parser with a redacted aggregate report, interpret its evidence, and retest safely in stages. A self-hosted DMARC report analyzer should be validated with a redacted aggregate-report fixture before it receives production reports. Confirm that the analyzer can produce a documented parser result or a reproducible configuration error, then compare its findings with the published DMARC record and later with real aggregate reports. A public record check helps inspect DNS, but it cannot prove the analyzer parsed a report or that a production sender authenticated. ## Quick takeaways - Validate a self-hosted analyzer with a redacted aggregate-report fixture before changing DNS, mailbox, or infrastructure settings. - Keep parser output, configuration errors, published DNS, and delivered-message evidence as separate observations. - A public DMARC record check can inspect the published record, but it cannot inspect a local parser, mailbox ingestion path, or stored report data. - Do not treat illustrative fields shown on vendor pages as a complete report schema or as evidence of a particular analyzer's behavior. - Stop the investigation when the selected analyzer returns a documented parsed result or a reproducible configuration error. - Hold deployment, DNS, mailbox, and infrastructure changes for human approval. ## What this tool checks A self-hosted DMARC report analyzer is separate from a public DNS checker. Its immediate job in this workflow is to accept a selected, redacted aggregate-report fixture and return either a parser output that its own documentation explains or an error that can be reproduced. Use the [Palisade DMARC checker](/tools/dmarc) alongside that local test to inspect the published DMARC record for the domain under review. This is useful DNS evidence when you need to compare a record change with report evidence. It does not show whether a self-hosted analyzer received, parsed, stored, or redacted an aggregate report. It also cannot prove the production sending path, message signing, continuous state, a receiver's private decision, or future delivery. If you need background before reviewing analyzer output, start with the [DMARC learning hub](/learning/dmarc). For report terminology, use [What are DMARC aggregate reports?](/learning/email-questions/what-are-dmarc-aggregate-reports). Keep those explanations separate from the selected analyzer's own documented input and output contract. ![Decision record for a self-hosted DMARC analyzer validation](/images/editorial/dmarc-report-analyzer-self-hosted/dmarc-report-analyzer-self-hosted-validation-record.webp "1200x582") *Source: Palisade.* ## How to run the check ### 1. Select one analyzer and its documented test path Choose one self-hosted analyzer before collecting evidence. Use its official documentation or repository to identify the documented parser command, fixture format, required configuration, and expected output location. Do not combine setup instructions from several analyzers. A parser command, storage setting, mailbox ingestion method, or retention option only applies when the selected project's documentation supports it. ### 2. Prepare a redacted aggregate-report fixture Use a fixture that contains no credentials, private keys, tokens, customer data, or unredacted message headers. Preserve the structure required for the selected analyzer's documented parser test. Record the fixture's source, redaction method, command, configuration version, and timestamp in your internal change record. This makes a later failure reproducible without exposing report contents. > Do not point a new parser at a production mailbox or change a DMARC reporting address until the local fixture test has a documented result and the owner approves the change. ### 3. Run the analyzer's documented parser test Run the exact parser command or test procedure supplied by the selected analyzer. Save the complete redacted output, including exit status and any error text. Do not paraphrase errors when escalating them. The exact message can distinguish a parser failure from a missing configuration value or an inaccessible dependency. A public DNS lookup is a separate repeatable check. Replace the example domain with the domain you are investigating: ```bash dig +short TXT _dmarc.yourdomain.com ``` This command returns a public DNS answer only. It does not test local report ingestion, parsing, storage, or notification behavior. ### 4. Check the published DMARC record separately Open the [Palisade DMARC checker](/tools/dmarc) and inspect the sending domain's published record before associating a parser result with a policy change. Preserve the time of the DNS check beside the local parser output. A record check answers a narrower question than the fixture test: whether a public DMARC record is visible at the time of the lookup. It cannot establish why an analyzer rejected a fixture or whether a report reflects the intended production path. ## How to interpret the results ### The analyzer returns a documented parsed result Treat a documented parsed result as evidence that the selected fixture passed through the analyzer's documented test path. Compare the returned fields and disposition labels with the selected analyzer's documentation. Do not assume that a field shown by one vendor or parser must appear in every implementation. For example, some vendor marketing pages show fields such as `source_ip`, `count`, `SPF`, `DKIM`, and `disposition`. Those examples are not a complete universal schema, and they do not prove that your selected analyzer should display the same labels. Next, determine whether the output identifies the report source, the observed sending source, authentication evidence, and the policy disposition in the way the selected analyzer documents. If it does not, keep the result as a parser-specific issue rather than diagnosing a DMARC policy problem. ### The analyzer returns a reproducible configuration error A reproducible configuration error means the selected documented test cannot complete with the supplied configuration. Preserve the command, redacted fixture identifier, error text, and the relevant configuration location. Compare them with the analyzer's official documentation before changing any infrastructure. Do not use a passing public DMARC lookup to dismiss this result. DNS can be correct while a local parser still lacks a required dependency, permission, configuration value, or supported fixture format. ### The published DMARC record differs from your expected record A record difference is DNS evidence. First confirm the exact domain and the lookup time. Then compare the public answer with the record your organization intended to publish. Keep this finding separate from analyzer output until a real report or delivered-message result establishes a connection. The [open-source DMARC report analyzer selection guide](/learning/dmarc-report-analyzer-open-source) can help when the issue is tool fit rather than a single parser failure. ### The evidence does not connect to production mail A successful fixture test and a visible public record do not prove that production reports are arriving or that a specific production sender is represented correctly. Move to the next evidence layer only after the local test is stable: - Check authoritative DNS and at least one public resolver for the intended record. - Verify the selected analyzer's own ingestion or processing status using its documented operator path. - Inspect a real delivered message from the exact production path when message authentication is in question. - Review aggregate-report data after it accumulates. Each layer answers a different question. Do not use a green result at one layer as proof for another. ![Four evidence layers for validating a self-hosted DMARC report analyzer](/images/editorial/dmarc-report-analyzer-self-hosted/dmarc-report-analyzer-self-hosted-four-evidence-layers.webp "1200x906") *Source: Palisade.* ## How to act on the result When the fixture produces documented output, retain the redacted output as a baseline. Then prepare the selected analyzer's deployment or ingestion change for review. Keep any mailbox, DNS, database, storage, retention, or infrastructure mutation outside the test until the responsible owner approves it. When the fixture produces a reproducible error, narrow the change to the selected analyzer's documented requirement. Inspect the configuration and repository first. Propose one minimal correction, identify how to roll it back, and rerun the same fixture test before expanding scope. When the public record differs from the expected record, correct only the intended DNS owner after comparing it with the organization-approved value. Do not copy report addresses, record values, or configuration from another tenant or domain. If your goal is to choose an approach rather than repair one configured parser, compare the operational requirements in [Best DMARC report analyzers](https://www.palisade.email/compare/best-dmarc-report-analyzers). A selection decision is not evidence that a deployment is working. ## Investigate this with your coding agent Use this after you have a selected analyzer, its documented test procedure, and a redacted fixture result. Prepare only redacted output and configuration locations that the agent can inspect without credentials or production access. ```agent Problem: The selected self-hosted DMARC report analyzer does not yet have a documented parsed result for a redacted aggregate-report fixture, or it returns a reproducible configuration error. Evidence: Selected analyzer name and version, redacted fixture path, documented parser command, redacted command output and exit status, and relevant redacted configuration paths. Repository scope: The selected analyzer repository, its documented test fixtures, parser configuration, and local test files only. Constraints: Inspect before editing. Do not apply changes until I approve the proposed diff. Do not access credentials, private keys, tokens, unredacted headers, customer data, production mailboxes, DNS, or infrastructure. Requested output: Diagnosis, minimal proposed change, rollback, and unknowns. Verification: Run the selected analyzer's documented parser test again against the same redacted fixture and record its output or reproducible error. Stop if: Credentials, private data, production mutation, DNS or mailbox changes, or missing analyzer documentation or fixture evidence is required. ``` ## How to retest Repeat the exact documented parser test against the same redacted fixture after an approved local change. A successful retest should produce the analyzer's documented parsed result. If it returns an error again, preserve the new output and compare it with the first run before making another change. Then repeat the public DNS lookup and the [Palisade DMARC checker](/tools/dmarc) only when the published record is relevant to the change. Expect a record check to reflect the public DNS state, not the local parser state. After deployment is approved and report data accumulates, validate the four layers again: authoritative and public DNS, the analyzer's documented status, a real delivered message from the production path when applicable, and aggregate-report evidence. This avoids promoting a local parser result into a claim about all production mail. ## Check the published DMARC record beside the parser evidence Once the local fixture test has a documented outcome, inspect the sending domain's public DMARC record and compare its timing with the parser run. This helps separate a DNS mismatch from a local analyzer configuration issue. [Check the published DMARC record](/tools/dmarc) A public record check cannot parse a local fixture, repair an analyzer, monitor report ingestion, prove a production sending path, or guarantee delivery. ## Sources and further reading - [Palisade DMARC checker](/tools/dmarc) - [DMARC learning hub](/learning/dmarc) - [What are DMARC aggregate reports?](/learning/email-questions/what-are-dmarc-aggregate-reports) - [Open-source DMARC report analyzers: how to choose](/learning/dmarc-report-analyzer-open-source) - [Best DMARC report analyzers](https://www.palisade.email/compare/best-dmarc-report-analyzers) ## Frequently asked questions ### Can a public DMARC checker validate a self-hosted report analyzer? No. A public DMARC checker can inspect the published DMARC record. It cannot access a local fixture, parser configuration, report storage, mailbox ingestion path, or the analyzer's error output. ### Should I connect a production reporting mailbox before testing a fixture? No. First run the selected analyzer's documented parser test against a redacted fixture. Hold mailbox, DNS, and infrastructure changes until the test has a documented parsed result or a reproducible error and an owner approves the next change. ### Does a parsed fixture prove that production mail is correctly represented? No. It proves only that the selected fixture completed the selected analyzer's documented test path. Production validation still needs DNS, analyzer-status, delivered-message, and accumulated aggregate-report evidence where applicable. ### What should I save when the parser fails? Save the selected analyzer version, documented command, redacted fixture identifier, redacted configuration location, complete error output, exit status, and timestamp. This is the minimum evidence needed to reproduce the failure without sharing secrets or customer data. ### Can I use example report fields from another analyzer as a validation checklist? No. Vendor examples are illustrative unless the selected analyzer's own documentation defines the same fields and meanings. Validate output against the documentation for the analyzer you are actually operating. --- # DMARC reporting template for MSPs Canonical: https://www.palisade.email/learning/dmarc-reporting-template-for-msps > DMARC reporting template for MSPs: track client domains, sender authentication evidence, exceptions, ownership, DNS changes, SLA status, and decisions. A DMARC reporting template for MSPs should give every client the same evidence trail: domain status, observed senders, SPF, DKIM, and DMARC results, open exceptions, DNS changes, owners, review dates, and decisions needed from the client. The report is not a compliance score. It is a portfolio operating record that lets an MSP show what is known, what remains unresolved, and who controls the next action. ## Quick takeaways - Use one reporting structure across clients, while keeping each client's domains, approvals, and exceptions separate. - Report sender evidence and ownership, not only the published DMARC policy. - A public DNS result confirms a published record, but it does not prove the production sender authenticates. - Give every unresolved item an owner, next action, review date, and client decision status. - Treat reporting cadence and SLA definitions as a practical service framework, not a protocol requirement. - Keep DNS hosts, sending platforms, receiving mailbox providers, clients, and the MSP accountable for their own controls. ## Operating context and ownership An MSP reporting process changes when the service covers many client organizations. Each client needs a clear record of its own sending domains, sources, business-critical mail paths, approvals, and accepted risks. The MSP needs a portfolio view that makes overdue work and blocked decisions visible without mixing tenant evidence. DMARC reports are useful because they can show sending sources and authentication outcomes. A DMARC reporting platform may process aggregate and forensic reports and present SPF, DKIM, and DMARC pass or fail information. For client stakeholders who need protocol context, link the reporting discussion to [what DMARC checks](/learning/what-is-dmarc). This article's template is a Palisade practical operating framework. It is not an industry-standard report layout or a protocol requirement. Set the service boundary in writing for each client: - The client approves business risk, confirms whether a sender is legitimate, and authorizes material changes. - The MSP collects evidence, maintains the report, coordinates remediation, and recommends the next decision. - The DNS host publishes approved DNS records. - The sender owner configures the sending platform and supplies a delivered-message sample when public DNS cannot prove the active path. - The receiving mailbox provider controls its own message handling and private reputation decisions. A report should also name the handoff point. If a marketing platform sends with an unaligned identity, the report must identify the client marketing owner or sender administrator who can act. If DNS ownership is unclear, the item is blocked rather than marked complete. ![Portfolio reporting flow that separates client evidence, MSP review, owner actions, and client decisions](/images/editorial/dmarc-reporting-template-for-msps/dmarc-reporting-template-for-msps-reporting-flow.webp "1200x980") *Source: Palisade.* ## Evidence to collect Create one working record per client domain. Keep evidence dates with the record so a client can distinguish an observed production sender from an onboarding assumption. The reporting template should capture: - Client and domain in scope. - Current published DMARC policy and the date it was checked. - Sender identity, source volume, and whether the sender is client-confirmed, report-observed, unknown, or retired. - SPF, DKIM, and DMARC authentication evidence for the sender. - The evidence source, such as an aggregate report, public DNS answer, delivered-message header, or client confirmation. - Open exception, severity definition used by the MSP, owner, next action, and review date. - DNS changes proposed or completed, including approval and rollback details. - SLA status under the service agreement, plus any decision required from the client. Use a portable format that can live in a PSA ticket, report export, client portal, or internal runbook: ```yaml client: example-client domain: yourdomain.com evidence: sender: billing.example-sender.com source_volume: observed-in-report spf_status: pass-unverified-alignment dkim_status: pass dmarc_status: pass source: aggregate-report-and-header-sample owner: client-email-admin next_action: confirm-billing-sender-and-retain-header-sample review_on: 2026-09-01 ``` The status labels are a reporting convention. They do not replace protocol results. For example, `pass-unverified-alignment` can mean the available record check looks correct but the MSP has not yet retained a message from the exact production path. For the DNS portion of the report, use the [DMARC checker](/tools/dmarc) to inspect the public record. When an observed source needs SPF or DKIM remediation, the [SPF checker](/tools/spf) and [DKIM checker](/tools/dkim) can help inspect published DNS evidence. These checks do not prove that the application is currently using the expected return path or signing key. > Do not mark a sender as remediated solely because a DNS record exists. Confirm the sender's current status and retain evidence from a real delivered message when the production path matters. ## How to run the workflow ### 1. Set the client reporting scope **Owner:** MSP service owner. **Input:** Approved client domain list, contacts, service boundary, and reporting cadence. **Output:** A client scope record with an approver and escalation contact. Record which domains are in scope, which are parked or retired, and which subdomains send mail independently. Identify business-critical sending paths such as billing, support, marketing, and application mail. A domain without an accountable client contact remains an onboarding exception. ### 2. Collect and label the evidence **Owner:** MSP analyst. **Input:** DMARC reporting data, public DNS checks, client sender inventory, and delivered-message samples where available. **Output:** A dated sender inventory with evidence labels. Separate what the client says should send mail from what reports show. A sender can be client-confirmed but not yet observed. Another can be report-observed but unknown to the client. Keep these states separate because they require different decisions. A public DMARC record check belongs in the report, but it only captures one point in time. If an authentication issue appears for a sender, the remediation ticket should state whether the next evidence must come from DNS, the sending platform, or a raw delivered message. ### 3. Turn exceptions into owner-specific work **Owner:** MSP analyst assigns, client or sender owner completes. **Input:** Unknown sender, authentication failure, missing approval, DNS discrepancy, or overdue review. **Output:** A tracked exception with a defined completion test. Write the exception as an observable condition. For example: ```text Exception: Invoice sender appears in report data with DMARC failure. Owner: Client finance systems owner. Next action: Confirm whether the sender is legitimate and provide a redacted delivered-message header. Completion test: SPF or DKIM passes and aligns on the confirmed production path, or the sender is documented as unauthorized. ``` Do not use “fix DMARC” as the task description. The owner needs to know what evidence is missing and what outcome will close the item. ### 4. Review DNS changes before reporting them as complete **Owner:** DNS change owner, reviewed by the MSP. **Input:** Approved DNS change, previous value, intended value, and rollback condition. **Output:** A change record with verification evidence. Report a DNS change separately from sender remediation. The DNS host can publish a record, but the sender platform may still use another identity or selector. Record the before value, approved after value, publication time, public resolver result, and the message-level validation still required. ### 5. Request client decisions at the reporting boundary **Owner:** Client approver. **Input:** Exceptions that have evidence but require business authorization or risk acceptance. **Output:** Approved action, accepted exception, or deferred decision with a new review date. Use a distinct decision section in each client report. Examples include an unconfirmed sender, a business-critical system without a safe test window, or a proposed policy-stage change. The MSP can recommend a path, but the client owns the business decision unless the agreement delegates that authority. The related [DMARC policy rollout across client domains](/learning/dmarc-policy-rollout-across-client-domains) process can help keep policy decisions separate from routine reporting work. ### 6. Publish the client report and update the portfolio queue **Owner:** MSP service owner. **Input:** Reviewed evidence, exception updates, DNS changes, SLA state, and client decisions. **Output:** Client report, internal portfolio queue, and next review date. Use the same headings for every client. A consistent template makes it easier to compare open work without treating clients as identical. Include a short executive section, followed by an operational appendix for senders, evidence, changes, and exceptions. The report should state the date range and evidence boundary. It should not claim that every future message will authenticate or that a receiver will deliver every message. ## Investigate this with your coding agent Use this when a redacted reporting export or runbook exists but fields are inconsistent across clients. Remove private headers, recipient data, tokens, credentials, and customer identifiers before sharing evidence. ```agent Problem: A multi-client DMARC report has inconsistent fields for sender evidence, ownership, exceptions, and review dates. Evidence: Redacted reporting export or runbook, field names, example anonymized rows, and known report collection locations. Repository scope: The reporting schema, transformation scripts, runbooks, and tests for the MSP reporting workflow. Constraints: Inspect before editing. Do not apply changes until I approve the proposed diff. Do not cross tenant boundaries, access credentials, private keys, tokens, unredacted headers, or customer data. Do not make client or production changes. Requested output: A field-to-evidence mapping, minimal proposed schema or runbook change, rollback, and unknowns. Verification: Confirm every client row has an evidence source, owner, review date, and unresolved-item status in a redacted test export. Stop if: Credentials, private data, production mutation, client authorization, an active incident, or missing evidence is required. ``` ## Exceptions and escalation Use an escalation tree that distinguishes a technical gap from a missing decision: - **Unknown sender with meaningful volume:** Ask the client to confirm ownership. Keep the item open until the sender is confirmed, remediated, or documented as unauthorized. - **Known sender with authentication failure:** Assign the action to the party that controls the sender configuration or DNS. Request message-level evidence after the change. - **DNS change cannot be approved:** Mark the item blocked. Record the approver needed and the next review date. - **Business-critical sender cannot be tested safely:** Escalate to the client approver with the delivery risk, proposed test window, and rollback condition. - **Report data conflicts with the sender inventory:** Treat the conflict as unresolved. Do not remove the observed source because it is absent from an onboarding list. Escalation urgency should follow client impact and the terms of the service agreement. This template does not define universal SLA targets. An MSP may use categories such as urgent, standard, and planned, but each category needs a documented client-facing definition. ## Reporting and success measures Use a monthly operational report and a quarterly service review. The monthly artifact should cover current evidence and work ownership. The quarterly review should show trend, decisions, overdue exceptions, and changes to the service scope. Track measures that expose operational state: - In-scope domains with a named client approver. - Domains with current sender evidence. - Open exceptions by owner and age. - Overdue reviews and blocked approvals. - DNS changes with before, approval, after, and rollback records. - Sender remediation items with a delivered-message verification result. These measures do not prove universal protection, inbox placement, or a receiver's private handling decision. They show whether the MSP has a current, accountable process for each client domain. For a recurring managed-DMARC service, align the report structure with the client onboarding and policy workflow. The [DMARC onboarding checklist for MSPs](/learning/dmarc-onboarding-checklist-for-msps) can provide the intake handoff that feeds this reporting template. ## Build a repeatable reporting workflow for your client portfolio A shared reporting template exposes the recurring portfolio gap: one-off checks cannot maintain sender evidence, exception ownership, approvals, and review dates across many client domains. Palisade is agentic DMARC software that analyzes DMARC aggregate-report data, identifies sending sources and authentication or alignment issues, and creates prioritized remediation tickets. A human reviews the evidence and applies any change. [Book a demo](https://calendly.com/sam-palisade/30min) [Start a Palisade account](https://app.palisade.email/signup) A demo does not prove a client's current production sending path, authorize DNS changes, repair every sender, or guarantee how receiving mailbox providers handle mail. ## Sources and further reading - [Palisade documentation](https://docs.palisade.email/) - [DMARCReport reporting platform overview](https://dmarcreport.com) - [PowerDMARC guidance on moving from monitoring to enforcement](https://powerdmarc.com) ## Frequently asked questions ### What should an MSP include in a DMARC client report? An MSP DMARC client report should include domains in scope, sender evidence, SPF, DKIM, and DMARC status, unknown or unauthorized sources, open exceptions, owner assignments, DNS changes, review dates, SLA state, and decisions required from the client. ### Should every client receive the same DMARC report? Yes, the report structure should be consistent so the MSP can operate a portfolio reliably. The evidence, sender inventory, approvals, exceptions, and business priorities must remain client-specific. ### Can a DMARC DNS check prove a sender is fixed? No, a DNS check can confirm the public record returned at the time of the check. It cannot prove that a production application uses the expected return path, DKIM selector, or authenticated identity. Retain evidence from a delivered message for the relevant sending path. ### Should an MSP report unknown sending sources to the client? Yes, unknown sources should appear as open exceptions with the observed evidence, a client confirmation request, an owner, and a review date. Do not silently remove an observed source because it is absent from the original sender inventory. ### Does a client report prove that all future mail will pass DMARC? No, a report describes the evidence available for its stated period. New senders, DNS changes, configuration drift, and receiver-specific decisions can change the outcome after the report is issued. --- # DMARCly DMARC checker: what its free report can show Canonical: https://www.palisade.email/learning/dmarcly-dmarc-checker > DMARCly DMARC checker guidance: use its free emailed report, separate message results from published DNS, then re-test an intended record change. DMARCLY offers a free DMARC report by email and describes its dashboard as able to generate or check DMARC, SPF, and DKIM records. Send a test message to its published report address, review the returned results for that message's sender domain, then keep that evidence separate from a public DNS lookup. Readers comparing vendor workflows can also review Palisade's [DMARC comparison resources](/compare). ## Quick takeaways - DMARCLY says its free report analyzes the sender domain and includes SPF, DKIM, and DMARC results. - The published DMARCLY report path is sending an email to `dmarc@dmarcly.com`. - A result for one submitted message is evidence about that message path, not every sender that uses the domain. - DMARCLY describes `p=none`, `p=quarantine`, and `p=reject` as monitoring, quarantine, and reject modes. - A public DNS recheck is useful after an intended record change, but it does not prove a delivered message authenticated. - Do not choose a DMARC enforcement policy from a checker result alone. ## What this tool checks [DMARCLY](https://dmarcly.com) describes itself as an SPF, DKIM, and DMARC monitoring solution. Its public site says the dashboard can "generate/check DMARC/SPF/DKIM records" and offers a free DMARC report when you send an email to `dmarc@dmarcly.com`. The documented report path is message-based. DMARCLY states that the report analyzes the sender domain and includes SPF, DKIM, and DMARC results. That makes the submitted message and returned report the evidence to retain when investigating a specific sending path. The available public description does not establish a separate checker URL, required form input, submit control, error messages, result labels, or a mapping between a report outcome and a specific DNS repair. Treat any report wording you receive as account-specific evidence. Do not assume that another domain, sender, or time will produce the same result. A public check has a different job. The [Palisade DMARC checker](/tools/dmarc) is an appropriate next step only when you have an intended published-record change to compare. A public record check cannot prove the production sending path, message signing, continuous state, a receiver's private decision, or future inbox placement. ![DMARCLY product dashboard overview](/images/editorial/dmarcly-dmarc-checker/dmarcly-dmarc-checker-shot-1.png "1600x900") *Source: [DMARCLY](https://dmarcly.com), checked 2026-08-13.* ## How to run the check ### 1. Send a message through the path you need to inspect Send a new test email through the same application, visible From domain, and routing path that you are investigating. DMARCLY instructs users to send an email to `dmarc@dmarcly.com` to obtain its free report. Use a controlled test message where possible. Record the sending application, visible From address, approximate send time, and recipient address used for the test. Those details help distinguish one path from another if the same domain is used by several systems. ### 2. Save the returned report with the test details Keep the report together with the exact message path used to create it. The report is evidence for the sender domain DMARCLY analyzed, but a domain can have more than one sender and each sender can authenticate differently. If the report identifies an issue, do not change DNS immediately. First determine whether the report concerns the sender you intended to test. A marketing platform, support system, and corporate mailbox can all use the same visible domain while relying on different authentication configurations. ### 3. Check the currently published DNS answer separately Use a DNS lookup after you know the record owner and value you expect to publish or have changed. This command retrieves the public TXT answer for an example DMARC record: ```bash dig +short TXT _dmarc.yourdomain.com ``` Replace `yourdomain.com` with your own domain. A DNS answer shows what a resolver can retrieve at that moment. It does not show whether the tested sender used that domain for aligned SPF or DKIM, and it does not explain a receiver's decision about a particular message. ## How to interpret the results ### A free report is available for the submitted message DMARCLY says, "It only takes 20 seconds to get your free DMARC report," and says that the report includes SPF, DKIM, and DMARC results. Read the returned information as message-path evidence for the message you sent. The useful question is narrow: what did the report observe for this submitted message and sender domain? It is not a domain-wide inventory. Send a separate test for each important mail stream when the same visible domain is used by multiple systems. ### The report refers to DMARC policy modes DMARCLY describes these policy stages: - Monitoring mode: `p=none` - Quarantine mode: `p=quarantine` - Reject mode: `p=reject` These labels identify the policy values DMARCLY describes. They do not establish that a domain is ready to move to the next stage, nor do they predict how every mailbox provider will handle every future message. If you need a broader explanation of the policy terms before assessing a report, use [how DMARC works](/learning/what-is-dmarc). Keep the policy decision separate from the report itself. A safe enforcement decision requires evidence about the production senders that use the domain, including their authentication and alignment outcomes over time. ### A public DNS answer differs from a message result A DNS lookup and an emailed report answer different questions: - The emailed report concerns the sender domain and authentication results observed for the submitted message. - The DNS lookup returns the public TXT answer currently available for `_dmarc.yourdomain.com`. - Neither observation alone proves every current sender that uses the domain. - Neither observation alone establishes a receiver's future delivery or spam decision. When a report and DNS answer appear to disagree, preserve both results and compare their timestamps. DNS may have changed after the message was sent. The message may also have traveled through a sender that differs from the one you expected to test. ![Decision map for separating a DMARC report from a public record recheck](/images/editorial/dmarcly-dmarc-checker/dmarcly-dmarc-checker-result-map.webp "1200x829") *Source: Palisade.* ## How to act on the result Start with the evidence that is closest to the problem. If the DMARCLY report relates to the expected sender and indicates an authentication or DMARC concern, collect the raw headers from a delivered copy of the same message before changing policy. The receiver-added `Authentication-Results` field is message evidence, and it helps confirm what the receiving system evaluated. If the problem is a delivery failure, use the [DMARC failure troubleshooting guide](/learning/dmarc-failure-for-domain) to separate domain-level policy from the evidence for the failed message. If the message path is unclear, repeat the test through the exact application that matters. Do not infer the behavior of every sender from a message sent through one mailbox. For an important production source, validate whether its SPF or DKIM identity aligns with the visible From domain by following the [DMARC alignment check](/learning/check-dmarc-alignment). If the DNS record itself needs an intended update, obtain the proposed value from the system or policy owner responsible for the domain. Do not copy a record value, reporting destination, or configuration from another organization. Compare the intended value with the authoritative DNS answer before publishing it. > Do not move from `p=none` to `p=quarantine` or `p=reject` solely because one test message produced a favorable result. A policy change can affect legitimate mail from sources that were not part of that test. ## How to retest After an approved DNS change, query the same DMARC owner again and compare the returned answer with the exact intended value: ```bash dig +short TXT _dmarc.yourdomain.com ``` Then send a new message through the same application and repeat the DMARCLY report workflow. Compare the new report only with a message sent after the DNS change was visible. Preserve the earlier result as the before state. For a fuller validation sequence, keep four observations separate: - Authoritative and public DNS answers for the changed record. - The sending service's own current authentication or verification status, if it provides one. - Raw headers from a newly delivered message sent through the same production path. - DMARC aggregate-report evidence once enough mail has accumulated. A green application setting is not proof that a receiver saw the expected authentication result. Likewise, a valid public DNS answer is not proof that the application used the configured identity on a real message. ## Recheck the published record after an intended DNS change When you have changed a DMARC record and know the value you expect to see, use the [Palisade DMARC checker](/tools/dmarc) to inspect the public record again. Compare that result with the new message report and raw headers from the same sender path. [Check the published DMARC record](/tools/dmarc) A public record check does not repair DNS, monitor every sender, prove that a particular message passed authentication, or guarantee how a mailbox provider will handle future mail. Palisade is DMARC software that analyzes aggregate-report data, identifies authentication or alignment issues, and proposes next policy steps for human review. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=tools_vendors_comparisons&utm_content=dmarcly-dmarc-checker). ## Sources and further reading - [DMARCLY](https://dmarcly.com) - [Palisade DMARC checker](/tools/dmarc) - [What is DMARC?](/learning/what-is-dmarc) - [Check DMARC alignment](/learning/check-dmarc-alignment) ## Frequently asked questions ### Does DMARCLY offer a free DMARC report? Yes, DMARCLY offers a free report, obtained by sending an email to `dmarc@dmarcly.com`. Its public site says the report analyzes the sender domain and includes SPF, DKIM, and DMARC results. The report covers the message you sent, so send it from the application you actually want to test. ### Can a DMARCLY report prove every sender on my domain is configured correctly? No, one report only covers the message you submitted and the path that sent it. A domain usually has several senders, such as a mail platform, a marketing tool, and a billing system, and each has its own authentication setup. Test every important application separately when they all use the same visible domain. ### Does a public DMARC record check prove that a message passed DMARC? No, a public record check cannot show that, because it reads the DNS record and nothing about a specific message. It does not reveal the SPF and DKIM identities a delivered message used, or the result the receiving system recorded. Send a real message and read the `Authentication-Results` header it comes back with. ### Does `p=none` mean the domain is ready for enforcement? No, `p=none` only means receivers are reporting rather than acting, which is the start of the work and not the end of it. DMARCLY calls it monitoring mode, and the point of that mode is to reveal senders that still fail. Review production message evidence and aggregate reports until every legitimate sender passes, then move to `p=quarantine` or `p=reject`. ### Should I retest after changing a DMARC record? Yes, retest after every DMARC record change, because an earlier report describes the record that was live before the edit. Compare the public DNS answer with the value you intended to publish. Then send a new message through the same sender path and review the fresh authentication results. --- # Email authentication in Mailchimp: what to verify first Canonical: https://www.palisade.email/learning/email-authentication-mailchimp > Email authentication Mailchimp requires current Mailchimp setup documentation and DNS evidence. Learn what to verify before changing a sending domain. Email authentication in Mailchimp is an email-sending-domain task that must be confirmed against Mailchimp's current domain-authentication documentation and your domain's DNS. [Mailchimp describes its service as an email and SMS marketing platform](https://mailchimp.com/), but its public homepage does not document the current domain-authentication procedure, record values, verification states, or settings path. Do not publish or change DNS from an assumed setup flow. ## Quick takeaways - Mailchimp's public homepage identifies Mailchimp as an email and SMS marketing platform. - A Mailchimp-specific authentication procedure needs current official Mailchimp Help Center documentation. - DNS records must come from the sending service's current account-generated instructions, not a generic example. - A public DNS result does not prove that Mailchimp is using the configured sending path. - A vendor verification indicator does not replace a delivered-message header check. - Use the [ESP setup hub](/learning/esp-setup) to route a sending-domain task to the provider documentation that owns it. ## What email authentication means for a Mailchimp sending domain Email authentication is the process of establishing evidence that a sending domain is authorized for the message path in use. For a Mailchimp campaign, the operational question is narrower: which domain appears in the campaign's visible From address, and what current configuration does Mailchimp require for that domain? That distinction matters because a marketing platform can send email, while the domain owner still controls the domain's DNS and the visible identity recipients see. A DNS record can exist without the application using it. An application can show a completed setup state while a later DNS change prevents the intended result. A delivered message provides separate evidence about the path that actually sent it. For a protocol-level explanation of the terms involved, start with [email authentication](/learning). The separate question of why authenticated sending matters is covered in [what is email authentication and why does it matter](/learning/what-is-email-authentication-and-why-does-it-matter). The current Mailchimp public homepage is not enough evidence to state: - The current Mailchimp menu path for domain authentication. - Which DNS record types Mailchimp requests. - The hostnames, values, selectors, or CNAME targets Mailchimp generates. - The labels Mailchimp uses for pending, verified, failed, or authenticated states. - Whether Mailchimp offers a contact-list verification feature, and what it checks. - What "add an authenticator" means in a Mailchimp account. Those are account and product-interface facts. They can change independently of email authentication standards. ![Decision flow for deciding whether Mailchimp domain-authentication evidence is sufficient before changing DNS](/images/editorial/email-authentication-mailchimp/email-authentication-mailchimp-evidence-decision.webp "1200x829") *Source: Palisade.* ## When the answer changes Use the evidence you have to choose the next action. - If you only have the sending domain, inspect its current public authentication posture. This can reveal published DNS records, but it cannot confirm Mailchimp's account settings or a campaign's real sending path. - If Mailchimp provides current official domain-authentication instructions, use the exact records generated for the account and domain. Do not substitute values from another account, a forum post, or an old guide. - If DNS has already been changed, compare the authoritative DNS answer and a public resolver result with the approved values from Mailchimp. - If Mailchimp shows a successful status, send a controlled message through the exact production campaign path and retain the delivered message's raw headers. - If messages have been sending for long enough to produce reporting data, use DMARC aggregate reports to identify the sources and authentication outcomes associated with the domain. > Do not replace existing DNS records based on an assumed Mailchimp configuration. A misplaced or overwritten record can interrupt legitimate mail from another service. The usable decision rule is: only treat a Mailchimp sending domain as configured when the vendor's current account instructions, DNS evidence, and a delivered message from that same path agree. Each layer answers a different question. ## A worked evidence checklist for Mailchimp Use this checklist before declaring Mailchimp email authentication complete. It is intentionally evidence-based because the Mailchimp-specific record shape and UI path must come from Mailchimp's current official documentation. ```text Mailchimp sending-domain evidence checklist Visible From domain: yourdomain.com Current Mailchimp documentation: official URL and access date Mailchimp account instruction: record type, hostname, and value generated for this domain Authoritative DNS result: matches the approved Mailchimp instruction Public resolver result: matches the authoritative result after propagation Mailchimp verification status: current status captured from the account Delivered test message: sent through the intended Mailchimp campaign path Raw message headers: retained and reviewed for authentication results DMARC reporting: reviewed after aggregate data becomes available ``` The checklist separates four validation layers: - DNS confirms what the domain publishes. - Mailchimp confirms what the provider account reports for its configured domain. - A delivered message confirms evidence from the exact sending path. - DMARC aggregate reports can reveal patterns across sending sources after reporting data accumulates. A positive result at one layer does not settle the others. For example, a public DNS check can show a record, but it cannot prove that a particular Mailchimp campaign used the intended domain or that a receiving mailbox provider made a particular delivery decision. ## What to do next with the evidence you have If you are preparing a Mailchimp domain for authenticated sending, obtain the current official Mailchimp Help Center page for that task from within Mailchimp's support documentation. Use the provider-generated values for your own domain, then preserve the existing DNS records before proposing a change. If you have already completed a Mailchimp setup, inspect the public posture of the exact visible From domain with Palisade's [Email Security Score](/tools/email-security-score). Use it as a DNS-oriented check, then compare the result with the Mailchimp account instructions and a raw header from a real campaign message. If the domain publishes a DMARC record, a dedicated record lookup can help you inspect that public policy. It still cannot prove that Mailchimp signed a particular message, identify every production sender, or predict a receiver's inbox placement. Delivery questions belong with the message headers, the sending provider's status, and the receiving provider's own evidence. ## Read the email authentication guide before changing Mailchimp DNS Use [Palisade's email authentication guide](/learning) to understand the evidence each authentication layer provides before following Mailchimp's current provider instructions. A general guide and a public DNS check cannot supply Mailchimp's account-generated record values, repair a provider configuration, confirm an individual campaign path, or guarantee future delivery. ## Sources and further reading - [Mailchimp](https://mailchimp.com/) - [Email authentication](/learning) - [Palisade Email Security Score](/tools/email-security-score) - [ESP setup guides](/learning/esp-setup) ## Frequently asked questions ### How to authenticate an email domain on Mailchimp? Open Mailchimp's current Help Center instructions for domain authentication and use the DNS records it generates for your own account and domain. Publish those exact records in your domain's DNS, leaving records that belong to other senders in place. Then check the published DNS answer, the status Mailchimp shows for the domain, and the headers of a real message sent through the campaign path you use in production. ### Does Mailchimp do email verification? Mailchimp does not say on its public homepage whether it verifies contact lists, what such a feature would check, or what limits apply to it. Look for the feature in the current Mailchimp Help Center before you rely on it. Address verification and domain authentication are separate jobs, so a list-cleaning feature would not authenticate your sending domain. ### How do I enable email authentication? For a Mailchimp sending configuration, use Mailchimp's current official instructions for the exact domain and account. Then confirm the published DNS records, review Mailchimp's current status, and inspect a real delivered message. A DNS lookup alone does not prove that the sending application is using the configuration. ### How do I add an authenticator to Mailchimp? Mailchimp does not use "add an authenticator" as the name of a domain-authentication task, so decide which job you mean first. If you want authenticated sending, follow Mailchimp's current domain-authentication instructions and publish the DNS records it generates for your domain. If you mean login security instead, that is an account setting rather than an email task, so look for it in Mailchimp's account documentation. ### Can a public DNS check prove a Mailchimp campaign is authenticated? No, because a DNS check shows what the domain publishes, not what a campaign did. It cannot confirm your Mailchimp account configuration, the path one campaign actually used, how a recipient evaluated the message, or where future mail will land. --- # Email IP warmup Canonical: https://www.palisade.email/learning/email-ip-warmup > Email IP warmup is a sending-infrastructure practice offered by some email platforms. Check authentication and delivery evidence before attributing a. Email IP warmup is a sending-infrastructure practice that some email platforms offer alongside direct sending IPs. It is not an email-authentication protocol, and it does not prove that a message will reach an inbox. Treat it as one part of a broader [email deliverability](/email-deliverability) investigation: first confirm the production sender, authentication results, and observed delivery outcomes. ## Quick takeaways - Email IP warmup is an infrastructure concern, not a DMARC, SPF, or DKIM setting. - Bird lists "Managed warm-up" alongside direct sending IPs in its email product offering. - A warmup claim does not prove that a specific message was delivered, accepted, or placed in an inbox. - Authentication and sending infrastructure are separate checks, even when an email provider offers both. - Delivered, bounced, complained, and queued are distinct outcomes worth observing during a sending change. - A public security check can identify published authentication posture, but it cannot reveal a receiver's private placement decision. ## How email IP warmup fits into sending infrastructure An IP address is a network identifier used to route traffic. In email operations, a sending platform may use IP infrastructure as part of the path that submits messages to recipient systems. [Bird's email product page](https://bird.com) advertises "Direct sending IPs" and "Managed warm-up" in the same product description, alongside ISP-aware routing and authentication handling. That placement supports a narrow conclusion: IP warmup is related to the sending infrastructure a platform manages. It should not be described as a universal protocol requirement or as a guaranteed delivery technique. No DMARC record tag enables IP warmup, and no SPF or DKIM result confirms that a platform has warmed an IP. Email authentication answers a different question. DMARC evaluates whether SPF or DKIM passes with a domain aligned to the visible From domain. A message can have authentication evidence that needs review even when the sending service offers managed warm-up. For the protocol basics, see [what DMARC is](/learning/dmarc). The practical distinction matters when a sending change coincides with delivery trouble. Do not assume the infrastructure change is the cause before collecting evidence from the actual production path. A delivered message header, the sender's delivery event, and the receiver's own available diagnostics provide more specific evidence than a product feature label. ![Decision flow for separating an email IP warmup question from authentication and observed delivery evidence](/images/editorial/email-ip-warmup/email-ip-warmup-decision-flow.webp "1200x829") *Source: Palisade.* ## When the answer changes The right next action depends on the evidence you have, not on whether a platform advertises warm-up. Use this decision rule: - If you only know that a platform uses a direct sending IP, treat warmup as a platform capability to clarify with that provider. It does not establish what happened to a particular message. - If you have a bounced, queued, complained, or delivered event, preserve that event and compare it with the message's sending path. Bird documents these as distinct test-mode states in its [email product materials](https://bird.com). - If you have a raw delivered message, inspect its authentication results. The `Authentication-Results` header records a receiver's authentication assessment and is defined by [RFC 8601](https://datatracker.ietf.org/doc/html/rfc8601). - If you see an authentication failure, resolve the SPF, DKIM, or DMARC issue before treating the incident as an IP warmup question. - If authentication passes but placement or acceptance differs across recipients, gather evidence from the affected recipient environment. A public check cannot reveal a mailbox provider's private filtering or future placement decision. > Do not change DNS or sending infrastructure solely because a provider feature description mentions warm-up. First identify the production sending path and compare the change with observed message evidence. This is also why IP warmup should remain separate from broader deliverability work. [Email deliverability](/email-deliverability) includes more than the identity of the sending IP. Authentication, content, recipient-system decisions, and the exact route of a message can all affect what you observe. ## Worked evidence example Suppose a team moves a production stream to a provider that advertises direct sending IPs and managed warm-up. The useful evidence object is not a guessed volume schedule. It is a record of the sending path and the result for an actual message. ```text Illustrative only Sending platform: your-email-provider Visible From domain: updates.yourdomain.com Sending IP: provider-managed IP Observed event: bounced Authentication-Results: recipient.example; spf=pass smtp.mailfrom=mail.yourdomain.com; dkim=pass header.d=yourdomain.com; dmarc=pass header.from=yourdomain.com ``` This example separates the facts that can be checked: - The sending platform and sending IP identify the path that needs investigation. - The visible From domain identifies the domain used for DMARC alignment. - The observed event records what happened to this message in the sender's available evidence. - The authentication results show a receiving system recorded SPF, DKIM, and DMARC passes for this illustrative message. A DMARC pass does not explain every bounce or prove inbox placement. Likewise, an advertised warm-up service does not establish why a recipient handled one message a certain way. Compare evidence from the same production stream before escalating a provider-specific question. For more detail on reputation-related signals, see [what an email blocklist is and how to check one](/learning/blocklist-email). A blocklist lookup may identify a public listing, but it does not prove that a particular receiver rejected mail because of that listing. ## What to check next Start with the evidence closest to the issue: - For a domain-level question, check the currently published security and authentication posture. - For a delivery event, inspect the sender's event record and a raw message from the same production path. - For a receiver-specific decision, use the affected provider's own available dashboard, feedback, or postmaster evidence. - For an ongoing domain portfolio, compare aggregate DMARC-report evidence with the approved sender inventory. A domain check can help prevent a basic authentication gap from being mislabeled as an IP warmup problem. Palisade's [Email Security Score tool](/tools/email-security-score) can inspect public domain security signals before you investigate a sending-infrastructure change. ## Check the domain posture before blaming IP warmup Run the sending domain through the Email Security Score tool to inspect its public authentication and email-security posture. Compare the result with a raw message and the delivery event from the affected production path. [Check the email security score](/tools/email-security-score) A public domain check cannot prove that an IP was warmed, explain an individual receiver's decision, monitor future delivery, or guarantee inbox placement. For an ongoing DMARC reporting workflow, Palisade is agentic DMARC software that analyzes aggregate-report data, identifies sending sources and authentication or alignment issues, and proposes next policy steps for human review. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=warm-up_and_sending_practices&utm_content=email-ip-warmup) Palisade does not control a receiver's private reputation decision, change DMARC policy without human review, or guarantee delivery. ## Sources and further reading - [Bird email product overview](https://bird.com) - [RFC 8601: Message Header Field for Indicating Message Authentication Status](https://datatracker.ietf.org/doc/html/rfc8601) - [Palisade Email Security Score tool](/tools/email-security-score) ## Frequently asked questions ### Is email IP warmup an email-authentication setting? No. Email IP warmup is separate from SPF, DKIM, and DMARC. Authentication results can show whether a message authenticated for a recipient system, while warmup refers to sending infrastructure managed by a platform. ### Does managed warm-up guarantee inbox placement? No. A provider offering managed warm-up does not guarantee delivery, inbox placement, or a receiver's future filtering decision. Recipient systems can apply their own policies and assessments. ### Can a DMARC pass prove an IP warmup worked? No. A DMARC pass shows that DMARC evaluation passed for that message at that receiver. It does not prove anything about an IP warmup process or explain every delivery outcome. ### What evidence should I collect after changing sending infrastructure? Collect the sender's delivery event, the sending platform and production path, and raw headers from a delivered test message where available. Keep the evidence from the same message stream so authentication and delivery observations can be compared. ### Can a public domain check diagnose a recipient-specific rejection? No. A public check can inspect published DNS and domain-level security signals. It cannot reveal why one recipient system rejected, filtered, or placed a message. --- # Email list bounce checker: how to interpret and act on results Canonical: https://www.palisade.email/learning/email-list-bounce-checker > Email list bounce checker results help separate bad, deliverable, and uncertain addresses before sending, then guide list cleanup and retesting. An email list bounce checker helps you sort addresses into likely deliverable, confirmed bad, and uncertain groups before a campaign. Use its result as list-hygiene evidence, then suppress confirmed undeliverable addresses and make a separate policy decision for risky or unknown results. A clean list can reduce one source of delivery trouble, but it does not prove that your sending domain, message, or recipient server will accept every message. ## Quick takeaways - Email verification services can inspect address syntax, domain and MX records, and other signals without sending a message. - A confirmed bad or undeliverable result should usually be removed or suppressed before the campaign. - Risky, unknown, catch-all, and unverifiable results are not confirmed deliverable addresses. - A hard bounce is generally permanent, while a soft bounce may be temporary or fixable. - Retest a list before an important send because an address can become invalid after a contact leaves an organization. - List quality is only one part of [email deliverability](/email-deliverability). ## What this tool checks An email list bounce checker is a verification service that evaluates recipient addresses before you send to them. The exact checks and labels differ by provider. For example, [Email Hippo describes its verification process](https://tools.emailhippo.com) as checking address formatting, the domain's MX records, a non-delivering connection to the receiving mailbox, disposable providers, and bounce history. It says this process identifies "fake emails and possible bounces without ever sending an email." Other services use more detailed categories. [Verifalia lists validation checks](https://verifalia.com) that include syntax, domain, MX, DNS, mailbox availability, spam-trap, catch-all-server, international-address, and disposable-email checks. These are vendor-specific capability descriptions, not a universal standard for every checker. A verification result is useful evidence about the address and its public or service-observable signals at the time of the run. It cannot prove that: - A person actively reads the mailbox. - A future campaign will reach the inbox. - Your production sender will authenticate correctly. - A recipient server will make the same private decision for every future message. - An address marked uncertain will definitely bounce. If a campaign has already produced SMTP errors, use the actual bounce text and message path to diagnose it. The [delivery errors hub](/learning/delivery-errors) separates recipient-list issues from sender, authentication, and receiver-policy failures. ## How to run the check ### 1. Export only the addresses needed for the check Export the intended recipient addresses from the system that will send the campaign. Remove fields that the checker does not need, such as names, message content, notes, account identifiers, and other customer data. Confirm the service's minimum-list rule before preparing a bulk job. For example, [ZeroBounce says bulk list verification requires at least 100 email addresses](https://zerobounce.net). That requirement applies to its service and should not be assumed for another provider. > Do not upload a mailing list to a service until your organization has approved that processor and the data-sharing scope. Recipient addresses can be personal data. ### 2. Submit the list using the checker's supported input Use the input format documented by the checker you selected. Some services offer a single-address check, while bulk tools may use an upload workflow. Keep the original list unchanged so you can match results back to the source system. For a public domain-level sanity check before a list run, inspect whether the domain named after `@` has MX records. This does not verify a specific mailbox. ```bash dig +short MX yourdomain.com ``` An MX answer only shows that DNS publishes mail-exchange information for the example domain. It does not prove that `person@yourdomain.com` exists, that the mailbox accepts mail, or that a future campaign will be delivered. ### 3. Save the result categories with the source address Download or retain the completed result with each source address and its returned status. Do not reduce every status to a yes-or-no field before reviewing what the provider means. [Email Hippo describes its free verifier outcome as "The result is OK, Bad, or Unverifiable."](https://tools.emailhippo.com) [Verifalia uses "Deliverable, Undeliverable, Risky, or Unknown."](https://verifalia.com) The labels are not interchangeable unless the service documents the mapping. ### 4. Separate confirmed failures from uncertain addresses Create distinct segments for confirmed bad or undeliverable addresses and for uncertain outcomes. Preserve the original returned label, check date, and provider result detail. This keeps a later campaign bounce from being mistaken for a list-verification finding. ![Email list bounce checker interpretation map](/images/editorial/email-list-bounce-checker/email-list-bounce-checker-result-map.webp "1200x488") *Source: Palisade.* ## How to interpret the results ### Deliverable or OK A deliverable or OK result means the checker found enough evidence under its own rules to classify the address positively. Treat this as a current verification result, not a delivery guarantee. Before sending, also confirm the sending system is configured correctly. A recipient list checker cannot inspect SPF, DKIM, DMARC alignment, message content, or the reputation associated with your production sending path. ### Bad or undeliverable A bad or undeliverable result is the clearest cleanup action. The practical interpretation is to remove or suppress that address before the campaign, then retain the result as the reason for suppression. Email Hippo describes a hard bounce as a permanent failure. Its examples include a nonexistent address or domain, and a receiving mail server configured to reject incoming email. Those examples explain why a confirmed bad result should not remain in an active campaign segment. Do not assume every failed delivery is a list-quality failure. If a sender receives a real bounce message, compare its exact text with the [common email bounce messages guide](/learning/bounce-back-email) and inspect the sending path. ### Risky, unknown, or unverifiable Risky, unknown, and unverifiable outcomes need a separate send-policy decision. They are not confirmed deliverable, but they are also not the same as a confirmed bad address. This interpretation is an operational inference from the category systems described by Email Hippo and Verifalia. A cautious policy can hold these addresses out of a high-volume campaign, request an updated address through an approved channel, or send only where your organization accepts the risk. The best choice depends on consent, campaign importance, and the meaning documented by the specific checker. ### Catch-all and similar special cases Some verification services identify catch-all behavior. [ZeroBounce lists catch-alls among the address conditions its validation identifies](https://zerobounce.net), and Verifalia lists catch-all-server checks. A catch-all domain can accept mail for many local parts, so domain acceptance does not necessarily establish that a named recipient mailbox is active. Keep this category separate from confirmed deliverable addresses. Do not convert a catch-all result into a promise that a person will receive or read the campaign. ### Hard bounces and soft bounces after sending Email Hippo describes a soft bounce as more likely fixable, with examples such as a full inbox or temporary mail-server issue. That distinction is useful after a real send, but a list verification result does not replace the SMTP evidence from the failed message. A soft bounce may call for a retry policy in the sending platform. A hard bounce may require suppression. Use the provider's documented bounce classification and the real error message before changing either rule. ## How to act on the result Start with the evidence that supports the lowest-risk action: - Suppress confirmed bad or undeliverable addresses from the upcoming campaign. - Keep risky, unknown, unverifiable, and catch-all results in separate segments. Document the policy used for each segment instead of treating them as verified. - Correct obvious formatting problems in the source system only when the intended address is known from reliable evidence. Do not guess a recipient's address. - For a real hard or soft bounce, inspect the exact SMTP or provider error before deciding whether to suppress, retry, or escalate. - If cleaned-list campaigns still fail, investigate sender authentication, domain configuration, and delivery-path evidence. A public list check cannot diagnose all of those conditions. The result map below is an operational decision aid, not a universal provider rule. ![Decision flow for email list bounce checker results](/images/editorial/email-list-bounce-checker/email-list-bounce-checker-decision-flow.webp "1200x829") *Source: Palisade.* ## How to retest Run the same list through the same checker again before a material campaign, especially when the list has aged, been imported, or collected over a long period. Email Hippo notes that contact validity can change over time, including when someone leaves a job and an inbox closes. Compare the new result with the prior one by address and status. Confirmed bad addresses should remain suppressed unless reliable new evidence supports an update. Review any address whose category changed, rather than assuming the newest label explains why it changed. After the list check, validate the production sending path separately: - Check that the sending domain resolves as expected through authoritative DNS and a public resolver. - Confirm the sending provider's current authentication or verification status. - Send a real message through the exact production path and inspect its delivered headers. - Review DMARC aggregate-report data once it accumulates. Each layer answers a different question. A positive list result does not prove that a message has been signed, aligned, accepted, or placed in the inbox. ## Check sender configuration after list cleanup Once confirmed bad addresses are suppressed, use the [Email Security Score tool](/tools/email-security-score) to inspect public sender-domain security and delivery-related configuration. This follows list cleanup because recipient quality and sender configuration are separate causes of campaign problems. [Check your sender domain's security score](/tools/email-security-score) A public domain check does not verify an email list, inspect a production message, monitor future delivery, or guarantee inbox placement. For ongoing DMARC work, Palisade analyzes aggregate-report data, identifies sending sources and authentication or alignment issues, and proposes the next policy step for human review. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=email_deliverability&utm_content=email-list-bounce-checker). ## Sources and further reading - [Email Hippo email verification tool](https://tools.emailhippo.com) - [Verifalia email verification](https://verifalia.com) - [ZeroBounce email validation](https://zerobounce.net) - [Palisade Email Security Score tool](/tools/email-security-score) ## Frequently asked questions ### What is email verification? Email verification is a process that evaluates whether an address appears usable without sending an email to it. Email Hippo describes checks that range from address syntax to mailbox-related verification signals. ### How does an email list bounce checker work? An email list bounce checker can evaluate address formatting, the recipient domain's MX records, and other provider-specific signals. Email Hippo says its process also makes a non-delivering connection to the receiving mailbox and checks disposable providers and bounce history. ### Can an email list checker identify uncertain results? Yes, most checkers label the results they could not settle. Verifalia uses Risky and Unknown, and Email Hippo uses Unverifiable. Keep those addresses in their own segment, because they are neither confirmed deliverable nor confirmed bad, and they need a send-policy decision rather than automatic deletion. ### How often should I check an email list? Recheck the list before any campaign that matters, and especially when it has aged, been imported, or been collected over a long period. No verification vendor publishes a fixed interval, because list decay depends on how the addresses were gathered. Email Hippo notes that contact validity changes over time, since a valid work inbox closes when someone leaves the organization. ### What is the difference between a hard bounce and a soft bounce? A hard bounce is a permanent failure, such as an address or domain that does not exist. A soft bounce is a temporary or fixable one, such as a full inbox or a mail server having a bad day. Suppress hard bounces before the next campaign and retry soft bounces later. ### Does a clean email list guarantee inbox placement? No, a clean list does not guarantee inbox placement, because list checking only evaluates the recipient addresses. Placement also depends on your sending path, authentication, message content, sender reputation, and each recipient provider's own filtering decision. Clean lists remove one common cause of trouble rather than all of them. --- # Email reverse DNS best practices Canonical: https://www.palisade.email/learning/email-reverse-dns-best-practices > Email reverse DNS best practices: set a PTR for every sending IP, confirm forward DNS, match EHLO, and recheck after IP changes for production senders. Email reverse DNS best practices are straightforward: publish a PTR record for every IP address that sends mail, make its hostname resolve back to that same IP address, use a consistent SMTP EHLO name, and repeat the check whenever the sending IP changes. Google requires valid forward and reverse DNS for senders. Reverse DNS is still a hygiene signal, not an email-authentication control. ## Audience This guidance is for teams that operate production email infrastructure, including internal IT teams, marketing teams, and service providers managing outbound mail for multiple domains. ## Quick takeaways - Every IPv4 or IPv6 address that sends production email needs its own valid PTR record. - A PTR record should return a hostname whose A or AAAA record resolves back to the sending IP. - The hostname in the PTR record does not have to be your brand domain, but the forward and reverse DNS relationship must be consistent. - The SMTP EHLO name should match the hostname used for the sending IP. - Recheck reverse DNS after an IP migration, a new outbound relay, or a provider change. - Use SPF, DKIM, and DMARC for email authentication. Reverse DNS does not authenticate a sender. ## What good email reverse DNS looks like Reverse DNS maps an IP address to a hostname through the `in-addr.arpa` tree for IPv4 addresses. [RFC 1035's inverse query guidance](https://www.rfc-editor.org/rfc/rfc1035#section-3.5) explains that reverse zones are delegated by network address, which is why the organization that controls the IP allocation usually controls the PTR record. For an email sender, the operational target is forward-confirmed reverse DNS: - The sending IP has a PTR record. - The PTR record returns one hostname. - That hostname has an A record for an IPv4 sender or an AAAA record for an IPv6 sender. - The A or AAAA record returns the same sending IP. - The SMTP server introduces itself with an EHLO name that is consistent with that hostname. [Google's Email sender guidelines](https://support.google.com/a/answer/81126) tell all senders to ensure sending domains or IPs have valid forward and reverse DNS records, also called PTR records. Google specifies that a PTR record must resolve to a hostname, and that hostname's A or AAAA record must resolve back to the same IP address. This does not mean the PTR hostname must be `mail.yourdomain.com`. A provider-owned hostname can meet the requirement if the forward and reverse lookup confirm each other. The practical question is whether the published DNS data describes the same sending IP in both directions. ![Decision flow for checking whether a sending IP has forward-confirmed reverse DNS](/images/editorial/email-reverse-dns-best-practices/email-reverse-dns-best-practices-rdns-flow.webp "1200x829") *Source: Palisade.* ## Give every sending IP a PTR record A sending domain can use more than one IP address. Each outbound IP needs its own reverse-DNS check. An IPv4 PTR record does not cover a separate IPv6 sending address. IPv6 reverse DNS uses the `IP6.ARPA` domain and a nibble-reversed representation of the address, as defined in [RFC 3596 section 2.5](https://www.rfc-editor.org/rfc/rfc3596#section-2.5). If your mail platform sends over IPv6, ask the IP owner to publish and verify the IPv6 PTR record as well. The records below are illustrative only. Do not publish these values. Your IP provider, cloud host, or email platform must generate or accept the real PTR hostname for its allocated IP space. ```text IPv4 sending IP: 192.0.2.25 PTR result: mailout.yourdomain.com Forward A result for mailout.yourdomain.com: 192.0.2.25 IPv6 sending IP: 2001:db8:1234::25 PTR result: mailout6.yourdomain.com Forward AAAA result for mailout6.yourdomain.com: 2001:db8:1234::25 ``` Microsoft's [Remote Connectivity Analyzer guidance for a missing PTR record](https://learn.microsoft.com/en-us/connectivity-analyzer/ip-address-does-not-have-ptr-record-dns) says that reverse zones are typically maintained by an ISP. The same ownership model applies when a cloud provider, dedicated host, or email service controls the sending IP range. If you do not control the reverse zone, do not attempt to add a PTR record in your domain's normal DNS zone. Request the PTR from the party that owns the IP address. For the DNS record anatomy, see [what a PTR record is](/learning/email-reverse-dns-lookup). ## Keep the PTR, forward DNS, and EHLO name consistent Forward confirmation is more useful than checking whether a PTR record merely exists. A PTR can return a hostname that no longer has a corresponding A or AAAA record, or it can point to a hostname that resolves to a different IP after an infrastructure change. Use this check sequence: ### 1. Identify the actual outbound IP Start with the IP address used by the system that delivers your production mail. A DNS record for a web server or inbound MX host does not prove that the outbound mail relay uses that address. If you are investigating a specific message, inspect the delivered message headers and isolate the sending infrastructure before changing DNS. The [email reverse DNS check guide](/learning/email-reverse-dns-check) covers the lookup and interpretation task in more detail. ### 2. Look up the PTR result Use the [Palisade IP Reputation Checker](/tools/ip-reputation) with the sending IP to inspect the PTR hostname returned for that address. This is a point-in-time public lookup. It has a 3,500 ms timeout that can return `null`, and it does not confirm the forward DNS result. A null result can mean the check timed out or did not receive a PTR answer. Treat it as a prompt to query the authoritative owner or rerun the lookup. Do not treat it as proof that a receiver rejected mail. ### 3. Check the forward A or AAAA record Take the hostname returned by the PTR lookup and query its matching address record. Use the [DNS Lookup tool](/tools/dns-lookup) for this forward half of the check. For example, if `192.0.2.25` returns `mailout.yourdomain.com`, the A record for `mailout.yourdomain.com` should return `192.0.2.25`. For an IPv6 sender, query the hostname's AAAA record and compare it with the IPv6 sending address. > Do not publish a PTR hostname that resolves to a different IP after a migration. That mismatch can leave a valid-looking reverse record attached to the wrong sending path. ### 4. Compare the SMTP EHLO name The SMTP server's EHLO name should be consistent with the hostname published in reverse DNS. This is an operational practice, not a rule that lets a receiver reject mail solely because the names differ. [RFC 5321 section 4.1.4](https://www.rfc-editor.org/rfc/rfc5321#section-4.1.4) states that a server that receives an EHLO argument that does not match the client's IP address "MUST NOT" refuse the connection for that reason alone. That standards limit matters. A mismatch can indicate a configuration issue, but it does not document the cause of a particular rejection. If you have a concrete banner mismatch, use the narrower [reverse DNS does not match SMTP banner guide](/learning/reverse-dns-does-not-match-smtp-banner) rather than assuming reverse DNS alone explains the result. ## Recheck reverse DNS after every sending-path change No cited standard sets a mandatory recheck interval. The sound operational rule is to recheck after any change that can alter the outbound IP or hostname: - Moving an application to a new hosting provider - Enabling a new transactional-email relay - Changing a cloud egress IP - Adding IPv6 delivery - Moving an SMTP service to a new host - Replacing an email platform's dedicated IP assignment The PTR record belongs to the IP address, not to the sending domain. A domain can retain correct SPF, DKIM, and DMARC records while its new outbound IP has no PTR record or an old reverse mapping. For teams that operate several domains or manage client portfolios, keep a small change record with the sender, IP, PTR hostname, forward result, EHLO name, and the date checked. That record makes an IP migration easier to review without treating a one-time DNS lookup as continuous monitoring. ## Do not use reverse DNS as authentication Reverse DNS can identify a hostname associated with an IP address. It does not prove that a message is authorized to use a visible From domain. [RFC 8601 section 3](https://www.rfc-editor.org/rfc/rfc8601#section-3) describes the `iprev` method for reporting an IP-address reverse check in `Authentication-Results`. The RFC also notes that the referenced guidance recommends avoiding this test as an authentication or security mechanism, and says that including `iprev` is not an endorsement. Use these controls for sender authentication: - SPF evaluates whether the sending IP is authorized for the envelope sender domain. - DKIM verifies a cryptographic signature associated with a signing domain. - DMARC evaluates alignment between the visible From domain and SPF or DKIM. A correct PTR record supports basic sending hygiene. It does not prove that SPF passes, that DKIM signs the message, that DMARC aligns, or that a mailbox provider will place a future message in the inbox. ## Check the reverse DNS behind your sending IP If you have the sending IP address, start by checking its current PTR result with the [Palisade IP Reputation Checker](/tools/ip-reputation). Then use a forward DNS lookup to confirm that the returned hostname resolves back to the same address. This check can show the public DNS state for one IP at one moment. It cannot prove the production system used that IP for a particular message, confirm the SMTP EHLO value, monitor later infrastructure changes, or predict a receiver's placement decision. For an ongoing DMARC workflow, [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=infrastructure&utm_content=email-reverse-dns-best-practices). Palisade autonomously analyzes DMARC aggregate-report data, identifies sending sources and authentication or alignment issues, and creates prioritized remediation tickets. It does not change your DNS or DMARC policy without human review, and it cannot control a mailbox provider's private filtering decision. ## Sources and further reading - [Google Email sender guidelines](https://support.google.com/a/answer/81126) - [RFC 1035: Domain names, implementation and specification](https://www.rfc-editor.org/rfc/rfc1035) - [RFC 3596: DNS extensions to support IP version 6](https://www.rfc-editor.org/rfc/rfc3596) - [RFC 5321: Simple Mail Transfer Protocol](https://www.rfc-editor.org/rfc/rfc5321) - [RFC 8601: Authentication-Results header field](https://www.rfc-editor.org/rfc/rfc8601) - [Microsoft Remote Connectivity Analyzer: IP address does not have PTR record](https://learn.microsoft.com/en-us/connectivity-analyzer/ip-address-does-not-have-ptr-record-dns) ## Frequently asked questions ### Is reverse DNS required for sending email? Google's sender guidelines require valid forward and reverse DNS records for all senders. SMTP itself does not make reverse DNS universally mandatory, and RFC 5321 says an EHLO and IP mismatch alone MUST NOT cause a server to reject a connection. Receiver requirements and local filtering policies can still make correct reverse DNS operationally necessary. ### Should the PTR name match my sending domain? No. The PTR hostname does not need to use your brand domain. It must resolve forward through an A or AAAA record to the same sending IP address. Keep the SMTP EHLO name consistent with that hostname so the published identity and server introduction do not conflict. ### Who sets up a PTR record? The organization that controls the IP address or its reverse DNS zone sets the PTR record. Microsoft notes that ISPs typically maintain reverse zones. For a cloud IP or email-platform IP, request the record from that provider rather than adding it to your ordinary domain DNS zone. ### Do I need reverse DNS for IPv6 email? Yes, if the system sends mail from IPv6. IPv6 reverse DNS uses the separate `IP6.ARPA` tree defined by RFC 3596. An IPv4 PTR record does not cover an IPv6 address, and the returned hostname should resolve through an AAAA record to the same IPv6 address. ### How often should I recheck reverse DNS? Recheck after any change to the outbound IP address, mail relay, hosting provider, or IPv6 configuration. No primary source sets a fixed review interval. This is operational guidance because the PTR record follows the IP allocation, so a migration can change reverse DNS even when the sending domain stays the same. ### Is reverse DNS an email-authentication method? No. Reverse DNS identifies a hostname associated with an IP address. RFC 8601 describes `iprev` reporting but does not endorse it as an authentication or security method. Use SPF, DKIM, and DMARC to authenticate domain use and evaluate alignment. --- # Email reverse DNS check Canonical: https://www.palisade.email/learning/email-reverse-dns-check > Email reverse DNS check: look up an email server's PTR record, confirm its forward DNS, and interpret iprev results for Gmail compliance today. An email reverse DNS check starts with the public IP address that sends SMTP mail. Look up that IP's PTR record, then confirm the returned hostname resolves back to the same IP address. Google requires valid forward and reverse DNS for sending domains or IPs, including a matching PTR hostname, for all senders under its [Email sender guidelines](https://support.google.com/a/answer/81126). ## Quick takeaways - A PTR lookup shows the hostname associated with a sending IP address. - A PTR result alone is not forward-confirmed reverse DNS. - RFC 8601 calls the two-way reverse-DNS check `iprev`. - A PTR query can return more than one hostname. - Google's sender guidelines require the sending IP to match the IP address of the hostname in its PTR record. - A missing PTR or mismatch is a signal receivers may evaluate, not a universal SMTP rejection rule. ## Who is affected? This check applies to anyone responsible for an internet-facing SMTP server or an email platform's dedicated sending IP. Start with the exact public IP that establishes the SMTP connection, not a domain shown in an email address or message body. Google's [sender guidelines](https://support.google.com/a/answer/81126) apply the forward-and-reverse-DNS requirement to all senders. They state that sending domains or IPs must have valid forward and reverse DNS records, also called PTR records, and that the sending IP address must match the IP address of the PTR hostname. The person who owns the IP address usually controls the repair path. If an ISP, cloud provider, or email service provider owns the address range, it may control the reverse DNS zone. Microsoft's guidance notes that [reverse zones are typically maintained by the ISP](https://learn.microsoft.com/en-us/connectivity-analyzer/ip-address-does-not-have-ptr-record-dns). A reverse DNS check does not establish DMARC alignment, DKIM signing, SPF authorization, message content quality, or a receiver's final spam decision. It is one infrastructure check within [email and DNS infrastructure](/learning/infrastructure). ## What are the requirements? ### The sending IP has a PTR record A reverse DNS lookup asks for the hostname associated with an IP address. The DNS record used for that answer is a PTR record. Run the initial lookup with the [IP Reputation Checker](/tools/ip-reputation). Enter the sending IP address. The result is a PTR response, which may be a hostname, more than one hostname, or no result. ```text Illustrative only. Replace these values with your own sending IP and hostname. Sending IP: 203.0.113.25 PTR result: smtp1.yourdomain.com ``` > Do not publish a provider-generated hostname, tenant identifier, or customer IP address as an example. Use values from the system that owns the sending IP. RFC 8601 states that a PTR response could contain multiple names. Treat each returned hostname as a candidate for the forward-confirmation check. Do not assume the first name is the only relevant answer. ![Checklist showing a PTR lookup, forward A or AAAA lookup, IP comparison, and delivered-message header review](/images/editorial/email-reverse-dns-check/email-reverse-dns-check-reverse-dns-checklist.webp "1200x582") *Source: Palisade.* ### The PTR hostname resolves back to the sending IP The reverse lookup is only the first half of the test. RFC 8601 section 3 defines the `iprev` method: query PTR for the client IP, query A and AAAA records for every returned name, then pass only if the original client IP appears in the resulting addresses. ```text Illustrative only. PTR query: 203.0.113.25 -> smtp1.yourdomain.com Forward query: smtp1.yourdomain.com -> 203.0.113.25 iprev result: pass ``` Use [DNS Lookup](/tools/dns-lookup) only for the forward portion of this test. Enter the hostname returned by the PTR lookup and request its A record for IPv4 or AAAA record for IPv6. DNS Lookup does not perform PTR queries from an IP address, so it cannot replace the initial IP Reputation Checker lookup. The [RFC 8601 `iprev` definition](https://www.rfc-editor.org/rfc/rfc8601.txt) is a method for reporting an authentication result. It does not require every receiver to perform the test for every message. ### A failed EHLO name check alone cannot cause SMTP refusal SMTP has a related, narrower rule for the name presented in `EHLO`. RFC 5321 says: ```text An SMTP server MAY verify that the domain name argument in the EHLO command actually corresponds to the IP address of the client. However, if the verification fails, the server MUST NOT refuse to accept a message on that basis. ``` This is from [RFC 5321 section 4.1.4](https://www.rfc-editor.org/rfc/rfc5321.txt). Keep that scope precise. A receiver cannot reject mail solely because the EHLO name check fails under this RFC rule. A missing PTR record or failed forward confirmation can still be one anti-spam signal among other receiver checks. For a mismatch specifically involving the SMTP banner, use [Reverse DNS does not match SMTP banner](/learning/reverse-dns-does-not-match-smtp-banner). It covers that separate operational problem. ## When does the requirement take effect? RFC 8601 is the current IETF standard for the Authentication-Results header field and `iprev` result method. It was published in May 2019 and obsoletes RFC 7601. RFC 8601 defines how a receiver can report `iprev`; it does not establish a universal date by which all senders must configure PTR records. Google's sender-specific requirement took effect on February 1, 2024. Its current [Email sender guidelines](https://support.google.com/a/answer/81126) say all senders need valid forward and reverse DNS records for sending domains or IPs. Google describes the required relationship this way: the public IP of a sending SMTP server must have a PTR record that resolves to a hostname, and that hostname must have an A or AAAA record resolving to the same public IP. Provider rules can change independently of RFC publication dates. Check the provider's current sender guidance before treating a date or enforcement consequence as permanent. ## How do I implement the requirement? ### 1. Identify the production sending IP Find the public IP used by the SMTP connection for the mail stream you are checking. A shared email platform may use multiple sending IPs, and a separate transactional service may use a different address than a marketing sender. Use a delivered message header, SMTP logs, or your provider's documented sending-IP details. A domain's website IP is not necessarily its email-sending IP. ### 2. Look up the PTR result Enter one sending IP at a time in the [IP Reputation Checker](/tools/ip-reputation). Record every hostname returned. If the tool returns `null`, retry before concluding the IP has no PTR record. A lookup can time out, and an empty result does not distinguish a genuine missing record from a transient resolution failure. For PTR record anatomy and ownership context, see [What is a PTR record](/learning/what-is-a-ptr-record). ### 3. Check forward DNS for every returned name For each PTR hostname, look up its A record for an IPv4 sending IP or AAAA record for an IPv6 sending IP. Compare the results with the exact original sending IP. A matching forward record completes the DNS-side `iprev` check. If none of the returned names resolve back to the sending IP, treat the result as failed forward-confirmed reverse DNS. ### 4. Correct the record through the IP owner If the PTR is absent or the returned hostname does not resolve back to the sending IP, request the change from the organization that controls the reverse DNS zone. That is often the ISP, hosting provider, cloud provider, or email service provider. Ask for the intended hostname and its matching forward A or AAAA record to be checked together. Changing only the forward record does not create a PTR record. ## How do I validate compliance? Validate the DNS relationship at two levels. First, rerun the PTR lookup on the sending IP. Then query A or AAAA for every hostname returned and verify that the original IP appears in the answer set. The IP Reputation Checker returns the PTR result only. It does not perform the forward lookup required for RFC 8601 `iprev`, and a single lookup does not prove continuous DNS state. Next, inspect a real delivered message from the same production path. RFC 8601 defines `iprev` results in `Authentication-Results` as `pass`, `fail`, `temperror`, or `permerror`. A receiver that evaluates it may expose a result shaped like this: ```text Authentication-Results: receiver.example; iprev=pass policy.iprev=smtp1.yourdomain.com ``` A receiver might omit `iprev`, perform a different evaluation, or apply additional unpublished anti-spam signals. A passing PTR and forward-DNS check does not guarantee inbox placement or prove that every future message will authenticate. ## Check the PTR record behind your sending IP Use the [IP Reputation Checker](/tools/ip-reputation) to inspect the PTR name returned for the public IP that sends your mail. Then use DNS Lookup to compare that name's A or AAAA result with the original IP. The checker reports a PTR lookup, not forward-confirmed reverse DNS, receiver enforcement, or future message placement. For ongoing monitoring and remediation, [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=email_deliverability&utm_content=email-reverse-dns-check). ## Sources and further reading - [RFC 8601: Authentication-Results header field](https://www.rfc-editor.org/rfc/rfc8601.txt) - [RFC 5321: Simple Mail Transfer Protocol](https://www.rfc-editor.org/rfc/rfc5321.txt) - [Google Email sender guidelines](https://support.google.com/a/answer/81126) - [Microsoft Remote Connectivity Analyzer: IP address does not have a PTR record in DNS](https://learn.microsoft.com/en-us/connectivity-analyzer/ip-address-does-not-have-ptr-record-dns) ## Frequently asked questions ### How do I check the reverse DNS of an email server's IP? Enter the public sending IP in the [IP Reputation Checker](/tools/ip-reputation) to retrieve its PTR result. Then look up the returned hostname's A or AAAA record and compare it with the original IP. That second lookup completes the RFC 8601 `iprev` method. ### What does it mean if a reverse DNS lookup returns nothing? An empty result means no PTR name came back, which can be a missing record or simply a lookup that failed. Retry it first, because DNS resolution can time out. If repeated lookups still return nothing, contact the organization that controls the IP range, since reverse zones are typically maintained by the ISP or provider. ### Is a PTR result the same as forward-confirmed reverse DNS? No, a PTR result is only the first half of the test, because it maps an IP address to one or more names. RFC 8601 adds a second step: query those names for A or AAAA records and confirm the original IP appears among the addresses returned. ### What should an email server's reverse DNS name resolve to? The PTR hostname should resolve through an A record for IPv4 or an AAAA record for IPv6 to the same public IP that sends the SMTP mail. This is the forward-and-reverse-DNS relationship described in Google's sender guidelines. ### Can a receiver reject mail because reverse DNS fails? A receiver can treat failed reverse DNS as one anti-spam signal, but RFC 5321 says it must not refuse a message solely because the EHLO name does not correspond to the client IP. Missing or invalid reverse DNS still counts against a sender in that broader evaluation, so repair an absent or mismatched PTR record rather than relying on the rule. --- # Email reverse DNS lookup: check and interpret a PTR record Canonical: https://www.palisade.email/learning/email-reverse-dns-lookup > Email reverse DNS lookup: check an SMTP sending IP's PTR record, confirm forward DNS, interpret results, and retest the mail path for reliable mail. An email reverse DNS lookup checks whether a sending IP address has a PTR record that maps it to a hostname. Start with the actual SMTP sending IP, inspect its PTR result, then resolve that hostname forward to confirm it includes the same IP. A PTR result is useful sender-infrastructure evidence, but it does not prove message authentication, mailbox-provider acceptance, or inbox placement. ## Quick takeaways - Reverse DNS maps an IP address to a hostname through a PTR record. - The [Palisade IP Reputation Checker](/tools/ip-reputation) accepts an IPv4 or IPv6 address and displays its reverse DNS result. - A hostname returned by a PTR lookup is not forward-confirmed reverse DNS until its A or AAAA records resolve back to the original IP. - Google requires valid forward and reverse DNS records for sending domains or IPs, with the sending IP matching the PTR hostname's IP. - A missing PTR result in the checker can also mean the lookup timed out, so confirm it with an independent DNS query. - Reverse DNS is one infrastructure check. It does not replace SPF, DKIM, DMARC, blocklist, or delivered-message evidence. ## What this tool checks The [Palisade IP Reputation Checker](/tools/ip-reputation) takes an IP address, runs a reverse lookup, and shows the result in its **IP information** card under **Reverse DNS (PTR)**. When a PTR hostname is available, the tool lists it. When it has no returned hostname, the row reads: **“No PTR record found. Mailbox providers expect sending IPs to have reverse DNS.”** A PTR record is a DNS record that points to a location elsewhere in the DNS namespace, as defined in [RFC 1035's PTR record specification](https://www.rfc-editor.org/rfc/rfc1035.html). For IPv4, reverse lookups use the special `in-addr.arpa` namespace with the address octets reversed. The result is a public lookup of the IP address. It cannot prove that the IP is the one your production application used, that the SMTP server's HELO or EHLO name matches the PTR hostname, that a hostname resolves back to the IP, or that a recipient accepted a particular message. For those questions, use a delivered message's headers and the sending platform's configuration. [Email transport security](/learning/infrastructure) depends on several controls, not reverse DNS alone. ## How to run the check ### 1. Identify the actual SMTP sending IP Get the source IP from the sending service, mail gateway, or a delivered test message. Do not use the visible From-domain address as a substitute. A domain can send through several outbound IPs, and each IP can have a separate PTR record. If you have a received message, [analyze its email headers](/learning/analyze-email-headers-online) to identify the relevant relay path before testing an address. ### 2. Submit the IP address to the checker Open the [IP Reputation Checker](/tools/ip-reputation), enter the IPv4 or IPv6 address, and inspect the **Reverse DNS (PTR)** row in **IP information**. The checker rejects text that is not a valid IP address. Verify that you copied the numerical source address rather than a hostname, URL, domain, or an address with a port number attached. ### 3. Repeat the public lookup independently Use a DNS query against the same IP address. This checks the PTR answer independently and gives you a repeatable record of the test. ```bash dig +short -x 203.0.113.25 ``` Use an IP you control when investigating production mail. `203.0.113.25` is an illustrative documentation address, not a sending server to configure or publish. ![Decision map for checking a sending IP's PTR record and confirming the returned hostname](/images/editorial/email-reverse-dns-lookup/email-reverse-dns-lookup-reverse-dns-flow.webp "1200x829") *Source: Palisade.* ## How to interpret the results ### A PTR hostname is displayed A displayed hostname means the reverse lookup returned one or more PTR names for the submitted IP. Treat this as the first part of the check, not the final result. RFC 8601 calls the full forward-confirmed check `iprev`. The receiver first performs a PTR query for the client IP, then resolves the returned names through A and AAAA queries. The check passes only when the original IP appears in those forward answers. [RFC 8601 defines the `iprev` method and its pass condition](https://www.rfc-editor.org/rfc/rfc8601.html). Query the returned hostname directly: ```bash dig +short A mail.yourdomain.com dig +short AAAA mail.yourdomain.com ``` Replace `mail.yourdomain.com` with the hostname returned for your sending IP. If neither answer includes the original sending IP, the PTR result alone does not meet the RFC 8601 forward-confirmation condition. Google's [email sender guidelines](https://support.google.com/a/answer/81126) state that sending domains or IPs need valid forward and reverse DNS records, and that the sending IP must match the IP address of the hostname specified in the PTR record. Microsoft likewise says the source email server should have a reverse DNS entry and that the HELO or EHLO command should match the sending IP's reverse DNS, in its [outbound mail best-practices guidance](https://learn.microsoft.com/en-us/defender-office-365/anti-spam-protection-faq). ### “No PTR record found” is displayed This state means the tool did not receive a PTR hostname for the lookup. It can indicate that no PTR data is published, but it can also occur when the reverse query does not complete in time. Retest with the same IP and run `dig +short -x` before concluding that the PTR record is absent. If both checks return no hostname, the owner of the IP address must normally publish or correct the PTR record. That is often the cloud provider, hosting provider, ISP, or email service that controls the IP allocation. Do not add a PTR record to your domain's normal DNS zone unless that provider specifically delegates control. PTR records for sending IP ranges are usually managed at the network provider level. RFC 8601 defines `permerror` for `iprev` when no PTR data is published. A timeout or temporary resolver problem is different from an absent record, which is why a single null result needs confirmation. ### The checker rejects the input The IP Reputation Checker returns an invalid-input error when the value is not IPv4 or IPv6. Recheck the value against the message relay information or the sending platform's outbound-IP list. A hostname such as `smtp.yourdomain.com` is not valid input for this check. Use its resolved IP address instead. For forward DNS records such as A, AAAA, MX, TXT, and CNAME, use the [Palisade DNS Lookup tool](/tools/dns-lookup). That tool checks forward record types, not PTR records. ## How to act on the result For a PTR hostname that resolves back to the sending IP, compare the SMTP server's HELO or EHLO name with that hostname. Microsoft documents that these names should match. Then send a test message through the same application and relay path, and inspect the received headers for the actual source path and authentication outcomes. For an absent PTR result confirmed by repeated DNS queries, identify who owns the outbound IP. Open that provider's current reverse-DNS documentation or support process, then request or configure the PTR hostname there. Keep the forward A or AAAA record under your DNS control aligned with the chosen hostname. Changing an unrelated web-domain record will not repair reverse DNS for the mail server. > Do not change a PTR hostname before checking every service that sends through the IP. A shared relay, gateway, or provider-managed address may have provider-specific naming requirements. For a PTR hostname that does not resolve back to the IP, correct the forward A or AAAA record, the provider-managed PTR record, or both according to the party that controls each DNS zone. Retest after DNS propagation, then validate a fresh message. A public reverse-DNS lookup cannot explain why one recipient rejected a message or establish that future mail will reach the inbox. If the IP also appears on a blocklist, keep that as a separate diagnosis. A working PTR does not delist an address. Use the [email blocklist guide](/learning/blocklist-email) to separate reputation evidence from DNS identity evidence, then [check whether the domain itself is listed](/tools/domain-reputation). ## How to retest Run the same IP through the Palisade IP Reputation Checker after the authoritative PTR answer changes. Repeat the `dig +short -x` query and resolve every returned PTR hostname through A and AAAA queries. Record the IP, hostname, answers, and test time together. Then send a new message through the exact production sending path. Confirm the message used the expected outbound IP, review its HELO or EHLO identity where available, and inspect its authentication results. Once sufficient mail has flowed, review DMARC aggregate-report data to see which sources authenticate and align. Reverse DNS supports sender infrastructure, but DMARC reports reveal a different layer of evidence. ## Track reverse-DNS gaps across active sending sources A successful lookup for one IP does not show whether another production sender has a missing PTR record, an alignment issue, or a new source that appeared later. Palisade is agentic DMARC software that analyzes DMARC aggregate-report data, identifies sending sources and authentication or alignment issues, and creates prioritized remediation tickets. It proposes the next policy step for human review. It does not change a PTR record, control a receiver's private decision, or guarantee delivery. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=infrastructure&utm_content=email-reverse-dns-lookup) ## Sources and further reading - [RFC 1035: Domain names, implementation and specification](https://www.rfc-editor.org/rfc/rfc1035.html) - [RFC 8601: Message Authentication Status](https://www.rfc-editor.org/rfc/rfc8601.html) - [Google email sender guidelines](https://support.google.com/a/answer/81126) - [Microsoft anti-spam protection FAQ](https://learn.microsoft.com/en-us/defender-office-365/anti-spam-protection-faq) - [Palisade IP Reputation Checker](/tools/ip-reputation) ## Frequently asked questions ### What is an email reverse DNS lookup? An email reverse DNS lookup queries a sending IP address for its PTR record. The PTR result identifies the hostname associated with that IP, if one is published. For a complete `iprev` check, resolve that returned hostname forward and confirm it includes the original IP. ### Does a PTR record prove that email will be delivered? No, a PTR record does not prove delivery, because it only describes the sending IP's infrastructure. It says nothing about SPF, DKIM, or DMARC results, the receiver's view of your reputation, or where the message lands. A missing PTR can cause rejections, but a present one is only the first hurdle cleared. ### Can I create a PTR record in my normal domain DNS zone? You cannot, unless the IP provider has delegated the reverse-DNS zone to you. PTR records live in the reverse zone for the IP range, which the provider that owns the range normally controls, so adding one to your forward domain zone does nothing. Request the change through that provider's documented process instead. ### Why does reverse DNS show a hostname that does not match my From domain? A reverse DNS hostname identifies the sending server or IP, while the From domain identifies the visible message author. They can differ. The important checks are whether the PTR hostname resolves back to the sending IP and whether the SMTP HELO or EHLO identity follows the sending provider's requirements. ### What does “No PTR record found” mean? "No PTR record found" means the reverse lookup came back with no hostname for that IP. Either the IP has no published PTR record, or the lookup itself failed or timed out. Repeat the check and confirm it with a direct `dig -x` query before you ask the IP provider for a repair. --- # Email security testing tools: run, interpret, repair, retest Canonical: https://www.palisade.email/learning/email-security-testing-tools > Email security testing tools help safely test gateway handling of safe threats, interpret blocking or disarming results, repair gaps, and retest. Email security testing tools help you check how an inbound security product handles safe simulations of threats such as spoofed senders, malicious links, attachments, QR-code phishing, and business-email-compromise attempts. Run a test against the recipient path you need to assess, inspect whether each sample was blocked, disarmed, or disinfected, repair the control gap, then repeat the same test. A received message alone does not prove the gateway failed. ## Quick takeaways - Gateway testing and staging-email testing answer different questions. - A safe threat test can assess whether an email-security product blocks, disarms, or disinfects a sample. - A test message that reaches an inbox may still have been disarmed. - Test the same recipient route again after changing a gateway policy or control. - A public domain check cannot prove how one inbound gateway handled a particular message. - Use the wider [email-threat learning hub](/learning/threats) to investigate the threat type behind a failed test. ## What this tool checks Email security testing starts by matching the tool to the evidence you have. A gateway threat tester sends safe, disarmed messages that behave like common threat scenarios. The [Email Security Tester](https://emailsecuritytester.com) describes examples including spoofed envelope senders, EICAR virus attachments, malware URI links, QR-code phishing, business-email-compromise spoofing, and macro-formula Excel content. Its stated expectation is that the recipient security product blocks, disarms, or disinfects the samples. That is different from a development email sandbox. [Mailtrap Email Sandbox](https://mailtrap.io) describes its service as a place for developers and QA teams to safely test staging emails. A sandbox can help test an application's outgoing messages without delivering them to real recipients. It does not, by itself, test whether a production inbound gateway stopped a simulated phishing message. Use [Palisade's Email Security Score](/tools/email-security-score) as a separate public-domain check when you want to inspect the result it currently returns for a domain. It is not evidence of the exact inbound message route, the actions an email-security gateway took on a sample, continuous security state, or a receiver's private decision about one message. ![Decision map for choosing an email security test based on the evidence available](/images/editorial/email-security-testing-tools/email-security-testing-tools-result-map.webp "1200x676") *Source: Palisade.* ## How to run the check ### 1. Define the recipient route to test Choose the exact mailbox and inbound route that matter. Record the recipient address, gateway or security product in front of it, and any routing rules that can affect delivery. A test sent to a different mailbox, tenant, or policy group does not establish how the target route behaves. Do not use a live malicious attachment or phishing URL. Use a service that states its samples are safe test messages. If you already have a real suspicious URL to assess, [check it against threat blocklists](/tools/url-reputation) rather than sending it through the gateway. ### 2. Choose the test type that matches the question Use a gateway threat tester when the question is whether inbound protections handle simulated threats. Use a staging-email sandbox when the question is whether an application builds and sends test emails correctly before production delivery. If you need a domain-level public check in addition to gateway testing, open [Palisade's Email Security Score](/tools/email-security-score). Treat its displayed result as a point-in-time public check. Keep it separate from the test messages and gateway evidence. You can confirm that the public tool page is reachable before starting a domain check: ```bash curl -I https://www.palisade.email/tools/email-security-score ``` This command confirms only that the public page responds. It does not test a domain, inspect a mailbox, or establish the effectiveness of an inbound security gateway. ### 3. Send the safe test to the target mailbox Follow the tester's current instructions and use the target recipient. Keep a record of the date, recipient route, test category, and result for each sample. The Email Security Tester page warns that a message received in the inbox may have been disarmed, so open the message description before classifying it as a failure. The result categories below are an interpretation aid for safe gateway tests. They are not result labels from Palisade's public domain tool. ## How to interpret the results ### The sample was blocked A blocked sample indicates that the tested recipient route prevented that test message from reaching the mailbox. Record which sample was blocked and the policy or product status available to the administrator. This is evidence for that route and test at that time. It does not prove that every threat variation will be blocked, that every mailbox uses the same policy, or that future messages will receive the same treatment. ### The sample reached the mailbox but was disarmed A received sample can still be handled safely. The Email Security Tester specifically instructs readers to check whether a delivered sample was disarmed. For example, a gateway may alter an attachment or link before delivery. Classify the outcome from the message description and the gateway's own event evidence, not from inbox delivery alone. If the message was disarmed, determine whether the changed content matches the intended policy for that test category. ### The sample was disinfected The tester identifies disinfection as another expected handling outcome. Record what the recipient received and confirm the gateway's event or administrative evidence if available. Do not assume that disinfection has the same operational consequence as blocking. The distinction matters when setting policy expectations, incident procedures, and user guidance. ### The sample reached the mailbox without documented safe handling Treat this as a finding that needs investigation, not immediate proof that every protective control is absent. First confirm the recipient route and test category. Then inspect the gateway's logs, quarantine, policy assignment, and any product-specific event details. The test can show an outcome. The gateway's own administration interface is the place to determine why it reached the mailbox and which policy applied. ## How to act on the result Work from the most specific evidence first. - Confirm that the tested mailbox used the intended inbound route. Shared mailboxes, alternate MX routing, forwarding, and different policy groups can change the result. - For a sample that was not blocked, disarmed, or disinfected as expected, inspect the gateway's event record and the policy assigned to that recipient. Do not change unrelated mail-flow rules based on a single result. - Repair the narrow control implicated by the test. A link-handling gap calls for gateway policy investigation. An attachment-handling gap calls for the relevant attachment or malware policy investigation. A spoofing scenario calls for review of the security product's sender and impersonation controls. - Repeat the same safe test after the change. Compare the new result with the original outcome for the same recipient route. - Review broader operating controls through [email security practices for businesses](/learning/what-are-the-top-email-security-tips-for-small-businesses). A passing simulation is useful evidence, but it is one part of an email-security program. > Warning: Do not weaken inbound filtering or bypass a production gateway to make a test produce a cleaner result. Test the policy that protects the mailbox in normal operation. If the issue involves a public domain signal rather than the gateway's handling of a received test message, keep that investigation separate. [Email security](/learning) covers the broader set of controls and operational questions around protecting business email. ## Investigate this with your coding agent Use this when you have a non-sensitive public domain and want a read-only record of the visible public checker result alongside the gateway-test outcome. Prepare only redacted result text and public domain information. ```agent Problem: A safe email-security gateway test reached the target mailbox without a documented block, disarm, or disinfection outcome. Evidence: Public domain name, redacted Palisade Email Security Score result text, test date, redacted recipient route description, and the safe test category. Repository scope: Public DNS and the public Palisade Email Security Score page only. Constraints: Inspect before editing. Do not apply changes until I approve the proposed diff. Do not change DNS, mail flow, gateway policy, or tool configuration. Exclude credentials, private keys, tokens, unredacted headers, and customer data. Requested output: Diagnosis, minimal proposed change, rollback, and unknowns. Verification: Re-run the same public tool path and repeat the same safe gateway test through the same recipient route. Stop if: Credentials, private data, production mutation, or missing evidence is required. ``` ## How to retest Repeat the same safe test category through the same mailbox and gateway route after the relevant policy change. Check the message description and the gateway's own event evidence again. Record whether the new outcome is blocked, disarmed, disinfected, or still unresolved. For a public-domain follow-up, run the same [Email Security Score check](/tools/email-security-score) again and retain the displayed result with its date. A public check does not prove that the production inbound gateway enforced a policy, repaired the original finding, or will handle all future messages the same way. ## Check the public domain result alongside the gateway test After you have documented the gateway outcome, run the domain through Palisade's Email Security Score to inspect the public result currently displayed for that domain. [Check the email security score](/tools/email-security-score) The check does not inspect a specific delivered test message, repair an inbound gateway policy, monitor the recipient route continuously, or guarantee that future messages will be blocked or delivered. ## Sources and further reading - [Email Security Tester](https://emailsecuritytester.com) - [Mailtrap Email Sandbox](https://mailtrap.io) - [Palisade Email Security Score](/tools/email-security-score) - [ImmuniWeb application security testing products](https://immuniweb.com) ## Frequently asked questions ### What is the best email security tool? The best email security tool is the one that matches what you are testing. Use a gateway threat tester when you need to see how inbound protection handles safe simulations of spoofed senders, malicious links, attachments, and QR-code phishing. Use a staging-email sandbox when you need to check the messages your own application sends before they reach real recipients. ### Which tool is best for security testing? Pick the tool by the question you are asking, because these two categories do not overlap. A gateway threat tester answers whether inbound protection blocks, disarms, or disinfects a safe threat sample sent to a real mailbox. A staging-email sandbox answers whether an application builds and sends the right messages during development and QA. ### What are email security tools? Email security tools are products that test or operate the controls protecting a mailbox from email threats. A gateway test sends safe simulations of spoofing, malicious links, attachments, QR-code phishing, and business-email-compromise scenarios to a chosen recipient route. The expected handling is that the security product blocks, disarms, or disinfects each sample. ### Does a test message in my inbox mean my gateway failed? No, delivery alone does not mean the gateway failed, because a gateway can pass a sample through after disarming or disinfecting it. Read the tester's description of that specific message and the gateway's own event log before you record a miss. A genuine failure shows an untouched sample and no protective action in the logs. ### What are SAST and DAST tools? SAST and DAST are application-security tests, not email tests. Static Application Security Testing inspects an application's source code without running it, while Dynamic Application Security Testing probes the running application from the outside. [ImmuniWeb lists the two as separate products](https://immuniweb.com). Neither one tells you how an email gateway handled a message, so keep them apart from the gateway tests on this page. --- # Email server authentication methods explained Canonical: https://www.palisade.email/learning/email-server-authentication-method > Email server authentication methods use SPF, DKIM, and DMARC to verify sending domains, while SMTP AUTH controls client access to mail servers. An email server authentication method usually means domain authentication: SPF identifies hosts authorized to send for a domain, DKIM verifies a signed message, and DMARC evaluates aligned SPF or DKIM results for the visible From domain. This is separate from SMTP AUTH, which authenticates a mail client to its outbound server. The controls work at different points in mail delivery and are normally used together. ## Quick takeaways - SPF publishes the hosts authorized to use a domain in SMTP `HELO` and `MAIL FROM` identities. - DKIM lets a receiver verify that signed parts of a message were not altered after signing. - DMARC evaluates SPF or DKIM results against the message's visible From domain. - SMTP AUTH is a client-to-server login protocol, not a replacement for SPF, DKIM, or DMARC. - RFC 9989 is the current DMARC specification and obsoletes RFC 7489. - A published DNS record does not prove that a production message uses the intended sending path. ## Who is affected? Domain authentication affects organizations that send mail using their own domain, including mail sent through a company mail system, a marketing platform, a support platform, or a transactional application. Receiving systems use the resulting authentication evidence when they process a message. The most useful distinction is between domain authentication and client authentication: - SPF, DKIM, and DMARC help a receiving server assess whether mail is authorized to use a domain. - SMTP AUTH allows a mail client or application to authenticate to its own outbound SMTP server before submitting mail. [SMTP AUTH in RFC 4954](https://www.rfc-editor.org/rfc/rfc4954.txt) defines an SMTP service extension for authentication between a client and server. It does not publish authorization to the public DNS and does not tell an external receiver whether a domain authorized a message. For the domain-authentication layer, [RFC 9989 defines DMARC](https://www.rfc-editor.org/rfc/rfc9989.txt) as a policy and reporting mechanism that consumes authenticated identifiers produced by SPF and DKIM. Read the broader explanation of [what email authentication is and why it matters](/learning/what-is-email-authentication-and-why-does-it-matter) if you need the business and delivery context. ## What are the requirements? ### SPF authorizes SMTP sending hosts [SPF, defined by RFC 7208](https://www.rfc-editor.org/rfc/rfc7208.txt), uses a DNS record to declare which hosts are and are not authorized to use a domain in the SMTP `HELO` and `MAIL FROM` identities. The receiver evaluates the SPF record for the identity used by the message, not automatically the visible From address. An illustrative SPF record shape looks like this: ```text yourdomain.com. IN TXT "v=spf1 ip4:192.0.2.10 -all" ``` > Do not publish this example unchanged. Your SPF record must reflect the actual hosts and services authorized to send mail for your domain. SPF therefore answers the question, "Which MTA email servers are authorized to send email for this domain?" It identifies sending hosts for the SMTP envelope identity. It does not, by itself, prove alignment with the domain a recipient sees in the From header. ### DKIM signs the message and publishes a public key [DKIM, defined by RFC 6376](https://www.rfc-editor.org/rfc/rfc6376.txt), lets a sending system add a cryptographic signature to a message. The receiving system retrieves the associated public key from DNS and verifies the signature. A DKIM public-key record is published below a selector chosen by the sending system: ```text selector1._domainkey.yourdomain.com. IN TXT "v=DKIM1; k=rsa; p=PUBLIC_KEY_MATERIAL" ``` > This is illustrative only. Do not reuse a selector or key from an example. Your sending platform generates the selector and public key values for your account. A valid DKIM result means the receiver could validate the signature using the published key and the signed message data. It does not mean every message from the domain will pass. Each production sending path must be configured to sign mail with the expected domain and selector. ### DMARC evaluates aligned SPF or DKIM evidence [RFC 9989](https://www.rfc-editor.org/rfc/rfc9989.txt) defines DMARC and states that SPF and DKIM produce the Authenticated Identifiers that DMARC evaluates. DMARC uses the visible `From:` domain as its organizing identity. For DMARC to pass, either SPF or DKIM must pass and align with that domain under the applicable alignment rules. A DMARC record is a DNS TXT record at `_dmarc.<domain>`: ```text _dmarc.yourdomain.com. IN TXT "v=DMARC1; p=none" ``` The `p=none` example is a monitoring policy shape. It is not a universal starting point or a safe policy for every domain. Policy changes affect mail handling, so review aggregate-report evidence and all known sending sources before changing enforcement. ![Checklist showing SPF host authorization, DKIM message signing, and DMARC alignment for yourdomain.com](/images/editorial/email-server-authentication-method/email-server-authentication-method-checklist.webp "1200x524") *Source: Palisade.* DMARC is not a third authentication mechanism in the same sense as SPF and DKIM. SPF and DKIM provide authentication results. DMARC applies policy and alignment rules to those results. ### SMTP AUTH controls access to an outbound server SMTP AUTH is relevant when an email client, application, or device needs permission to submit mail through an SMTP server. RFC 4954 specifies the `AUTH` SMTP extension and its authentication exchange. ```text C: AUTH mechanism initial-response S: 235 2.7.0 Authentication successful ``` SMTP AUTH can stop an unauthenticated client from using a submission service. It does not create an SPF record, add a DKIM signature, or establish DMARC alignment at the receiving server. Treat SMTP AUTH as an access control for message submission, then configure the server's outbound path to apply the domain-authentication controls described above. ## When does the requirement take effect? There is no single effective date for all email server authentication. SPF was published as [RFC 7208 in April 2014](https://www.rfc-editor.org/rfc/rfc7208.txt), DKIM as [RFC 6376 in September 2011](https://www.rfc-editor.org/rfc/rfc6376.txt), and SMTP AUTH as [RFC 4954 in July 2007](https://www.rfc-editor.org/rfc/rfc4954.txt). DMARC's current controlling specification is [RFC 9989, published in May 2026](https://www.rfc-editor.org/rfc/rfc9989.txt). It obsoletes RFC 7489. DMARC reporting was separated into RFC 9990 and RFC 9991, so implementation work should use the current RFC series rather than relying on an older DMARC draft or RFC 7489 alone. Mailbox providers may set their own operational requirements. For example, Google's sender rules are separate from the RFC publication dates and can change independently. Keep transport encryption distinct from authentication by reviewing [email transport security](/learning/infrastructure). ## How do I implement the requirement? ### 1. Inventory every system that sends as the domain List each production system that sends mail using the domain, including corporate mail, applications, support tools, and marketing systems. Record the SMTP envelope domain, visible From domain, DKIM signing domain, and the system that controls DNS. This inventory is implementation guidance. The RFCs define protocol behavior, but they cannot identify undisclosed sending systems in your environment. ### 2. Publish SPF authorization for the actual envelope senders Publish an SPF TXT record for the domains used in `HELO` and `MAIL FROM`. Include only the sending hosts and authorized service mechanisms that your organization actually uses. Check DNS lookup limits and the record's full evaluated structure before adding multiple service includes. A record that omits a legitimate sender can cause SPF failure. A record that authorizes an unintended sender expands who can use the envelope domain. ### 3. Configure DKIM signing for every sending path Generate the DKIM selector and public key in each sending system, then publish the generated public key at the required selector name. Send a test message through each production path and inspect its delivered headers for a DKIM result. Do not assume a platform's configuration page proves live signing. The delivered message is the evidence that the production path added a signature and that a receiver could validate it. ### 4. Publish DMARC and check alignment Publish the DMARC TXT record at `_dmarc.<domain>`. Compare the visible From domain with the SPF-authenticated domain and DKIM signing domain in messages from every sending path. Start with evidence, not a policy guess. DMARC aggregate reports can show sources and authentication or alignment issues once reports accumulate. [DMARC and DKIM implementation guidance](/resources-post/in-depth-guide-to-understanding-and-implementing-dmarc-and-dkim) can help with the adjacent configuration task. ## How do I validate compliance? Validate each layer independently: - DNS: query the authoritative DNS service and at least one public resolver for SPF, DKIM, and DMARC records. Use the [DNS lookup tool](/tools/dns-lookup) to inspect public DNS responses. - Sender configuration: confirm each platform reports that it has verified the DNS records or activated signing, where the platform provides that status. - Delivered message: send a real message through the exact production path and inspect its `Authentication-Results` header. RFC 8601 defines the syntax and trust model for that field. - DMARC: review aggregate reports after they accumulate to identify sources and alignment outcomes across the domain. A public DNS lookup can show a currently resolvable record. It cannot prove that a specific application signed the message, that a receiver accepted the message, or how a receiver will make a private reputation or placement decision. Gmail documents the following SMTP error for unauthenticated sending: ```text 550 5.7.26 This email has been blocked because the sender is unauthenticated. Gmail requires all senders to authenticate with either SPF or DKIM. ``` Use [Google's Gmail SMTP error documentation](https://knowledge.workspace.google.com/admin/support/troubleshooting/gmail-smtp-errors-and-codes) with the message headers to determine whether the failure concerns SPF, DKIM, or the actual sending path. ## Check the authentication records, then separate transport security Inspect the public SPF, DKIM, and DMARC records for the sending domain before changing a record. Then compare those records with a message sent through the affected production path. [Read the email transport security guide](/learning/infrastructure) to assess TLS and transport controls separately. A DNS check cannot prove message behavior, monitor later DNS changes, or guarantee how a receiving provider will treat a future message. If you need ongoing visibility into authentication results and sending sources, [sign up for Palisade](https://app.palisade.email/signup) to monitor your domain's email authentication. ## Sources and further reading - [RFC 9989: Domain-based Message Authentication, Reporting, and Conformance](https://www.rfc-editor.org/rfc/rfc9989.txt) - [RFC 7208: Sender Policy Framework](https://www.rfc-editor.org/rfc/rfc7208.txt) - [RFC 6376: DomainKeys Identified Mail Signatures](https://www.rfc-editor.org/rfc/rfc6376.txt) - [RFC 4954: SMTP Service Extension for Authentication](https://www.rfc-editor.org/rfc/rfc4954.txt) - [Google Workspace Gmail SMTP errors and codes](https://knowledge.workspace.google.com/admin/support/troubleshooting/gmail-smtp-errors-and-codes) ## Frequently asked questions ### How do I fix email server authentication? Publish SPF authorization for the actual sending hosts, configure each sending system to sign with DKIM and publish its public key, then publish DMARC at `_dmarc.<domain>`. Confirm on a delivered production message that SPF or DKIM passes and aligns with the visible From domain. A DNS record alone does not prove the sending application is using it. ### Which email authentication method identifies who the MTA email servers are that have been authorized to send email for a domain? SPF. RFC 7208 defines an SPF record as a DNS record that declares which hosts are authorized to use a domain name for the SMTP `HELO` and `MAIL FROM` identities. ### What are the three types of authentication methods? No email RFC defines SPF, DKIM, and DMARC as three equivalent authentication methods. SPF and DKIM are authentication mechanisms. DMARC is the policy and alignment layer that evaluates their authenticated identifiers for the visible From domain. ### What are the different types of email authentication? SPF authorizes SMTP sending hosts, DKIM verifies a message signature, and DMARC evaluates aligned SPF or DKIM results. SMTP AUTH is separate because it authenticates a client to its outbound SMTP server rather than authenticating the domain to a receiving server. ### Does SMTP AUTH replace SPF, DKIM, or DMARC? No. SMTP AUTH controls whether a client can submit mail through an SMTP server. SPF, DKIM, and DMARC provide domain-authentication evidence to receiving systems after the server sends the message. --- # Email spoofing in cyber security Canonical: https://www.palisade.email/learning/email-spoofing-in-cyber-security > Email spoofing in cyber security is the use of a forged email identity to make a message appear to come from a trusted sender and domain. Email spoofing in cyber security is the use of a forged or misleading email identity to make a message appear to come from a person, company, or domain that did not authorize it. The visible From address alone is not enough to establish who sent a message. Email authentication checks help receiving systems evaluate whether the sending path is authorized to use that domain. ## Quick takeaways - Email spoofing makes a message appear to come from a different sender. - The address displayed in an email client can differ from SMTP identities used to transmit the message. - SPF and DKIM authenticate parts of the sending path or message, while DMARC applies alignment to the visible From domain. - A message can look familiar and still require header and authentication checks. - Opening an unexpected message is different from clicking a link, downloading a file, or providing information. - A domain owner can reduce unauthorized use of its domain with correctly deployed email authentication and DMARC policy. ## How email spoofing works Internet email uses several identities. [RFC 5322 defines the From field](https://datatracker.ietf.org/doc/html/rfc5322) that recipients usually see in a mail client. SMTP also has an envelope sender used during message transport, defined in [RFC 5321](https://datatracker.ietf.org/doc/html/rfc5321). These identities can be different for legitimate operational reasons, so a matching display name or visible address does not, by itself, prove authorization. SPF lets a domain publish which hosts are authorized to send mail using an envelope sender or HELO identity. [RFC 7208 defines SPF](https://datatracker.ietf.org/doc/html/rfc7208). DKIM adds a cryptographic signature that a receiver can verify against a public key published in DNS. [RFC 6376 defines DKIM](https://datatracker.ietf.org/doc/html/rfc6376). DMARC connects those checks to the domain in the visible From field. [RFC 7489 defines DMARC](https://datatracker.ietf.org/doc/html/rfc7489) as a mechanism that lets a domain owner publish a policy and request feedback when SPF or DKIM do not pass with the required alignment. A pass in SPF or DKIM is not automatically a DMARC pass. The authenticated domain must also align with the visible From domain under the applicable alignment rules. For a wider view of impersonation risks, see Palisade's [email threats learning hub](/learning/threats). ## When email spoofing changes from suspicious to actionable A message is suspicious when its claimed identity, request, or delivery context does not match what the recipient can independently verify. The practical decision rule is to avoid treating the visible From line as proof. Use the evidence available: - If the message asks for a password, payment, sensitive information, or an unexpected action, verify the request through a known contact method rather than replying to the message. - If you have access to message headers, inspect the authentication results and compare the visible From domain with the SPF and DKIM domains. - If you manage the claimed domain, inspect its published authentication records and DMARC policy. A public DNS result shows what is published, not whether a particular message used an authorized production path. - If the message contains a link or attachment, do not use it as the route to verify the request. Contact the organization through a previously known website, phone number, or internal directory. A receiver may add its own local policy and reputation signals when deciding how to handle mail. DMARC therefore does not guarantee that every spoofed message is rejected, and a delivered message is not proof that its visible identity was authorized. ## A worked email-identity example This illustrative example shows why the visible From address and the SMTP identities must be read together. ```text From: Billing Team <billing@yourdomain.com> Return-Path: <mailer@unrelated-example.net> Authentication-Results: mx.receiver.example; spf=pass smtp.mailfrom=unrelated-example.net; dkim=pass header.d=unrelated-example.net; dmarc=fail header.from=yourdomain.com ``` In this example, SPF and DKIM pass for `unrelated-example.net`. The visible From domain is `yourdomain.com`. Because neither authenticated identifier aligns with `yourdomain.com`, the example reports DMARC failure. `Authentication-Results` is a structured field for communicating authentication assessments. [RFC 8601 defines its syntax and trust boundary](https://datatracker.ietf.org/doc/html/rfc8601). Treat results added by a trusted receiving or intermediary system differently from text placed into a message by an unknown sender. ![Diagram showing a visible From domain compared with SPF and DKIM authenticated domains before a DMARC result is determined](/images/editorial/email-spoofing-in-cyber-security/email-spoofing-in-cyber-security-identity-flow.webp "1200x676") *Source: Palisade.* The example does not establish what happened to a real message. To investigate a particular email, preserve its full headers and use the recipient organization's security process or mail-provider controls. ## What to check next Choose the next check based on the evidence you have. If you received a suspicious email, keep the message available for your security team and inspect its headers through an approved mail-client or security workflow. Do not rely on the sender name, logo, or display address alone. If the message concerns an account, open the service through a known bookmark or independently typed address. If you manage a domain, start with the domain's published authentication posture. Palisade's [email security score tool](/tools/email-security-score) can help you inspect public email-security configuration. A public check cannot prove why one message was delivered, show a receiver's private reputation decision, or confirm that every application sending mail for the domain is authenticated. For the protocol-specific context, read [what DMARC is in cyber security](/learning/dmarc-cyber-security). DMARC aggregate reports can later help domain owners identify sending sources and authentication or alignment issues, but they do not replace testing messages through the exact production path. > Do not publish a restrictive DMARC policy before legitimate senders have been inventoried and tested. A policy change can affect valid mail that is still failing alignment. ## Build the broader email-security baseline Email spoofing prevention is an operational email-security task, not a one-time visual check. Review the published DNS records, verify each sending service's authentication status, inspect real delivered messages from important production paths, and use DMARC reporting after data accumulates. For the broader controls and operating context, see [Palisade's email security guide](/learning). ## Sources and further reading - [RFC 5321: Simple Mail Transfer Protocol](https://datatracker.ietf.org/doc/html/rfc5321) - [RFC 5322: Internet Message Format](https://datatracker.ietf.org/doc/html/rfc5322) - [RFC 7489: Domain-based Message Authentication, Reporting, and Conformance](https://datatracker.ietf.org/doc/html/rfc7489) - [RFC 8601: Authentication-Results header field](https://datatracker.ietf.org/doc/html/rfc8601) - [RFC 7208: Sender Policy Framework](https://datatracker.ietf.org/doc/html/rfc7208) - [RFC 6376: DomainKeys Identified Mail](https://datatracker.ietf.org/doc/html/rfc6376) ## Frequently asked questions ### What is spoofing in cybersecurity? Spoofing in cybersecurity is the use of a false or misleading identity to make a communication, system, or request appear to come from a trusted source. In email, the misleading identity can involve the visible From address, display name, envelope sender, or another message attribute. ### How can I tell if someone is spoofing my email? Inspect the message headers and compare the visible From domain with the SPF, DKIM, and DMARC results from a trusted receiving system. A mismatch can be a warning sign, but a complete assessment also requires the message context and the recipient organization's security process. ### What happens if I open a spoofed email? Opening a spoofed email is not usually the risky step on its own. The risk starts when you click a link, download or open an attachment, run embedded content, reply with information, or follow an instruction in the message. Treat any unexpected request as unverified and confirm it through a contact path you already had, not one the message supplies. ### Can I stop my email from being spoofed? You cannot stop the attempts, because anyone can put your address in a message they send. What you can do is publish SPF, DKIM, and DMARC so receiving systems recognize unauthorized use of your From domain and apply the policy you asked for. That limits exact-domain spoofing rather than every message that name-drops your organization. ### Does a DMARC pass prove that an email is safe? No, a DMARC pass does not mean an email is safe. It shows only that SPF or DKIM passed with an identifier aligned to the visible From domain, which is a statement about the sender's authorization and not about the content. A compromised account sends perfectly authenticated mail, so keep judging the request itself. ### Is email spoofing the same as phishing? Email spoofing and phishing are not the same thing, though they often travel together. Spoofing is about a misleading sender identity, while phishing is a social-engineering attempt to obtain information, money, or access. A phishing message may use spoofing to look credible, and a spoofed message may exist for some other purpose entirely. --- # Email warmup by GMass: what the public site confirms Canonical: https://www.palisade.email/learning/email-warmup-by-gmass > Email warmup by GMass is not documented on GMass's public homepage. See what GMass confirms and what to check before sending campaigns safely. Email warmup by GMass is not something the GMass public homepage documents as a standalone feature or workflow. GMass documents Gmail-based campaign creation, mail merge, follow-ups, scheduling, reporting, list verification, link testing, spam-trigger checks, and SPF checks. Those features may support campaign preparation, but they do not verify a warmup process or prove that a specific recipient will place a message in the inbox. ## Quick takeaways - GMass documents campaign and pre-send deliverability features on its public homepage. - GMass says campaigns start in Gmail and that "GMass requires Chrome." - The public GMass page does not document a standalone email-warmup setup, sending ramp, or performance result. - List verification, link checks, spam-trigger checks, and SPF checks are different from proof of inbox placement. - Recipient inbox placement remains a receiver-controlled outcome. - Check domain authentication and security signals separately from campaign controls. ## What GMass publicly documents [GMass describes its product](https://gmass.co) as a platform that turns Gmail into an email marketing and cold email platform. Its listed features include mass email, Google Sheets mail merge, campaign reporting, personalization, automatic follow-up emails, and scheduling. Its public campaign description says users compose in Gmail, enter a list, subject, and message, then send a campaign. The same page states, "GMass requires Chrome." GMass also says it can "Verify your list, test links, & fix spam triggers before you send" and announces "Real-time SPF checks when you send a campaign." These are campaign and pre-send checks. They are useful categories to distinguish because they answer different questions: - Campaign controls concern how a sender prepares, schedules, personalizes, or follows up on mail. - List verification concerns the addresses in a sending list. - Link and spam-trigger checks concern pre-send content signals GMass chooses to inspect. - SPF checks concern an authentication mechanism associated with the sending domain. - Inbox placement concerns a receiving system's decision about a delivered message. The available GMass page does not describe a standalone email-warmup feature, a configuration path, a daily sending ramp, a mailbox network, supported warmup providers, or a warmup result. That is a limit of the public page reviewed, not proof that GMass has no such capability elsewhere. For the broader operational context, see [email deliverability](/email-deliverability). Deliverability evidence comes from the real sending path and the receiving system, not solely from a campaign interface. ## When the answer changes The answer changes only when GMass publishes current documentation that specifically identifies an email-warmup feature and explains its operation. A feature page or help article would need to establish the relevant scope, such as how a mailbox is connected, what messages are sent, whether settings exist, and what GMass claims the feature does. Use this decision rule: ![Decision flow for deciding whether GMass public information answers a warmup question or only documents campaign controls](/images/editorial/email-warmup-by-gmass/email-warmup-by-gmass-decision-flow.webp "1200x829") *Source: Palisade.* - If you need campaign composition, list handling, mail merge, follow-ups, scheduling, reporting, or GMass's stated pre-send checks, consult [GMass's public product information](https://gmass.co). - If you need verified instructions for an email-warmup function, do not infer them from the campaign features above. Look for a current GMass feature or help page that explicitly documents warmup. - If you need to assess the domain's published email-security posture before a campaign, inspect the domain separately. - If you need to know why a delivered message authenticated or failed authentication, inspect its raw headers. [Analyzing email headers](/learning/analyze-email-headers-online) is the task that fits that evidence. It is reasonable to infer that campaign controls and pre-send checks do not, by themselves, prove inbox placement. GMass's homepage describes those controls, while it does not publish a statement that they guarantee delivery to a particular recipient inbox. A recipient's mail system can apply its own filtering and placement decisions. ## Worked example: campaign evidence versus warmup evidence Suppose a sender can compose a Gmail campaign in GMass, schedules it, and sees that the list has been checked. That confirms activity in a campaign workflow. It does not answer whether GMass ran a warmup process, whether the production sending domain has all relevant authentication configured, or how a particular recipient handled the message. Use the evidence you have to keep the questions separate: ```text Evidence: GMass campaign controls are available Can confirm: A sender can prepare or schedule a campaign in GMass Cannot confirm: A GMass warmup feature was configured or used Evidence: GMass states it performs an SPF check Can confirm: GMass publicly describes an SPF-related pre-send check Cannot confirm: DKIM or DMARC status, domain alignment, or inbox placement Evidence: A message arrives in a recipient mailbox Can confirm: That specific message reached that mailbox Cannot confirm: Future placement for every recipient or campaign ``` A production authentication check has more layers than a campaign setting: - DNS: confirm the published DNS records through authoritative DNS and a public resolver. - Vendor: check the sending service's current verification or authentication status where the service documents it. - Message: send a real message through the exact production path and review its authentication results in the delivered headers. - DMARC: use aggregate reports after data accumulates to identify sending sources and authentication or alignment issues. A green indicator at one layer does not replace the others. In particular, a public DNS result does not show which application sent a message, and a delivered message does not guarantee future placement. ## What to check before relying on campaign delivery Start with the evidence closest to the question: - If you are deciding whether GMass includes warmup, use current GMass documentation that explicitly names and explains that feature. The available public homepage does not provide those instructions. - If you are preparing a campaign and need to inspect the domain's public authentication and security signals, use an [email security score check](/tools/email-security-score). - If you have a delivered or rejected message, inspect the actual headers from that sending path. Public domain checks cannot explain every receiver decision. - If you operate recurring mail across domains, use DMARC aggregate-report data to identify sending sources and prioritize authentication or alignment remediation. A public email-security check can inspect published domain signals. It cannot verify a GMass warmup feature, confirm the exact production sending path, continuously monitor later changes, or guarantee inbox placement. ## Check the domain evidence behind the campaign Before treating campaign preparation as deliverability proof, inspect the sending domain's public email-security signals. This is the useful next action when you have a domain but no current GMass documentation that verifies a warmup workflow. [Check the domain's email security score](/tools/email-security-score) That check does not prove that GMass provides email warmup, repair a sender configuration, show a receiver's private placement decision, or guarantee that future messages will reach the inbox. For teams that need to work through recurring DMARC aggregate-report findings across domains, [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=deliverability&utm_content=email-warmup-by-gmass). Palisade is agentic DMARC software that analyzes aggregate-report data, identifies sending sources and authentication or alignment issues, and proposes prioritized remediation work. A human reviews the evidence and applies changes. Palisade does not control GMass features, change a receiver's private reputation decision, or guarantee delivery. ## Sources and further reading - [GMass product homepage](https://gmass.co) - [Palisade email security score checker](/tools/email-security-score) - [Email deliverability](/email-deliverability) - [Analyze email headers online](/learning/analyze-email-headers-online) ## Frequently asked questions ### Does GMass have email warmup? No, the available GMass public homepage does not document a standalone email-warmup feature, its setup, or its results. It documents campaign features and pre-send checks. Confirm any current warmup capability through GMass documentation that specifically describes it. ### Does GMass check SPF before sending? GMass states that it provides "Real-time SPF checks when you send a campaign." The public page reviewed does not explain whether that check covers alignment, DKIM, DMARC, every plan, or every sending path. ### Does a GMass campaign prove inbox placement? No. A campaign can be composed, scheduled, or sent without proving how a particular recipient system will classify or place it. Recipient systems make their own delivery and placement decisions. ### Do list verification and spam-trigger checks replace authentication checks? No. GMass describes list verification, link testing, and spam-trigger checks as pre-send features. SPF, DKIM, DMARC, and alignment need separate DNS, vendor, message, and DMARC-report evidence. ### Can a public domain check verify the GMass sending path? No. A public domain check can inspect published DNS and email-security signals. It cannot prove which GMass configuration or production path sent a message, or how a receiving system handled it. --- # Email warmup company: how to assess one Canonical: https://www.palisade.email/learning/email-warmup-company > Email warmup company services connect mailboxes for message exchanges or simulated activity. Assess their diagnostics, data handling, and claims. An email warmup company is a vendor that connects to a sending mailbox and performs or simulates mailbox activity, such as exchanging messages, opens, and replies. Vendors present this activity as a way to build sender trust or support inbox placement, but the available provider and standards evidence does not verify that warmup improves deliverability. Assess the company's observable diagnostics, access model, and claims before relying on it. ## Quick takeaways - An email warmup company is a vendor category, not a mailbox-provider standard or protocol. - Vendors describe different mechanisms, including message exchanges and simulated human-like activity. - No supplied primary provider or RFC source confirms that email warmup improves inbox placement. - There is no verified universal warmup volume, duration, reply rate, or safe sending threshold. - Authentication, DNS, and message evidence should be checked separately from a vendor's warmup activity. - A placement test or blacklist check is diagnostic evidence, not proof of future inbox placement. ## How an email warmup company works Email warmup companies generally ask for access to a sending mailbox, then describe recurring activity intended to make that mailbox look active to receiving systems. For example, [Warmup Inbox describes its email warmup tool](https://warmupinbox.com) as connecting a sending inbox through Gmail, Outlook, or SMTP and exchanging messages within its network, including opens and replies. Warmforge says its product works by "mimicking human behaviour in your mailboxes to establish trust with ESPs." That is Warmforge's description of its mechanism, not a mailbox-provider-confirmed explanation of how Gmail, Microsoft, or another receiver makes placement decisions. Other vendors describe different connection and reporting options. [TrulyInbox says its product supports Google and Microsoft sign-in, as well as SMTP and IMAP connections](https://trulyinbox.com), and presents ESP-level deliverability information. These are vendor-specific product claims. They do not establish that every email warmup company has the same capabilities or that a reported result will apply to later production mail. The key distinction is between activity a warmup vendor says it performs and evidence you can inspect yourself. A warmup network's messages are not the same as business mail sent through your production application, CRM, transactional platform, or employee mailbox. Broader [email deliverability](/email-deliverability) also depends on the sending path, authentication, recipient behavior, and each receiver's local decisions. ![Decision flow for separating an email warmup company's claimed activity from independently observable DNS, authentication, placement, and monitoring evidence](/images/editorial/email-warmup-company/email-warmup-company-decision-flow.webp "1200x829") *Source: Palisade.* ## When the answer changes A company may be useful for a narrow internal experiment, but its claims should not replace a sender-readiness assessment. Use this decision rule: - If the company can only describe warmup activity, treat it as an unverified service claim. Ask what mailbox access it needs, how access can be revoked, and what data it stores. - If it provides DNS, authentication, blacklist, or placement diagnostics, separate those observable outputs from any claim that warmup caused an outcome. - If it reports results by mailbox provider, compare the result with mail sent through the exact production path. A test inbox and a production recipient list can receive different treatment. - If a provider's decision or inbox placement remains unclear, look for message headers, bounce evidence, and the receiver's own available diagnostics. A third-party score cannot reveal every private receiver signal. This distinction matters when comparing products such as [AI email warmup services](/learning/ai-email-warmup) or a platform-specific offering such as [Apollo email warmup](/learning/apollo-email-warmup). The useful question is not whether a label sounds more advanced. It is whether the company gives you evidence that applies to your own domain and production sending path. Do not treat warmup as a replacement for domain authentication. SPF, DKIM, and DMARC address whether a message can authenticate with identifiers aligned to the visible From domain. Sender activity does not correct a missing DNS record, a broken DKIM signature, or an unaligned return path. ## A worked evaluation example Suppose a marketing team is considering a vendor that asks to connect `sales@yourdomain.com` and promises a warmup program. Record the vendor's claim separately from the evidence you need before changing any sending behavior. ```text Email warmup company evaluation for yourdomain.com Vendor claim: - Connects a mailbox and exchanges or simulates mailbox activity. Authentication baseline: - SPF record exists and covers the production sending service. - DKIM passes on a delivered message from the production service. - DMARC passes with an aligned SPF or DKIM identifier. Observable diagnostics: - DNS and MX status - Placement test results, identified by receiving provider - Blacklist-status result and lookup time - Raw headers from a real delivered production message Access and data questions: - Connection method: OAuth, SMTP, or IMAP - Permissions requested and revocation process - Data retained from the connected mailbox ``` This is a decision record, not a validated warmup recipe. There is no supplied primary evidence that establishes a safe number of messages, replies, or days for the program. Warmforge says its Health Checks monitor DNS, MX-record, and blacklist status, and it describes placement tests as a separate feature. TrulyInbox describes provider-level deliverability reporting. Those descriptions support a practical inference: diagnostics can be evaluated independently, while the claimed effect of warmup still needs evidence from the actual sending path and receiving systems. A DNS or reputation result also has limits. It cannot prove that the production application is using the expected authentication setup, that a receiver will make the same decision for future messages, or that a connected mailbox's activity improved placement. ## Check the baseline before attributing a problem to warmup Start with the evidence you have. - If you have a domain but no message sample, inspect the public DNS and email-authentication posture first. - If you have a message that landed in spam or failed delivery, preserve the raw headers and compare SPF, DKIM, and DMARC results with the visible From domain. - If you have a vendor placement report, record the tested provider, date, sending path, and recipient type. Do not assume it predicts every recipient's outcome. - If you manage multiple domains or sources, keep an inventory of each source and its aligned authentication status. One warmed mailbox does not establish readiness for every source. For the wider operating context, the [deliverability learning hub](/email-deliverability) covers related sending and authentication topics. The goal is to identify a specific defect or unknown before purchasing or expanding a warmup service. ## Check the email-authentication baseline behind the warmup claim Run the sending domain through Palisade's [Email Security Score](/tools/email-security-score) before treating a warmup service as the explanation for an inboxing problem. Use the result to identify public DNS and authentication issues that should be investigated separately from mailbox activity. [Check the email security baseline](/tools/email-security-score) A public check cannot prove that a production message used the expected path, repair a sender configuration, monitor future changes, or guarantee inbox placement. If your team needs to keep inventorying sending sources and reviewing DMARC aggregate-report evidence over time, [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=email_warmup&utm_content=email-warmup-company). Palisade autonomously analyzes DMARC aggregate-report data, identifies sending sources and authentication or alignment issues, and creates prioritized remediation tickets. A human reviews the evidence and applies any DNS or DMARC policy change. ## Sources and further reading - [Warmup Inbox email warmup tool](https://warmupinbox.com) - [Warmforge email warmup and deliverability features](https://warmforge.ai) - [TrulyInbox email warmup product](https://trulyinbox.com) - [Palisade Email Security Score](/tools/email-security-score) - [Palisade guide to email deliverability](/email-deliverability) ## Frequently asked questions ### Does email warm up actually work? Warmup companies say it does, but no mailbox provider publishes a rule that rewards the activity, so nobody can show the practice itself causes better placement. Warmup Inbox describes exchanging messages inside its own network, and Warmforge describes mimicking human behaviour in mailboxes. Both describe what the product does, not what a receiver does next. ### What is the best email warm up tool? There is no best one, because nobody publishes a like-for-like comparison and no tool controls a receiver's placement decision. Judge each company on what you can check yourself: the mailbox access it asks for, how you revoke that access, what data it keeps, and which diagnostics it actually shows you. Then compare its reported result against mail sent through your real production path. ### What is email warmup? Email warmup is a vendor-run practice where a service connects to your sending mailbox and generates activity around it, usually by exchanging messages and engagement inside its own network. Warmup Inbox describes those network exchanges, while Warmforge describes simulating human-like mailbox behaviour. It is a product category rather than a mailbox-provider standard, so no receiver is obliged to read that activity as a positive signal. ### Can a warmup company fix DMARC failures? No, because a warmup company never touches your DNS or your signing setup. It cannot make an SPF or DKIM identifier align with your visible From domain, and it cannot publish a DMARC record for you. Check the DNS configuration and the authentication results on a real message before you blame a DMARC failure on reputation. --- # Email warmup GitHub: what the search does and does not show Canonical: https://www.palisade.email/learning/email-warmup-github > Email warmup GitHub does not identify a verified GitHub warmup feature. Check the actual sending domain's authentication and security evidence. Email warmup GitHub does not identify a verified GitHub email-warmup feature or setup workflow. GitHub is a platform for developers, code, collaboration, automation, and security, while email warmup refers to activity performed by an email-focused service. If you are assessing a real sending domain, inspect its authentication and security posture first instead of assuming that a GitHub search result proves anything about sending behavior or inbox placement. ## Quick takeaways - [GitHub](https://github.com) describes a platform for developers, agents, and code, not a documented native email-warmup product. - A GitHub repository is code and documentation, not proof that a production sending domain is authenticated or trusted by receivers. - Mailwarm describes its own warm-up service as exchanging messages with accounts in its network, including inbox actions. - The cited material does not establish that email warmup improves reputation, avoids spam filtering, or guarantees inbox placement. - A public domain assessment can inspect published email-security evidence, but it cannot prove a receiver's private decision about a specific message. - Deliverability investigation starts with the actual sender, domain, and message path. ## How the distinction works GitHub says its platform brings together "developers, agents, and code" and presents capabilities for code, planning, collaboration, automation, and security on its [main product page](https://github.com). That page does not document an email-warmup product, native setup flow, integration, or recommended workflow. This is a narrow observation about the cited GitHub page. It does not prove that GitHub contains no repository, third-party project, or discussion related to warmup. A specific project would need its own repository URL, documentation, maintenance history, and operating instructions before it could be evaluated as a concrete tool. An email warmup service is a different kind of system. For example, [Mailwarm's product page](https://mailwarm.com) states: "Your email account automatically sends dozens of emails to +50,000 Mailwarm's accounts, and get replies." It also describes inbox actions, including "Moved to Inbox." Those statements describe Mailwarm's stated service behavior only. They do not establish a universal result for every warmup service, sending domain, mailbox provider, or recipient. For the wider operational topic, see [email deliverability](/email-deliverability). Delivery depends on the real production path. A code-hosting search cannot establish whether an application sends mail, which domain it uses in the visible From field, or whether that mail authenticates. ![Decision flow separating a GitHub search result from evidence about the actual sending domain](/images/editorial/email-warmup-github/email-warmup-github-evidence-flow.webp "1200x676") *Source: Palisade.* ## When the answer changes The answer changes when you have a specific, documented repository or an actual sending system to assess. A GitHub project may be relevant if its own documentation identifies: - The maintained repository and its owner. - The email service or mailbox accounts it connects to. - The data it reads, sends, or stores. - The authentication method and any required permissions. - Its production safeguards, limits, and rollback process. Without those details, "email warmup GitHub" is a navigational search phrase, not a verified implementation plan. The question also changes when you have evidence from the sending domain itself. Published DNS records can show whether a domain has certain email-authentication and security records. They cannot show whether the production application uses those records correctly, whether a delivered message passed authentication, or how a recipient handled it. > Do not treat a public DNS result as approval to begin or expand a production sending program. Validate the exact message path before changing sending behavior. If you are choosing between a repository and a warmup provider, keep the assessment separate from deliverability claims. The available evidence does not support a claim that either option will improve inbox placement. It also does not identify a native GitHub alternative to an email-warmup service. Related searches may lead to product-specific pages such as [AI email warmup](/learning/ai-email-warmup) or [Apollo email warmup](/learning/apollo-email-warmup). Those pages concern distinct product contexts. They do not turn GitHub itself into a verified email-sending platform. ## A worked evidence rule for this search Use this decision rule before acting on an "email warmup GitHub" result: ```text Search result: "email warmup GitHub" If there is no specific repository URL and current project documentation: Do not infer a GitHub email-warmup feature or production workflow. If there is a specific repository: Review its documented owner, scope, permissions, data handling, and release activity. Do not infer deliverability results from repository presence alone. If you need to assess a sending domain: Inspect the domain's published email-security posture. Then validate the actual production sender and a real delivered message separately. ``` The final two checks answer different questions. - A domain-level check can inspect public DNS evidence associated with email security. - A delivered-message check requires a real message from the exact production path and its available headers or receiving-system evidence. - Ongoing DMARC analysis requires aggregate-report data after reports accumulate. That separation matters because a domain can publish records that a particular sender does not use. A sender can also use an authenticated domain while a receiver makes a separate local delivery or placement decision. Mailwarm's own site includes the question "Is email warmup enough to fix deliverability issues?" in its FAQ navigation, but the cited material does not provide an answer. Do not fill that evidence gap with a claim about effectiveness. ## Take the next step with the evidence you have If your only evidence is a GitHub search, find the exact repository and read its current documentation before connecting accounts, granting permissions, or sending mail through it. If you have a sending domain, use [Palisade's email security score](/tools/email-security-score) to inspect its public email-security posture. Record the domain you checked and compare the result with the DNS configuration your team expects. If you have a message from the production sender, keep the message evidence separate from the public lookup. Check the visible From domain, the sending application, and the authentication results available for that exact message. If the sender is part of a broader program, use the [deliverability hub](/email-deliverability) to frame the work around the actual sending path. ## Check the sending domain behind the search A GitHub result does not show the email-security records published for the domain you plan to send from. Check that actual domain first, then compare the public result with your intended DNS configuration. [Check the domain's email security posture](/tools/email-security-score) A public domain check cannot prove that a repository is safe to connect, that a production application is using the domain correctly, that a receiver will place a message in the inbox, or that email warmup repaired a sending problem. For ongoing DMARC work, Palisade is agentic DMARC software that analyzes aggregate-report data, identifies authentication or alignment issues, and proposes the next policy step for human review. It does not autonomously change your DMARC policy or guarantee delivery. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=email_deliverability&utm_content=email-warmup-github) ## Sources and further reading - [GitHub](https://github.com) - [Mailwarm](https://mailwarm.com) - [Palisade email security score](/tools/email-security-score) - [Palisade email deliverability guide](/email-deliverability) ## Frequently asked questions ### Does GitHub have a native email-warmup feature? GitHub does not document an email-warmup feature, and its product page presents code, planning, collaboration, automation, and security instead. Warmup is something email services sell, not a code-hosting platform. Anything warmup-related you find on GitHub is third-party code rather than a GitHub product. ### Does a GitHub repository prove that email warmup will work? No, because a repository holds code and documentation, not evidence about your mail. Its existence says nothing about how a domain sends, whether those messages authenticate, or what a receiver does with them. ### Is Mailwarm the same as GitHub? No, they are different kinds of product. GitHub is a platform for developers and code. Mailwarm describes an email-warmup service that exchanges messages with accounts in its stated network. ### Can a public domain check prove inbox placement? No, because a public domain check reads published records rather than a receiver's decision. It can show the email-security evidence a domain publishes. It cannot show how a receiver handled one message or where the next one will land. ### Should I connect an email account to a GitHub project found in search? Connect an account only after you have identified the exact project and reviewed its current documentation, owner, permissions, data handling, and production safeguards. A search result on its own does not name a specific repository worth approving. Handing mailbox access to unreviewed code puts that account and its mail at risk. --- # Email warmup reviews: what vendor claims can prove Canonical: https://www.palisade.email/learning/email-warmup-reviews > Email warmup reviews should compare documented controls and independently test placement, because vendor claims alone cannot prove deliverability results. Email warmup reviews should assess what a provider documents, what access it requires, and what evidence you can collect from your own sending path. A warm-up vendor may describe automated mailbox activity as a way to establish or maintain reputation, but those claims alone do not prove that your messages will reach the inbox or that the service is safe to scale. ## Quick takeaways - Email warm-up tools commonly market automated mailbox activity intended to build or maintain sender reputation. - A provider's claimed inbox-placement result is not independent proof that warm-up caused the result. - Connection method, diagnostics, reporting, controls, and measurement transparency are useful review criteria. - Domain authentication and the actual production sending path need separate validation. - A readiness score or provider dashboard does not prove future inbox placement. - [Email deliverability](/email-deliverability) includes more than sender reputation. Receiver policy, authentication, and message context also affect outcomes. ## How email warm-up products work Email warm-up products generally describe exchanges among mailboxes that create activity around a sender account. For example, [Warmforge describes its warm-up process](https://warmforge.ai) as mimicking human behaviour in mailboxes to establish trust with ESPs. [MailReach describes its product](https://mailreach.co) as using positive interactions with a network of high-reputation accounts to "Repair, raise and maintain" sender reputation automatically. Those are vendor descriptions of their services. They do not establish a universal protocol mechanism or prove that a warm-up service improves inbox placement for every sender. The distinction matters because inbox placement is a receiver decision. A mailbox provider can consider authentication, reputation, user feedback, content, sending patterns, and local policy. A warm-up dashboard may show activity in the vendor's network, while a real campaign can take a different route, use a different From domain, or fail authentication. Start by separating two questions: - What does the service say it creates or measures? - What evidence shows that the exact production messages you plan to send authenticate and are accepted as intended? Authentication is one part of that evidence. Review [AI email warmup: what it is and what it cannot prove](/learning/ai-email-warmup) before treating an automated warm-up claim as a complete deliverability diagnosis. ## When a warm-up review changes the decision A useful review compares documented capabilities, not marketing outcome claims. The vendors in this category disclose different controls and signals. Warmforge says its Health Checks monitor DNS records, MX records, and blacklist status. This is a vendor-specific feature statement. It does not mean every warm-up product offers those checks or that a clean result proves production delivery. MailReach states that it is compatible with email service providers that support SMTP. That statement is relevant if SMTP compatibility is a requirement for your sender, but it does not describe another provider's connection method, permissions, or security controls. [TrulyInbox presents warm-up strategies](https://trulyinbox.com) described as "progressive, random, or flat" and offers an "Outreach Readiness indicator." It also says, "Your score updates daily." Those controls may be useful to evaluate, but a score is not evidence that a future prospecting message will reach a recipient's inbox. Use this decision rule: - Keep a product in consideration when its documented connection method fits your sending platform, its controls match your operating needs, and it clearly identifies what its metrics measure. - Do not treat a product's reported score, network activity, or placement claim as proof of a campaign outcome. - Require a test using your authorized sending domain and the same production path before increasing sending volume. - Pause the decision if the provider cannot explain the access it needs, the data it retains, or the difference between vendor-reported activity and independently measured delivery. ![Checklist for reviewing an email warm-up provider: connection method, diagnostics, reporting, operating controls, and independent placement measurement](/images/editorial/email-warmup-reviews/email-warmup-reviews-review-checklist.webp "1200x639") *Source: Palisade.* ## A worked email warm-up review A review record should capture a provider's documented statements alongside the evidence you still need. Do not convert a vendor's suggested timing into a universal ramp schedule. ```text Warm-up provider review: illustrative only Connection method: - Documented provider compatibility or supported protocol: - Required mailbox permissions: - Sending domain used for the test: Documented controls: - Warm-up strategy controls: - DNS, MX, blacklist, or spam-test diagnostics: - Reporting cadence and metric definitions: Evidence to collect separately: - Published SPF, DKIM, and DMARC records - Delivered test-message headers from the production path - Recipient-side inbox, spam, or rejection result - Campaign results measured after an approved sending change ``` For example, Warmforge advises users to warm up a newly connected mailbox "for at least 2 weeks before you reach out to any prospects" and to keep warm-up enabled afterwards. That is [Warmforge guidance](https://warmforge.ai), not a duration that applies to every domain, sender, or mailbox provider. Likewise, TrulyInbox says, "Most see 95%+ in 2-3 weeks." Attribute that as a vendor outcome claim. It does not establish that the same result will occur for your domain or campaign. A review should also note capabilities beyond warm-up. [EmailWarmup.com markets](https://emailwarmup.com) personalized warmup, real-time mailbox monitoring, and automated rotation. That can support a question about the product's stated diagnostic scope. It cannot establish the accuracy of its monitoring or the effect on receiver decisions. > Do not increase production volume because a warm-up provider reports a favorable score. First test mail through the same authenticated sender, application, and route that production mail will use. ## Take the next step from the evidence you have If you are comparing warm-up products before a campaign, document the proposed connection method and obtain the provider's current privacy, permissions, and security information. Those facts are outside the performance claims on a marketing page. If you already have a sending domain, first inspect its public email-security signals with the [Email Security Score tool](/tools/email-security-score). Then compare those public DNS results with the settings in the service that sends your production messages. Public checks can reveal published signals, but they cannot prove that an application is signing mail, that a receiver will place a message in the inbox, or that a warm-up provider improved reputation. For a delivered test message, inspect the raw message headers and confirm the authentication result from the actual production path. The [Apollo email warmup review](/learning/apollo-email-warmup) explains why a product workflow and a real delivered-message result are different kinds of evidence. ## Review your domain before relying on warm-up Before treating warm-up as the explanation or remedy, inspect the domain's published email-security signals and compare them with the authenticated sending path you intend to use. [Inspect your email security score](/tools/email-security-score) A public domain check cannot prove that a warm-up service caused inbox placement, repair a sender configuration, monitor future campaign performance, or predict a receiver's private placement decision. For teams that need to identify sources and authentication or alignment issues across ongoing DMARC report data, [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=email_deliverability&utm_content=email-warmup-reviews). Palisade analyzes DMARC aggregate-report data, identifies sending sources and issues, and proposes prioritized remediation work for human review. It does not control a mailbox provider's reputation decision, guarantee placement, or automatically change your DMARC policy. ## Sources and further reading - [Warmforge product information](https://warmforge.ai) - [MailReach product information](https://mailreach.co) - [TrulyInbox product information](https://trulyinbox.com) - [EmailWarmup.com product information](https://emailwarmup.com) - [Palisade Email Security Score tool](/tools/email-security-score) ## Frequently asked questions ### Does email warm-up actually work? Warm-up vendors say it does, but none of them publish independent proof, and inbox placement stays the receiver's decision either way. Warmforge, MailReach, and TrulyInbox all describe automated mailbox activity meant to build sender reputation, and those are their own marketing claims about their own products. Test the real production sending path and read the delivered message headers before you raise volume. ### What is the best email warm-up tool? There is no single best tool, because no independent comparison of these products exists and the right fit depends on your sending platform. Compare what each vendor documents: how it connects to a mailbox, what access it needs, what its diagnostics cover, and how it defines the numbers it reports. Then run your own test through the production path before you commit. ### Is Mailmeteor safe to use? That depends on what access you are willing to grant. Before you connect a mailbox, read Mailmeteor's current permissions, privacy, security, and data-handling documentation, then decide whether that scope is acceptable for your organization. Apply the same test to any warm-up or sending tool that asks to connect to your mail. ### Can a clean DNS check prove a warm-up tool is working? No, because a DNS check only reads what your domain publishes, not what your mail actually does. It cannot show whether your sending application uses the intended authentication settings, whether warm-up activity changed your sender reputation, or where a receiver will place your next message. Use a delivered test message from the production path for that. --- # Emailchaser email warmup Canonical: https://www.palisade.email/learning/emailchaser-email-warmup > Emailchaser email warmup gradually ramps up new mailboxes, according to Emailchaser. Learn what that claim covers and what it cannot prove here. Emailchaser email warmup is Emailchaser's stated feature for gradually ramping up new mailboxes within its cold-email platform. Emailchaser says it will "Ramp new mailboxes up gradually, with no fake-engagement network." That describes a sending-volume approach, not proof of inbox placement, sender reputation, or the security posture of the domain. For the wider context, see the [email deliverability learning hub](/email-deliverability). ## Quick takeaways - Emailchaser lists email warm-up as part of its cold-email toolkit. - Emailchaser says its software gradually increases the number of emails sent each day to minimize risk. - Gradual sending is not an independently verified guarantee that messages will reach an inbox. - Emailchaser says one subscription can connect an unlimited number of sending accounts. - Inbox rotation and warm-up are separate stated features that can both affect how a campaign sends. - Authentication and domain security still need their own review before sending volume increases. ## How Emailchaser email warmup works On its [product site](https://emailchaser.com), Emailchaser describes email warm-up as a gradual ramp for new mailboxes and says it does not use a fake-engagement network. Its stated sending mechanism is that the software "gradually increases the number of emails sent per day, to minimize risk." The useful distinction is between a platform's stated ramp-up behavior and a deliverability result. The first is a product feature: daily sending volume rises over time. The second is an outcome at a receiving mailbox provider, which can depend on factors beyond send volume. Emailchaser's public statement supports the first claim. It does not establish that every mailbox will gain reputation, avoid filtering, or reach the inbox. Emailchaser also says it can connect an "unlimited number of email sending accounts." Its inbox-rotation description says that it rotates sending emails between connected accounts in a campaign "in a natural way." Rotation distributes campaign sending among accounts. Warm-up describes the gradual ramp of a new mailbox. Treat them as different controls, even when both are used in the same campaign. For a broader explanation of delivery outcomes and the factors around them, read [what email deliverability means](/email-deliverability). ## When the answer changes The answer changes according to the evidence you have and the decision you need to make. If you only need to know what Emailchaser advertises, its public description supports this answer: its warm-up feature gradually ramps new mailboxes and its sending software gradually increases daily emails to minimize risk. If you need to know whether a specific mailbox is ready for a higher volume, the public product description is not enough. Review evidence from the real sending path, such as delivery results from that mailbox and the authentication status of messages it sends. A product feature description cannot establish the condition of an individual domain or account. If the concern is an email's authentication posture, use a separate check. Warm-up does not replace SPF, DKIM, or DMARC. These controls concern whether a message can authenticate in a way that supports the visible From domain. For a related explanation of feature claims and evidence limits, see [AI email warmup: what it is and what it cannot prove](/learning/ai-email-warmup). A practical decision rule is: ```text Use Emailchaser's stated warm-up feature to ramp a new mailbox gradually. Do not treat the ramp as proof of inbox placement, reputation, or domain authentication. Before increasing campaign volume, review the sending domain's current security and authentication posture, then inspect real delivery evidence from the same mailbox. ``` ![Decision flow showing that Emailchaser's stated gradual mailbox ramp is separate from authentication checks and real delivered-message evidence](/images/editorial/emailchaser-email-warmup/emailchaser-email-warmup-decision-flow.webp "1200x829") *Source: Palisade.* ## Worked example: what the product claim does and does not answer Suppose a team connects a new sending mailbox to Emailchaser for an outreach campaign. Emailchaser's published description supports the expectation that the platform will increase daily send volume gradually. If the team connects multiple accounts, Emailchaser also states that inbox rotation can distribute campaign sends between those accounts. That gives the team an operational claim to verify in its own account: whether the configured mailbox and campaign are following the intended volume pattern. It does not answer these separate questions: - Whether the visible From domain has correctly published SPF, DKIM, and DMARC records. - Whether the production application is signing messages with DKIM or using the intended return path. - Whether a receiving provider will accept, filter, or place a particular message in the inbox. - Whether the new mailbox has a delivery issue unrelated to daily volume. - Whether any connected account should receive more sending volume. > Do not increase business-critical sending volume based only on a warm-up setting or a public DNS result. Check messages sent through the real production path and keep a rollback option for campaign-volume changes. Emailchaser's published commercial information also matters when evaluating the feature. The company says [plans start at "$23 /month"](https://emailchaser.com). Its listed Starter plan includes "5,000 emails / month · 1,000 active contacts" and "Unlimited email accounts." Emailchaser also advertises a "7-day free trial · Cancel anytime." Pricing, included features, and limits can change, so confirm the current plan details with Emailchaser before purchasing. ## Take the next step based on your evidence Start with the evidence closest to the question: - If you are comparing Emailchaser's stated capabilities, check its current product and pricing pages for the feature and plan details that apply to your account. - If you have a sending domain but no message evidence yet, [check the domain with Palisade's Email Security Score](/tools/email-security-score) before scaling campaign volume. - If you have delivered messages, inspect the authentication results for messages from the exact mailbox and campaign path. A public DNS result alone does not prove that the application is using the records you published. - If you are evaluating another platform's warm-up claim, compare its stated mechanism with the same evidence standard. [Apollo email warmup](/learning/apollo-email-warmup) is a related example. ## Check the sending domain before scaling Emailchaser volume A gradual mailbox ramp does not show whether the sending domain's authentication and security posture needs attention. Use Palisade's Email Security Score to inspect the domain before treating a higher campaign volume as safe to test. [Check the sending domain's Email Security Score](/tools/email-security-score) A score check does not prove that Emailchaser configured warm-up correctly, monitor a mailbox's ongoing delivery, explain a receiver's private filtering decision, or guarantee inbox placement. For teams that need ongoing DMARC aggregate-report analysis across sending sources, [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=warmup_and_sending_practices&utm_content=emailchaser-email-warmup). Palisade analyzes DMARC aggregate-report data, identifies authentication or alignment issues, and proposes policy steps for human review. It does not change DMARC policy automatically or guarantee delivery. ## Sources and further reading - [Emailchaser product and pricing information](https://emailchaser.com) - [Palisade Email Security Score](/tools/email-security-score) - [Email deliverability](/email-deliverability) - [AI email warmup: what it is and what it cannot prove](/learning/ai-email-warmup) ## Frequently asked questions ### What is the best email warmup tool? There is no best one, because no independent comparison of these products exists and none of them control where a receiver puts your mail. Emailchaser describes its own warm-up as a gradual ramp for new mailboxes with no fake-engagement network, which tells you its approach but not its ranking. Compare tools on the access each one needs and on what your own delivered mail shows. ### How much does Emailchaser cost? Emailchaser says plans start at $23 per month. Its listed Starter plan includes 5,000 emails per month, 1,000 active contacts, and unlimited email accounts. Check Emailchaser's current pricing page before purchase because plan details can change. ### Does email warm up actually work? Emailchaser says its gradual ramp lowers risk, and that is a claim about its own software rather than a measured deliverability result. No mailbox provider publishes a rule that rewards warm-up activity, so nobody can show the practice itself lifts placement for a given mailbox. Ramping up gradually is still sensible, but confirm it with real delivery evidence from that mailbox. --- # ESET anti-phishing protection is non-functional Canonical: https://www.palisade.email/learning/eset-anti-phishing-protection-is-non-functional > ESET anti-phishing protection is non-functional when its product-specific status needs diagnosis. Identify the product, symptom, and official support path. ESET anti-phishing protection is non-functional only when the relevant ESET product identifies a specific protection failure or when a reproducible symptom shows the feature is not operating as expected. The query alone does not establish the product, operating system, browser, warning, or cause. Start by preserving the exact status text and identifying the installed ESET product, then use ESET's product-specific documentation or support path. ## Quick takeaways - "Anti-phishing protection is non-functional" is not enough information to identify a safe repair. - The exact ESET product, version, operating system, and symptom determine which documentation applies. - A browser, endpoint, or URL-protection issue is separate from DMARC, SPF, and DKIM authentication. - Do not change security settings based on a generic fix that does not match the displayed ESET status. - ESET directs users to search its help pages, documentation, guides, and FAQs before using its support path. - A domain email-security assessment does not test whether ESET endpoint protection is active. ## What the message does and does not establish A report that ESET Anti-Phishing protection is non-functional establishes a need for product-specific diagnosis. It does not, by itself, establish that phishing email reached a mailbox, that a browser extension failed, or that a domain's email authentication is misconfigured. Phishing is an attempt to obtain information or induce an unsafe action through impersonation or deceptive content. [Palisade's explanation of phishing](/learning/what-is-phishing) covers that broader threat. Endpoint and browser protections can be part of a layered defense, but a single endpoint status does not describe every protection layer. The available public ESET support entry points direct users toward documentation and assistance rather than providing one universal remediation sequence. [ESET Help](https://help.eset.com) asks users to "Search through ESET help pages, documentation, guides, and FAQs." [ESET Support](https://support.eset.com) provides Knowledgebase and Technical Support paths. That distinction matters because the same wording may refer to different products or environments. Without the exact product-specific page, it is not safe to infer: - Whether the relevant feature is an endpoint, browser, email-client, or network control. - Whether a setting is enabled, disabled, excluded, unavailable, or reporting an error. - Whether an update, browser component, policy, license state, or another condition is involved. - Which navigation path or repair action ESET currently documents. ## When the answer changes Use this decision rule before taking action: - If you have an exact ESET warning or status, search that text with the ESET product name on [ESET Help](https://help.eset.com). - If you know the product but do not have the exact symptom, record the product name, version, operating system, and where the warning appears before searching the product documentation. - If the issue occurs only in a browser or on one endpoint, keep the investigation scoped to that device and its documented ESET configuration. - If the concern is phishing messages that use your organization's domain, inspect sender authentication and domain controls separately. An endpoint anti-phishing status does not prove a DMARC, SPF, or DKIM failure. - If no matching official documentation resolves the symptom, use ESET's Technical Support path with the product and exact observed message. > Do not disable phishing-related protection, add exclusions, or apply registry or policy changes from an unrelated product guide. A mismatch can reduce protection without resolving the displayed condition. [Threats and impersonation resources](/learning/threats) can help place the symptom in a broader security review. They do not replace ESET's product documentation for a protection-state warning. ![Decision flow for identifying an ESET anti-phishing protection issue by product, exact symptom, and the appropriate support path](/images/editorial/eset-anti-phishing-protection-is-non-functional/eset-anti-phishing-protection-is-non-functional-decision-flow.webp "1200x829") *Source: Palisade.* ## Worked evidence example Collect a short, factual evidence object before looking for a fix. Do not include account credentials, license keys, private URLs, customer data, or unredacted email contents. ```text ESET product: [exact installed product name] Product version: [version shown by the product] Operating system: [name and version] Where the issue appears: [product window, browser, or endpoint context] Exact status text: "[copy exactly]" When observed: [date and time with time zone] Scope: [one endpoint or multiple endpoints] Recent change: [only if known and documented] ``` This is a diagnostic record, not proof of the cause. It makes it possible to match the issue to the correct ESET documentation and avoid treating a generic phrase as a universal error code. For example, a report with only "non-functional" should stop at identification and evidence capture. A report that adds the exact product name and exact status text can be searched against ESET's documented help content. If the wording appears only after a particular browser action, that context belongs in the support request. If it appears across managed endpoints, document the scope but do not assume the cause is a shared policy until ESET's guidance supports that conclusion. ## What to check next Choose the next action based on the evidence you have. - With the exact ESET status text: search [ESET Help](https://help.eset.com) using the text and product name. Use only a page that names the same product and platform. - With a product name but no clear symptom: capture the product version, operating system, and location where the issue appears. Then search the matching ESET documentation. - With no matching documentation: submit the collected evidence through [ESET Support](https://support.eset.com). Include the observed scope and exact text rather than a paraphrase. - With a separate concern about your domain's email controls: review [email security](/learning) as a distinct control area. Domain authentication helps receivers evaluate mail that uses your domain, while endpoint anti-phishing software addresses a different part of the threat path. You can also use Palisade's [Email Security Score](/tools/email-security-score) to review a domain's public email-security posture. That assessment does not inspect ESET software, browser protection, endpoint configuration, or a device's protection state. ## Review the separate email-security controls If the ESET issue prompted a wider review of phishing defenses, start with the controls that protect your sending domain and mail flow. [Review email security controls](/learning) This guide cannot diagnose, repair, or confirm ESET Anti-Phishing protection. It covers domain-level email-security controls, which need separate evidence and validation. ## Sources and further reading - [ESET Help](https://help.eset.com) - [ESET Support and Knowledgebase](https://support.eset.com) - [Palisade guide to email security](/learning) - [Palisade Email Security Score](/tools/email-security-score) ## Frequently asked questions ### Does this message prove that ESET is blocking phishing protection? No. The phrase alone does not identify the ESET product, the protection component, or the condition behind the status. Use the exact displayed text with the matching product documentation. ### Should I disable ESET Anti-Phishing protection to clear the warning? No. Do not disable a protective control based on a generic warning description. First find the official ESET guidance for the exact product, platform, and status text. ### Can a DMARC record fix ESET Anti-Phishing protection? No. DMARC is a domain-based email authentication policy. It is separate from an ESET endpoint or browser protection state, although both can contribute to a broader phishing-defense program. ### Can an email-security score test ESET protection? No. A public domain assessment can review domain-facing email-security signals. It cannot inspect ESET software installed on an endpoint or confirm that its anti-phishing feature is functional. ### What information should I provide to ESET Support? Provide the exact ESET product name, version, operating system, where the status appears, the exact status text, when it occurred, and whether it affects one endpoint or multiple endpoints. Exclude credentials, license keys, private URLs, and customer data. --- # Generate a DKIM record Canonical: https://www.palisade.email/learning/generate-dkim-record > Generate a DKIM record by creating a key pair in your sending service, then publishing its public key at the selector's DNS name for your domain. Generate a DKIM record by using the system that signs your mail to create a DKIM key pair, then publishing the public key in DNS at the selector name that system supplies. Do not create a generic record by copying another sender's value. The selector, DNS hostname, record type, and public-key value must match the signing service that will add the DKIM-Signature header. ## Quick takeaways - A DKIM record publishes a public key. The corresponding private key stays with the signing system. - The standard DNS lookup name is `<selector>._domainkey.<signing-domain>`. - Your email provider or mail server must supply the real selector and key material. - A TXT record and a CNAME record can both support DKIM, but the provider determines which form to publish. - A public DNS lookup confirms that a record is visible. It does not prove that a production message is being signed. - DKIM is one part of [email authentication](/learning), alongside other controls that a receiver can evaluate. ## How DKIM record generation works [DKIM](https://datatracker.ietf.org/doc/html/rfc6376) lets a signing domain associate a cryptographic signature with a message. The signer holds the private key and places a `DKIM-Signature` header on outgoing mail. A receiving system uses the signature's domain and selector to retrieve the matching public key from DNS. The public-key lookup name combines two values from the sender's configuration: ```text <selector>._domainkey.<signing-domain> ``` For example, if a sending platform assigns selector `selector1` for `yourdomain.com`, the DNS name is: ```text selector1._domainkey.yourdomain.com ``` RFC 6376 defines selectors as a way to support multiple keys for one domain. That lets a domain use separate keys for separate sending systems or replace a key without requiring all existing selectors to disappear at once. The selector is therefore part of the lookup identity, not a label you should guess. A standard DKIM public-key record uses DNS TXT data. The record normally identifies the key type with `k=` and contains the encoded public key in `p=`. RFC 6376 also defines other key-record tags, including `t=` for flags and `s=` for service types. The signer, record, and signature header must agree. ![DKIM record relationship between a sender's private key, selector, DNS public key, and receiving verifier](/images/editorial/generate-dkim-record/generate-dkim-record-key-flow.webp "1200x676") *Source: Palisade.* For a fuller explanation of record lookup and testing, see the [DKIM learning hub](/learning/dkim). ## When the record format changes The safe decision rule is: publish the exact DNS instructions generated by the service that signs the mail. A provider may ask for a TXT record that contains the public key directly. Another provider may ask for a CNAME record that delegates the selector lookup to provider-managed DNS. Both approaches can support DKIM, but they are different DNS configurations. A CNAME is not interchangeable with a TXT record. See [what a DKIM CNAME record is](/learning/dkim-cname) before replacing one record type with the other. The signing domain can also differ from the visible From domain. DKIM permits a signing domain to identify the party taking responsibility for the signed message, while DMARC later evaluates whether the authenticated domain aligns with the visible From domain. Publishing a valid DKIM record alone does not establish that alignment. Use this decision rule: - If the sending service presents a DNS hostname, record type, and value, publish those exact values in the DNS zone for the domain it names. - If the service offers DKIM setup for more than one sending domain, generate and publish the values for each intended domain. Do not reuse a selector target or public key from another account unless the service explicitly generated it for that domain. - If DNS already has the required selector record, compare it with the provider's current instructions before editing. A duplicate or conflicting record can prevent verification. - If the provider says DKIM is enabled but a lookup returns no usable selector record, investigate the missing record with [how to diagnose a missing DKIM record](/learning/no-dkim-record-found). > Do not publish a private key in DNS, support tickets, or a shared document. DNS receives the public key or a provider-directed CNAME only. ## Worked DKIM record shape The following is a structural example, not a record to publish. Your sender generates the real selector and public-key value. ```text Type: TXT Host: selector1._domainkey.yourdomain.com Value: v=DKIM1; k=rsa; p=BASE64_PUBLIC_KEY_FROM_YOUR_SENDING_SERVICE ``` In this example: - `selector1` is the selector chosen or assigned by the signing system. - `_domainkey` is the DKIM DNS namespace defined by the standard. - `yourdomain.com` is the domain named by the signing configuration. - `v=DKIM1` identifies the record as a DKIM key record. - `k=rsa` identifies the key type for this example. - `p=` carries the public key. Replace the placeholder only with the exact public-key value generated for your sender. The value is often long. DNS control panels may display quoted strings or split a long TXT value into segments. Follow the sending provider's published DNS entry instructions, then inspect the record after publication. Do not add spaces or omit characters from the supplied key. A provider that uses CNAME delegation supplies a different shape, such as a selector hostname and a target hostname. It does not supply a universal public-key string for you to paste into a TXT record. If you manage DNS through GoDaddy, the separate guide on [adding a DKIM record in GoDaddy DNS](/learning/add-dkim-record-godaddy) covers that DNS-provider task. ## What to do after generating the record Start with the evidence you have: - If you have not configured a sender yet, open that sender's domain-authentication or DKIM settings and generate its DNS instructions. Keep the selector, type, hostname, and value together. - If you have DNS access, publish the exact provider-generated record, then wait for the provider's own verification status before treating setup as complete. - If you have a delivered test message, inspect its `DKIM-Signature` and receiver-added authentication results. A real message from the production path can show whether that path signed mail and whether the receiving system evaluated the signature. - If you only have a domain and selector, use Palisade's [DKIM checker](/tools/dkim) to look up the public DNS record. A lookup can show whether public DNS returns a record at the name you check. It cannot prove that the sending application uses the matching private key, that every mail stream signs, or that a receiver will make a particular delivery decision. ## Continue with the email authentication checks After a DKIM record is published, confirm that the sending system reports the domain as verified and send a real message through the same production path. Then review the message headers and the domain's broader authentication configuration. [Review the email authentication checklist](/learning) An email-authentication guide and a DKIM lookup cannot repair a sender configuration, prove future messages will authenticate, or control a receiver's final inbox decision. ## Sources and further reading - [RFC 6376: DomainKeys Identified Mail (DKIM) Signatures](https://datatracker.ietf.org/doc/html/rfc6376) - [RFC 8463: A new cryptographic signature method for DKIM](https://datatracker.ietf.org/doc/html/rfc8463) - [Palisade email authentication guide](/learning) ## Frequently asked questions ### Can I generate a DKIM record myself? You can generate the key pair yourself only if you run the mail-signing system and can protect its private key. On a hosted email service, generate DKIM from the provider's domain-authentication settings instead, then publish the DNS values it gives you. Whichever route you take, the system that signs your mail has to hold the private key matching the public key in DNS. ### Is a DKIM record always a TXT record? No, although TXT is the common form, because the standard describes public keys retrieved through DNS without fixing one record type. Some email providers instead ask you to publish CNAME records that point the selector at their own managed key records. Publish whichever form your provider's instructions specify. ### What is a DKIM selector? A DKIM selector is the label that identifies which public key a receiver should look up for a signature. The selector combines with `_domainkey` and the signing domain to form the DNS lookup name. ### Can I use the same DKIM key for every sending service? No, in almost every case, because each service generates its own selector and key pair and keeps its own private key. Copying one provider's record into another provider's setup leaves that stream unsigned or unverifiable. Publish a separate selector record for each service that signs mail for the domain. ### Does a published DKIM record mean DKIM is working? No, because a published record only shows that DNS returns public-key information for the selector you queried. Check the sending provider's own verification status, then inspect a delivered message from the exact production path to confirm it carries a `DKIM-Signature` and that the receiver verified it. --- # Gmail bulk sender guidelines Canonical: https://www.palisade.email/learning/gmail-bulk-sender-guidelines > Gmail bulk sender guidelines: meet Gmail's 5,000-message threshold with SPF, DKIM, DMARC, TLS, alignment, unsubscribe, and validation for senders. Gmail bulk sender guidelines apply when a sender delivers close to 5,000 or more messages to personal Gmail accounts in 24 hours. Configure SPF and DKIM in the platform that sends the mail, publish a DMARC record, use TLS, align the visible From domain with SPF or DKIM, and support one-click unsubscribe for marketing and subscribed mail. Google documents the requirements, but does not provide one universal Admin console setup path because the DNS and sending controls belong to your sending platform and domain. ## Quick takeaways - Google's sender guidelines apply to mail sent to personal Gmail accounts, not mail sent to Google Workspace accounts. - A bulk sender sends close to 5,000 or more messages to personal Gmail accounts in 24 hours, counted by primary domain. - Bulk senders need both SPF and DKIM, plus DMARC. Google's DMARC policy requirement permits `p=none`. - Gmail requires a DKIM key of at least 1024 bits and recommends 2048 bits where the DNS provider supports it. - Keep the daily user-reported spam rate below 0.3%. Google recommends staying below 0.1%. - A passing DNS record or vendor status does not prove that the production message path authenticates and aligns. ## What should I check before configuring Gmail? Start by identifying the exact system that sends the messages. A marketing platform, transactional-email provider, CRM, employee mailbox, and outbound gateway can use different SPF, DKIM, return-path, and TLS configurations. This guide is one provider-specific path within Palisade's [email service provider setup guides](/learning/esp-setup). Google states that its sender requirements apply to personal Gmail accounts, not Google Workspace recipients. A sender becomes a bulk sender when it sends close to 5,000 messages or more to personal Gmail accounts within 24 hours. Messages from the same primary domain count toward that threshold, even when more than one sending service is involved. See Google's [sender-guidelines FAQ](https://support.google.com/mail/answer/14229414). Confirm these items before changing DNS: - The visible From domain for the messages in scope. - The platform that generates the SMTP connection and signs DKIM. - Access to the authoritative DNS zone for the From domain and any return-path domain. - Access to the sending platform's current domain-authentication status. - A test mailbox where you can inspect the raw source of a newly delivered message. - Ownership of the unsubscribe process for marketing and subscribed messages. > Copy DNS values from the account and domain you are configuring. Do not publish selectors, targets, tokens, or hostnames from another account or from an online example. Google's baseline rules require all senders to set up SPF or DKIM, use valid forward and reverse DNS for sending domains or IPs, use TLS, follow RFC 5322 message formatting, avoid impersonating Gmail From headers, and keep Postmaster Tools spam rates below 0.3%. Bulk senders need both SPF and DKIM, DMARC, alignment, and one-click unsubscribe. Google's [Email sender guidelines](https://support.google.com/mail/answer/81126) are the authoritative requirement list. ## Which setup method should I use? Use the authentication workflow in the system that actually sends the messages. Gmail is the receiving service in this workflow. It does not generate your marketing-platform DKIM selector, your transactional provider's return-path target, or your sending IP's PTR record. If a sending platform offers automatic domain authentication, use its account-generated DNS values for the selected domain. If DNS is managed through infrastructure-as-code or a change-control process, export the exact values from the selected platform account and submit them through that workflow. Do not replace a working SPF record when adding another sender. SPF has one effective record per domain, so the platform's required mechanism must be merged into the existing record according to that platform's documentation. Use a dedicated IP only when the sending platform and your operational model require one. A dedicated IP does not remove Gmail's authentication, TLS, alignment, unsubscribe, PTR, or spam-rate requirements. ![Decision flow for selecting the sender platform that owns Gmail bulk sender authentication settings](/images/editorial/gmail-bulk-sender-guidelines/gmail-bulk-sender-guidelines-setup-flow.webp "1200x676") *Source: Palisade.* ![General vendor product overview related to email delivery and security, not a specific Gmail settings screen](/images/editorial/gmail-bulk-sender-guidelines/gmail-bulk-sender-guidelines-shot-1.png "1600x900") *Source: https://documentation.campus.barracuda.com/wiki/rest/api/content/5242894/child/attachment/att5243058/download* ## How do I configure SPF and DKIM for Gmail bulk sending? ### 1. Identify the production sender and visible From domain List each service that sends mail using the domain, then separate marketing, transactional, and mailbox-hosted traffic. For each service, record the visible From domain, envelope sender or return-path domain, DKIM signing domain, selector, sending IP or relay, and test mailbox. Google's bulk-sender rules require the direct-mail From domain to align with either the SPF domain or the DKIM domain. A message can pass SPF or DKIM without producing DMARC alignment if the authenticated domain does not match the visible From domain under the selected alignment mode. ### 2. Open the sending platform's domain-authentication settings Open the selected sender's domain-authentication, sender-domain, or DKIM settings. Google does not document a universal Gmail settings page for publishing another platform's account-generated DNS records. Verify the path from the sending platform's current official documentation or authenticated account before making the change. Select the precise sending domain. Do not assume that an organization domain, subdomain, branded return-path, and visible From domain share the same DNS setup. ### 3. Publish the account-specific SPF and DKIM records Copy the SPF mechanism, DKIM selector, and DKIM value or CNAME target from the sending platform account. The following examples show record structure only. **SPF record type:** `TXT` **SPF host:** `yourdomain.com` **SPF value, illustrative only:** ```text v=spf1 include:spf.example.net -all ``` **DKIM record type:** `TXT` or `CNAME`, as generated by the sending platform **DKIM host, illustrative only:** ```text selector1._domainkey.yourdomain.com ``` **DKIM value, illustrative only:** ```text v=DKIM1; k=rsa; p=example-public-key ``` > Do not publish these examples. Copy the complete SPF and DKIM values generated for the selected account and domain. Account-generated selectors, public keys, and CNAME targets can differ by provider and tenant. Check how the DNS provider handles host names. Some interfaces append `yourdomain.com` automatically. Entering the full owner name into such an interface can create `selector1._domainkey.yourdomain.com.yourdomain.com`. Before saving, inspect existing records. Do not add a second SPF record at the root domain. For DKIM, do not overwrite an active selector without using the provider's rotation process. A CNAME cannot coexist with other record data at the same DNS owner. ### 4. Publish a DMARC record and confirm alignment design Google requires bulk senders to set up DMARC for the sending domain. Google explicitly states that the DMARC enforcement policy can be `none`, so Gmail's bulk-sender requirement does not require immediate `p=quarantine` or `p=reject`. **DMARC record type:** `TXT` **DMARC host:** `_dmarc.yourdomain.com` **DMARC value, illustrative only:** ```text v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com ``` > Do not publish this example unchanged. Use a reporting mailbox your organization controls, and verify that it can receive aggregate reports. Ensure that a real message can produce SPF alignment or DKIM alignment with the visible From domain. Google's [Email sender guidelines](https://support.google.com/mail/answer/81126) require this alignment for direct bulk email. ### 5. Verify in the sending platform and send a real message Return to the sending platform and confirm that it accepts the published records for the selected domain. Then send a new message through the exact production path to a mailbox where raw headers are available. A green platform indicator is useful evidence, but it is not proof that the message was sent through the expected return path, signed with the expected domain, or accepted by Gmail with aligned authentication. ## How does this setup affect DMARC? DMARC evaluates whether SPF or DKIM passes and aligns with the visible From domain. For bulk senders, Google requires both SPF and DKIM to be configured, while direct email needs the From domain aligned with either the SPF domain or DKIM domain. Use Palisade's [DMARC checker](/tools/dmarc) to inspect the published DMARC record before changing policy. A public DNS check can confirm the record that resolves now. It cannot prove the production sending path, Gmail's private spam assessment, future delivery, or whether a particular message aligned. Palisade is agentic DMARC software for teams that need to move beyond a one-time record check. It analyzes DMARC aggregate-report data, identifies sending sources and authentication or alignment issues, and creates prioritized remediation tickets. A human reviews the evidence and applies any DNS or policy change. ![Four-layer validation flow for Gmail bulk sender requirements](/images/editorial/gmail-bulk-sender-guidelines/gmail-bulk-sender-guidelines-validation-flow.webp "1200x524") *Source: Palisade.* ## How do I validate the setup? ### Check public DNS Query the authoritative DNS provider and at least one public resolver for the SPF, DKIM, and DMARC owners. Confirm the final fully qualified owner names and complete values. ```bash dig +short TXT yourdomain.com dig +short TXT selector1._domainkey.yourdomain.com dig +short TXT _dmarc.yourdomain.com ``` Also confirm that each sending IP has forward and reverse DNS consistency. Google documents PTR records as a sender requirement, and its [SMTP error documentation](https://knowledge.workspace.google.com/admin/support/troubleshooting/gmail-smtp-errors-and-codes) identifies missing or mismatched PTR records as a 550 5.7.25 rejection condition. ### Check the sending-platform status Confirm that the platform recognizes the selected domain and that its authentication status is current. Record the selected account, domain, selector, and time of verification. This checks the vendor layer only. It does not confirm that every campaign, relay, or application uses the approved configuration. ### Inspect a delivered message Inspect a newly delivered message from the production path. Confirm the `DKIM-Signature` domain and selector, then inspect the receiver-added `Authentication-Results` field. [RFC 8601](https://datatracker.ietf.org/doc/html/rfc8601) defines this field and explains that recipients must evaluate its trust boundary. Accept the message-path test only when the trusted result shows the expected authentication outcome and either SPF or DKIM aligns with the visible From domain. Keep a redacted header copy with the change record. ### Review DMARC reports After aggregate reports accumulate, review each sending source and its SPF and DKIM alignment results. A successful test message does not inventory every system that uses the domain. ## Troubleshooting ### Gmail returns 550 5.7.26 Google documents this error as: ```text This email has been blocked because the sender is unauthenticated. Gmail requires all senders to authenticate with either SPF or DKIM. ``` Check the message headers for the actual SPF and DKIM results, then compare the sending platform's configured domain with the DNS records that resolve publicly. See Google's [Gmail SMTP errors and codes](https://knowledge.workspace.google.com/admin/support/troubleshooting/gmail-smtp-errors-and-codes). ### Gmail returns 550 5.7.27 or 550 5.7.30 Google documents 550 5.7.27 for SPF failure and 550 5.7.30 for DKIM failure on bulk mail. Check whether the production route uses the return-path and DKIM selector that you configured. A common cause is testing one platform while the live campaign uses another relay or subdomain. ### Gmail returns 550 5.7.29 Google documents this error when a bulk message was not sent over TLS. Check SMTP or relay logs for the negotiated connection and require TLS on the actual delivery path. A DNS checker cannot inspect SMTP transport logs. ### SPF passes but DMARC fails Compare the visible From domain with the SPF-authenticated envelope domain. If they are not aligned, DMARC does not use that SPF pass. Check DKIM alignment as well, then correct the sender-domain or return-path configuration in the platform that sent the message. ### Spam rate approaches 0.3% Google recommends keeping the user-reported spam rate below 0.1% and requires it to remain below 0.3%. The sender-guidelines FAQ states that spam rate is calculated daily and that senders above 0.3% are ineligible for mitigation until rates remain below 0.3% for seven consecutive days. Review consent, list quality, message frequency, and unsubscribe handling before increasing volume. ## Check the DMARC record behind your Gmail bulk-sender setup Check the published DMARC record for the exact From domain before relying on the bulk-sender configuration. Compare the record with the SPF and DKIM domains observed in a newly delivered message, then use aggregate-report evidence to find other production sources that may still fail alignment. [Check the DMARC record](/tools/dmarc) A DMARC record check cannot prove a receiver's private spam decision, inspect SMTP TLS, repair an individual sender configuration, or guarantee future Gmail placement. When you need ongoing evidence across multiple senders or domains, [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=provider_requirements&utm_content=gmail-bulk-sender-guidelines). Signup and trial do not require a credit card. ## Sources and further reading - [Google Email sender guidelines](https://support.google.com/mail/answer/81126) - [Google sender-guidelines FAQ](https://support.google.com/mail/answer/14229414) - [Google Gmail SMTP errors and codes](https://knowledge.workspace.google.com/admin/support/troubleshooting/gmail-smtp-errors-and-codes) - [Google Workspace Gmail sending limits](https://knowledge.workspace.google.com/admin/gmail/gmail-sending-limits-in-google-workspace) - [RFC 8601: Authentication-Results](https://datatracker.ietf.org/doc/html/rfc8601) ## Frequently asked questions ### What is the bulk sending limit for Gmail? A Gmail bulk sender threshold is not a sending cap. Google defines a bulk sender as a sender that delivers close to 5,000 or more messages to personal Gmail accounts in 24 hours, counted by primary domain. Google Workspace Gmail has separate sending limits, including 2,000 messages per day for standard accounts. See Google's [sender-guidelines FAQ](https://support.google.com/mail/answer/14229414) and [Workspace sending limits](https://knowledge.workspace.google.com/admin/gmail/gmail-sending-limits-in-google-workspace). ### How do I send 10,000 emails from Gmail? No, a Gmail or Google Workspace mailbox is not the right sending path for 10,000 messages per day. Google Workspace Gmail documents a 2,000-message daily limit, while personal Gmail documents sending errors above 500 emails in a day. Use a dedicated sending platform, then meet Gmail's bulk-sender requirements for SPF, DKIM, DMARC, alignment, TLS, unsubscribe, and spam rate. See Google's [personal Gmail sending limits](https://support.google.com/mail/answer/22839). ### What is the most hacked email provider? No reliable answer identifies one provider as the "most hacked" without a defined time period, user population, attack type, and comparable primary security data. Provider compromise risk also depends on account security controls, phishing exposure, recovery settings, and administrator practices. Choose providers based on documented security controls and your own threat model rather than an unsupported ranking. ### Can I send 300 emails at once with Gmail? Yes, for Google Workspace Gmail, 300 recipients is within Google's documented per-message limit of 2,000 total recipients, including a maximum of 500 external recipients. Those recipients still count toward daily limits, including 3,000 external recipients per day. Personal Gmail documents an error condition above 500 recipients in one email. See Google's [Workspace sending limits](https://knowledge.workspace.google.com/admin/gmail/gmail-sending-limits-in-google-workspace) and [personal Gmail limits](https://support.google.com/mail/answer/22839). ### Does Gmail require DMARC enforcement for bulk senders? No. Google requires bulk senders to set up DMARC, but its sender guidelines state that the DMARC enforcement policy can be set to `none`. A `p=none` record satisfies that Gmail requirement, though it does not instruct receivers to quarantine or reject failing mail. --- # Gmail one-click unsubscribe requirements Canonical: https://www.palisade.email/learning/gmail-one-click-unsubscribe > Gmail one-click unsubscribe requires bulk senders to add signed headers, an HTTPS POST endpoint, and a visible body link for eligible Gmail messages. Gmail one-click unsubscribe is required for senders that send close to 5,000 messages or more to personal Gmail accounts in a 24-hour period when those messages are marketing or subscribed messages. Since February 1, 2024, eligible mail needs RFC 8058 one-click headers, DKIM coverage for those headers, an HTTPS endpoint that accepts the unsubscribe POST, and a clearly visible unsubscribe link in the message body. It is one part of Gmail deliverability expectations, alongside authentication requirements. ## Quick takeaways - Gmail applies this bulk-sender requirement to personal Gmail accounts, not Google Workspace accounts. - Google says marketing and subscribed messages from affected senders must support one-click unsubscribe and include a visible body link. - RFC 8058 requires both `List-Unsubscribe` and `List-Unsubscribe-Post` for one-click behavior. - A valid DKIM signature must cover both one-click headers in its `h=` tag. - The unsubscribe endpoint must accept an HTTPS POST without cookies, HTTP authorization, or redirects. - Gmail began ramping up enforcement on non-compliant traffic in November 2025. ## Who is affected? Google defines a bulk sender as a sender that sends close to 5,000 messages or more to personal Gmail accounts within 24 hours. Messages from the same primary domain count toward that limit, according to [Google's bulk-sender FAQ](https://support.google.com/mail/answer/14229414). For that sender tier, [Gmail's email sender guidelines](https://support.google.com/mail/answer/81126) say that marketing messages and subscribed messages must support one-click unsubscribe and include a clearly visible unsubscribe link in the message body. The header-based action and the visible body link are separate requirements. A `List-Unsubscribe` header does not replace the visible link. Google also states that its email sender guidelines and enforcement apply only to mail sent to personal Gmail accounts. They do not apply to messages sent to Google Workspace accounts. Google identifies the included categories as marketing messages and subscribed messages, but the cited guidance does not publish a complete list of other message categories that are excluded. Do not assume a message is outside scope without checking its purpose and the current Google guidance. One-click unsubscribe is distinct from Gmail authentication. A message can have valid SPF, DKIM, and DMARC results yet still lack the required unsubscribe mechanism. Review [how to authenticate email for Gmail](/learning/authenticate-email-for-gmail) separately when the sending domain also needs authentication work. ## What are the requirements? ### The message includes the RFC 8058 header pair RFC 2369 defines `List-Unsubscribe` as a header field containing one or more angle-bracket-enclosed URLs for list commands. RFC 8058 adds the fixed `List-Unsubscribe-Post` value that tells a receiver it can perform a one-click unsubscribe action. [RFC 8058](https://www.rfc-editor.org/rfc/rfc8058.txt), a Standards Track RFC published in January 2017, requires the `List-Unsubscribe` header to contain one HTTPS URI. Its Section 5 defines the one-click header value as a fixed value, not a free-text field. ```text List-Unsubscribe: <https://example.com/unsubscribe/opaquepart> List-Unsubscribe-Post: List-Unsubscribe=One-Click ``` The HTTPS URI should contain an opaque or hard-to-forge identifier rather than a plain recipient address or list name. RFC 8058 does not prescribe the token format. The sender remains responsible for making it difficult to guess and limiting it to the intended unsubscribe operation. ![Checklist of Gmail one-click unsubscribe requirements: signed headers, HTTPS POST endpoint, no redirect, and visible body link](/images/editorial/gmail-one-click-unsubscribe/gmail-one-click-unsubscribe-requirements-checklist.webp "1200x582") *Source: Palisade.* A `mailto:` link can still appear as an additional RFC 2369 list command, but it does not provide RFC 8058 one-click behavior. For the protocol-level distinction, see [one-click unsubscribe and the RFC 8058 header pair](/learning/one-click-unsubscribe). ### Both headers are covered by a valid DKIM signature RFC 8058 requires at least one valid DKIM signature on the message. The `List-Unsubscribe` and `List-Unsubscribe-Post` headers MUST be covered by that signature and included in the DKIM-Signature header's `h=` tag. ```text DKIM-Signature: v=1; a=rsa-sha256; d=yourdomain.com; h=from:to:subject:list-unsubscribe:list-unsubscribe-post; ... ``` This is an illustrative header shape only. Inspect the raw headers of a delivered message to confirm the actual production signature covers both fields. A platform status that says DKIM is enabled does not prove that its signing configuration includes these two headers. ![HTTPS one-click unsubscribe flow from receiver consent to the sender endpoint](/images/editorial/gmail-one-click-unsubscribe/gmail-one-click-unsubscribe-endpoint-flow.webp "1200x522") *Source: Palisade.* ### The endpoint completes an HTTPS POST without session context RFC 8058 says a receiving system can perform an HTTPS POST to the URI in `List-Unsubscribe` and send the key and value from `List-Unsubscribe-Post` as the request body. Google publishes this example request shape in its sender guidelines: ```text POST /unsubscribe/example HTTP/1.1 Host: solarmora.com Content-Type: application/x-www-form-urlencoded Content-Length: 26 List-Unsubscribe=One-Click ``` RFC 8058 says the receiver SHOULD send `multipart/form-data` and MAY send `application/x-www-form-urlencoded`. An interoperable endpoint accepts both permitted encodings. The endpoint cannot depend on browser state. RFC 8058 says the POST request MUST NOT include cookies, HTTP authorization, or other context information. The sender MUST NOT return an HTTPS redirect because redirected POST actions have not worked reliably. A preference center, login flow, or confirmation page may be appropriate for a body link, but it cannot be required to complete the RFC 8058 transaction. The receiver also MUST NOT make the POST without user consent. The mailbox provider obtains that consent through its own interface. RFC 8058 does not require Gmail to display a particular control in every client or for every message. ### The message body includes a visible unsubscribe link Google's requirement includes a clearly visible unsubscribe link in the message body in addition to one-click support. That link gives the recipient a direct, human-operated way to unsubscribe or manage preferences. The visible link may lead to a broader subscription-management experience. The RFC 8058 endpoint has a narrower job: it must process the one-click POST without a web session or redirect. Keep these paths separate when testing. A working body link does not establish that a background POST can complete, and a working endpoint does not establish that the body link is visible in the delivered template. ## When does the requirement take effect? Google states that, starting February 1, 2024, all senders to Gmail accounts must meet the requirements in its sender-guidelines section. The one-click unsubscribe requirement appears in the tier for senders of close to 5,000 messages or more to personal Gmail accounts in a 24-hour period. The current enforcement notice in [Google's bulk-sender FAQ](https://support.google.com/mail/answer/14229414) says Gmail began ramping up enforcement on non-compliant traffic in November 2025. Google says affected messages can experience disruptions, including temporary and permanent rejections. This is provider enforcement, not a change to RFC 8058 itself. RFC 8058 remains the controlling one-click protocol standard. It builds on RFC 2369's older `List-Unsubscribe` URL syntax. RFC 2369 alone describes list-command links. RFC 8058 adds the signed header signal and constrained POST flow that make the action one-click. ## How do I implement the requirement? ### 1. Identify eligible Gmail-bound campaign traffic Measure messages sent to personal Gmail accounts by primary domain over a 24-hour period. Identify marketing and subscribed message streams that fall under Google's bulk-sender requirement. Do not combine Google Workspace mailbox traffic with personal Gmail traffic when assessing this scope. Keep the recipient classification and sending-domain evidence available for review. ### 2. Generate an opaque HTTPS unsubscribe URI Create a recipient-specific, hard-to-forge URI for the HTTPS endpoint. The endpoint needs enough information to identify the applicable subscription without asking the receiver to sign in, accept cookies, or submit another form. > Do not use a raw recipient address or reusable account identifier in the unsubscribe URI. Treat the URI as sensitive operational data and avoid exposing full values in routine logs or support tickets. ### 3. Add the headers before DKIM signing Add `List-Unsubscribe` with the HTTPS URI and `List-Unsubscribe-Post: List-Unsubscribe=One-Click` to the message before its DKIM signature is generated. Inspect the generated DKIM-Signature header to confirm its `h=` list includes both one-click header names. If another mail relay modifies or adds headers after signing, test the message after the final production sending path. ### 4. Accept the one-click POST directly Configure the endpoint to accept the exact `List-Unsubscribe=One-Click` body with either permitted form encoding. Process a valid request without a redirect, cookie, authorization challenge, or browser JavaScript. Make repeated valid requests safe to handle. The recipient should remain unsubscribed after the first successful request, rather than creating a second removal event or an error that obscures the result. ### 5. Keep the visible body link in the template Place a clearly visible unsubscribe link in the message body for every applicable template. Check the rendered message, not only the template editor, because layout or content conditions can hide a link in a specific campaign. For platform-specific implementation considerations, see [Mailchimp one-click unsubscribe: headers, body links, and validation](/learning/mailchimp-one-click-unsubscribe). ## How do I validate compliance? Validate the requirement at the message and endpoint layers. Send a controlled message through the exact production path to a test mailbox. In the delivered raw headers, confirm that `List-Unsubscribe` contains an HTTPS URI, `List-Unsubscribe-Post` contains the exact fixed value, and a valid DKIM signature includes both header fields in its `h=` list. Then test the endpoint with a safe test recipient. Send the fixed POST using both `multipart/form-data` and `application/x-www-form-urlencoded`. Confirm that the endpoint completes the suppression action without a cookie, login, authorization header, redirect, or browser-only dependency. Check the rendered body for the visible unsubscribe link. Finally, verify the recipient's suppression status in the source-of-truth list system and ensure another applicable send does not include that recipient. A public posture check such as the [email security score](/tools/email-security-score) can help inspect broader email-authentication configuration. It does not prove that an unsubscribe endpoint accepts the POST, that the DKIM `h=` list covers the headers, or that Gmail will make a particular receiver-side enforcement decision. ## Check the current Gmail sender rules The protocol check above establishes whether a message and endpoint follow RFC 8058. Google's sender guidance determines the affected Gmail traffic and its enforcement posture. [Review Gmail's current email sender guidelines](https://support.google.com/mail/answer/81126) Google's public guidance cannot prove that every production template has the correct headers or that a particular recipient interface will display an unsubscribe control. Validate with a delivered message and a safe endpoint test. ## Sources and further reading - [RFC 8058: Signaling One-Click Functionality for List Email Headers](https://www.rfc-editor.org/rfc/rfc8058.txt) - [Gmail email sender guidelines](https://support.google.com/mail/answer/81126) - [Google bulk-sender FAQ](https://support.google.com/mail/answer/14229414) - [RFC 2369: The Use of URLs as Meta-Syntax for Core Mail List Commands](https://www.rfc-editor.org/rfc/rfc2369.txt) ## Frequently asked questions ### Is one-click unsubscribe mandatory? Yes, conditionally. Google requires it for senders that send close to 5,000 messages or more to personal Gmail accounts in a 24-hour period when the messages are marketing or subscribed messages. The requirement has applied since February 1, 2024, and Google says it does not apply to Google Workspace accounts. ### What happened to one-click unsubscribe? It became part of Gmail's bulk-sender requirements on February 1, 2024. Google says it began ramping up enforcement on non-compliant traffic in November 2025, and affected mail can experience temporary or permanent rejections. ### How do I unsubscribe in one-click? The mail receiver performs the HTTPS POST after the recipient gives consent through the receiver's interface. The recipient does not need to visit the sender's unsubscribe URL in a browser for the RFC 8058 transaction to occur. ### How does one-click unsubscribe work? The sender adds an HTTPS `List-Unsubscribe` URI and `List-Unsubscribe-Post: List-Unsubscribe=One-Click`, then covers both headers with a valid DKIM signature. After user consent, the receiver sends `List-Unsubscribe=One-Click` in an HTTPS POST, and the sender processes it without requiring cookies, authentication, or a redirect. ### Does a visible unsubscribe link replace the RFC 8058 headers? No. Google's guidance requires both one-click unsubscribe support and a clearly visible unsubscribe link in the message body for eligible marketing and subscribed messages. A body link alone does not create the signed, receiver-initiated POST flow defined by RFC 8058. --- # Gmail phishing protection Canonical: https://www.palisade.email/learning/gmail-phishing-protection > Gmail phishing protection combines Gmail warnings with careful verification and reporting. Learn what to check before you click or respond today. Gmail phishing protection combines Gmail's detection and warning features with careful user verification and reporting. Google says Gmail can identify phishing emails and may show warnings or move suspicious messages to Spam, but a warning is not the only signal to use. Treat unexpected requests for passwords, money, personal information, links, or downloads as a reason to stop and verify the request through a trusted channel. [Google's Gmail phishing guidance](https://support.google.com/mail/answer/8253?hl=en) also states that Gmail will not ask for your password over email. ## Quick takeaways - Gmail may warn about suspicious messages or move them to Spam, but users still need to assess unexpected requests. - A message can impersonate a known organization or a person you trust. - Check the sender address, link destination, and message authentication details before acting on a suspicious email. - Do not enter a Google Account password after following a link in an email. - On Gmail for computers, the phishing-report action is in the message's More menu beside Reply. - Unfamiliar account activity or Gmail setting changes can indicate that someone else may have access to a Google Account. ## How Gmail phishing protection works [Google's phishing guidance for Gmail](https://support.google.com/mail/answer/8253?hl=en) describes two parts of phishing protection: Gmail can identify phishing emails and display warnings, while recipients should avoid interacting with suspicious requests. A message may look like it comes from a bank, workplace, social platform, friend, or another familiar source. Visual familiarity alone does not establish that the sender or request is legitimate. Google advises recipients to examine whether the sender name and email address match, whether the message is authenticated, and whether a link's actual URL matches the destination described in the message. On a computer, hovering over a link before clicking can expose a mismatch between visible link text and its destination. Gmail can also show a warning when a message that looks like a scam comes from an address in your contacts. [Google's scam-warning documentation](https://support.google.com/mail/answer/1074268?hl=en) says the safe response is to avoid replying or clicking links, report the suspicious message, and contact the apparent sender through a normal, separate channel. For a broader explanation of the threat category, see [Palisade's email-threat learning hub](/learning/threats). For teams comparing business controls beyond one inbox, [anti-phishing software](/learning/anti-phishing-software) covers the evaluation problem separately. ## When the answer changes A Gmail warning, an unexpected request, and an unfamiliar account event call for different actions. Use the evidence you have rather than assuming that every suspicious-looking message means the account itself has been compromised. - If Gmail displays a warning or the message requests private information, do not reply, download attachments, open links, or enter credentials. Verify the request directly with the organization or person using contact information you already trust. - If the message is from a known contact but asks for money, credentials, or an unusual action, contact that person outside the suspicious email. Their account may have been used without permission. - If you receive a Google security notification, do not rely on the email link to investigate it. [Google's account-security guidance](https://support.google.com/accounts/answer/6063333?hl=en-EN) directs users to review recent security events for unfamiliar locations or devices. - If you find unfamiliar sign-ins, devices, or changes to Gmail settings such as forwarding or mail delegation, [Google's compromised-account guidance](https://support.google.com/accounts/answer/6294825?hl=en-EN) says someone else may be using the account. Secure the account through Google Account security settings. A legitimate email can still be unexpected, and a familiar-looking email can be deceptive. The decision should turn on independent verification, not tone, branding, or urgency. ## A practical decision rule for a suspicious Gmail message Use this decision rule before interacting with a message that requests a login, payment, attachment download, or sensitive information. ```text Illustrative only: Gmail warning shown? Yes: Do not click, reply, download, or provide information. Report the message. No warning, but the request is unexpected or urgent? Yes: Check the full sender address and hover over links on a computer. Verify the request through a known website, phone number, or separate message. Unfamiliar account activity or Gmail setting changes? Yes: Review Google Account security events and secure the account. No suspicious signals found? Confirm the request through the normal business or personal contact path before acting. ``` ![Decision flow for handling a suspicious Gmail message, from a Gmail warning or unexpected request to reporting, independent verification, or account review](/images/editorial/gmail-phishing-protection/gmail-phishing-protection-decision-rule.webp "1200x829") *Source: Palisade.* This rule separates two questions that are easy to merge: whether the email should be reported, and whether the Google Account may have been accessed. Reporting a suspicious message helps Gmail review it. It does not, by itself, prove who sent it or secure an account that has already been accessed. Messages in Spam can also contain useful context. [Gmail's spam guidance](https://support.google.com/mail/answer/1366858?co=GENIE.Platform%3DDesktop&hl=en&oco=0&vid=0-445826934509-1551579340501) explains that Gmail may label a message as a phishing scam, a spoofed address, or a message from an unconfirmed sender. Those labels are a reason to pause. They do not replace verification of a business request through a trusted route. ## What to do with the evidence you have If the email is suspicious, preserve the message until you have reported it or your security team has reviewed it. Do not forward a suspicious link as part of a casual verification request. Instead, contact the purported sender through a phone number, website, or conversation you already know is legitimate. On a computer, Gmail's documented reporting path is to open the message, select More beside Reply, then choose **Report phishing**. Google says a manually reported message is sent to Google for review. The control's location and availability can differ by client, so use [Google's current Gmail reporting instructions](https://support.google.com/mail/answer/8253?hl=en) for the interface you are using. The [Gmail report phishing guide](/learning/gmail-report-phishing) explains evidence preservation, the spam distinction, and what the mailbox action does not resolve. If the concern is account access rather than one message, review recent security events and devices in the Google Account security area. Google also provides [Gmail last-account-activity information](https://support.google.com/mail/answer/45938?hl=en) that can show access types, IP addresses, and approximate locations. Multiple locations do not automatically mean compromise because mobile carriers, POP or IMAP clients, and Google services can affect what appears there. For a wider review of email risks, controls, and organizational responsibilities, read [Palisade's email security guide](/learning). A public [email security score check](/tools/email-security-score) can support an initial domain review when you administer the domain. It cannot prove why Gmail treated an individual message as suspicious, show every production sending path, or establish future inbox placement. ## Review phishing protection beyond one Gmail inbox A reported message and an account-security review address the immediate evidence. If you need to assess email-security responsibilities across a domain or team, use the broader [email security guide](/learning) to identify the controls and operating checks that belong outside an individual Gmail message. That guide does not determine whether a specific Gmail email is safe, explain a private Gmail decision, or repair a compromised Google Account. Those outcomes depend on the message evidence and Google Account security review. ## Sources and further reading - [Google Gmail Help: Avoid and report phishing emails](https://support.google.com/mail/answer/8253?hl=en) - [Google Gmail Help: "This message could be a scam" warning](https://support.google.com/mail/answer/1074268?hl=en) - [Google Account Help: Secure a hacked or compromised Google Account](https://support.google.com/accounts/answer/6294825?hl=en-EN) - [Google Gmail Help: Last account activity](https://support.google.com/mail/answer/45938?hl=en) - [Palisade email security guide](/learning) ## Frequently asked questions ### How do I report phishing emails to Gmail? On a computer, open the suspicious message in Gmail, select More beside Reply, then select **Report phishing**. [Google's Gmail Help instructions](https://support.google.com/mail/answer/8253?hl=en) document that reporting path and state that Google receives the report for review. ### What are the signs that your Gmail is hacked? Google identifies unfamiliar security events, devices, and changes to security settings as possible signs that someone else is using the account. Unfamiliar Gmail settings, including forwarding, mail delegation, outgoing address, blocked addresses, or vacation responder changes, also need review. [Google's compromised-account guidance](https://support.google.com/accounts/answer/6294825?hl=en-EN) lists the current account checks and recovery actions. ### What does a Gmail phishing email look like? A Gmail phishing email may imitate an organization or known person, ask for personal or financial information, request that you click a link or download software, or create urgency. [Google's Gmail phishing guidance](https://support.google.com/mail/answer/8253?hl=en) recommends checking the sender address, authentication, and the real destination of links before acting. ### Where is the phishing button on Gmail? On Gmail for computers, the documented phishing-report control is in the More menu beside Reply after opening the message. [Google's reporting instructions](https://support.google.com/mail/answer/8253?hl=en) are the current reference for the Gmail interface and supported workflow. ### Does reporting a phishing email mean my Google Account is compromised? No. Reporting means the message appears suspicious and should be reviewed by Gmail. Review Google Account security events and devices separately if you see unfamiliar activity, security alerts, or Gmail setting changes. --- # GoHighLevel email warmup: how the fixed-stage model works Canonical: https://www.palisade.email/learning/gohighlevel-email-warmup > GoHighLevel email warmup uses fixed sending stages for eligible LC Email dedicated domains. Learn what it controls and how to validate mail. GoHighLevel email warmup is HighLevel's fixed-stage sending model for eligible verified dedicated domains using LC Email. It controls the documented daily sending capacity as a domain progresses through warmup stages. It does not authenticate mail, prove that a message reaches the inbox, or override a receiving provider's filtering decisions. Use it alongside a dedicated, authenticated sending domain and evidence from real delivered messages. ## Quick takeaways - GoHighLevel's domain warmup feature applies to eligible dedicated domains configured for LC Email. - Newly created and verified eligible domains can begin the documented warmup process automatically. - Existing eligible domains can be started through HighLevel's documented agency or sub-account settings paths. - A warmup stage is a sending-capacity control, not an inbox-placement guarantee. - Authentication, consent, recipient engagement, and receiver policy still affect delivery. - A real production message and its authentication results provide evidence that DNS alone cannot. ## How GoHighLevel email warmup works [HighLevel's Domain Warmup fixed-stage documentation](https://help.gohighlevel.com/support/solutions/articles/155000005242-domain-warmup-how-it-works-fixed-stage-model-) describes a model that increases an eligible domain's daily sending limits through fixed stages. HighLevel documents the feature for LC Email dedicated domains, rather than for every possible sending connection in an account. The practical purpose is controlled volume growth for a new sending domain. A domain should still send wanted mail to recipients who opted in and engage with it. [HighLevel's Email Sending Guide](https://help.gohighlevel.com/support/solutions/articles/155000001021-email-sending-guide-email-best-practices-email-warm-up) identifies consent, audience quality, authentication, and consistent sending practices as part of responsible sending. A warmup stage does not change the evidence receivers use to assess an individual message. Google, for example, separately requires applicable senders to meet its [email sender guidelines](https://support.google.com/mail/answer/81126), including authentication requirements for higher-volume senders. Receiving providers can also apply their own spam filtering and local policy. For the broader protocol and operational context, see [what email deliverability is](/email-deliverability) and [whether email warmup works](/learning/does-email-warmup-work). ## When GoHighLevel email warmup applies The answer changes based on the mail connection and domain type. - If the account sends through LC Email using an eligible verified dedicated domain, HighLevel documents fixed-stage domain warmup and paths to start it. - If the account uses a Custom SMTP provider, HighLevel's sending guide says the LC Email warmup model does not govern that provider's sending behavior. Check the SMTP provider's own controls and requirements instead. - If the domain is not yet verified or is not a dedicated domain, resolve that configuration first. A warmup setting cannot substitute for a working domain setup. - If the issue is a specific delivered message, inspect its headers. A domain's warmup state does not show whether SPF, DKIM, or DMARC passed for that message. Use this decision rule: start or confirm warmup only when the sending path is LC Email and the dedicated domain is eligible. Then validate authentication and recipient outcomes separately on the actual production path. > Do not raise sending volume beyond the documented stage because a domain has a green configuration state. A platform setting does not prove that recipients expect the mail or that a receiving provider will place it in the inbox. ![Decision flow separating HighLevel LC Email domain warmup eligibility from authentication and real-message delivery evidence](/images/editorial/gohighlevel-email-warmup/gohighlevel-email-warmup-warmup-boundary.webp "1200x906") *Source: Palisade.* ## A worked GoHighLevel email warmup example Assume `yourdomain.com` is a newly verified dedicated domain used only for LC Email. HighLevel's documented model can place that eligible domain into its fixed warmup stages. The operational evidence should remain separate: ```text Sending path: LC Email Dedicated domain: yourdomain.com Domain state: verified and eligible for HighLevel domain warmup Warmup action: start or confirm the documented fixed-stage state Message evidence: send a normal production message to a controlled recipient Header evidence: inspect SPF, DKIM, and DMARC results for yourdomain.com Recipient outcome: review the receiving mailbox and any provider feedback separately ``` The first four lines describe the platform configuration. They do not establish that a recipient received the message, that the visible From domain aligned with SPF or DKIM, or that the message avoided spam filtering. For a delivered test message, open the raw headers and find the receiving system's `Authentication-Results` field. [RFC 8601](https://datatracker.ietf.org/doc/html/rfc8601) defines this header field for recording a message authentication assessment. An SPF or DKIM pass is useful for DMARC only when the authenticated domain aligns with the visible From domain. If you have a raw message, use the [email header analyzer](/tools/email-header-analyzer) to inspect the authentication evidence. It can help read a supplied header, but it cannot enable HighLevel warmup, prove ongoing domain state, or explain every recipient's placement decision. ## What to do next with the evidence you have If you are setting up a new LC Email dedicated domain, verify the domain first and follow HighLevel's current documented settings path for the account type: - At the agency level, HighLevel documents the path through Agency Settings, Email Services, SMTP Service, Dedicated Domain and IP, then the selected domain and `Start Warmup`. - At the sub-account level, use the current sub-account path described in [HighLevel's fixed-stage warmup guide](https://help.gohighlevel.com/support/solutions/articles/155000005242-domain-warmup-how-it-works-fixed-stage-model-). Interface labels can change, so follow the guide's current labels rather than relying on an older walkthrough. - If the domain sends through Custom SMTP, confirm the provider and domain configuration with that provider. Do not assume HighLevel's LC Email stages apply. After configuration, send a normal message through the same production route your contacts will receive. Check the message headers at the receiving mailbox. Then review DMARC aggregate reports after they accumulate, because a delivered test message is one point in time and does not inventory every application that may send as the domain. For broader security posture on the published domain, run the [email security score](/tools/email-security-score). It can inspect public DNS signals such as authentication records. A public score cannot verify the HighLevel sending path, monitor warmup stages, or predict a receiver's future inbox decision. ## Sources and further reading - [HighLevel Domain Warmup: Fixed-Stage Model](https://help.gohighlevel.com/support/solutions/articles/155000005242-domain-warmup-how-it-works-fixed-stage-model-) - [HighLevel Email Sending Guide](https://help.gohighlevel.com/support/solutions/articles/155000001021-email-sending-guide-email-best-practices-email-warm-up) - [Google email sender guidelines](https://support.google.com/mail/answer/81126) - [RFC 8601: Message Header Field for Indicating Message Authentication Status](https://datatracker.ietf.org/doc/html/rfc8601) - [Palisade email security score](/tools/email-security-score) ## Frequently asked questions ### Does GoHighLevel have email warmup? Yes, HighLevel documents a fixed-stage domain warmup model for eligible verified dedicated domains that send through LC Email. It raises the domain's daily sending limits in set stages. It does not cover Custom SMTP connections, so check that provider's own controls if your account sends that way. ### What is the best email warm up tool? The best warm-up control is the one built into the platform that actually sends your mail, because it is the only one that governs your real sending limits. For LC Email on an eligible dedicated domain, that is HighLevel's own fixed-stage warmup. Whichever you use, validate a real production message, its authentication results, your consent practices, and recipient response separately. ### How do I set up email on GoHighLevel? Set up the sending connection that matches your account, then configure and verify a dedicated domain when using LC Email. Follow [HighLevel's Email Sending Guide](https://help.gohighlevel.com/support/solutions/articles/155000001021-email-sending-guide-email-best-practices-email-warm-up) for the current configuration requirements. If the domain is eligible for LC Email warmup, use the documented domain settings path to confirm or start it. ### Does warmup make GoHighLevel emails land in the inbox? No, warmup does not decide where your mail lands, because it only controls how much an eligible domain may send at each stage. Inbox placement also depends on authentication, sender reputation, recipient engagement, message content, complaint signals, and each receiver's own filtering. Warmup keeps volume sensible while those other signals build. --- # Google email warmup: what it is and what Google does not define Canonical: https://www.palisade.email/learning/google-email-warmup > Google email warmup is an industry practice, not a Google-published process. Separate vendor claims from authentication and deliverability checks. Google email warmup usually means gradually establishing a new sending mailbox's activity before using it for larger campaigns. It is an industry practice promoted by warmup vendors, not a Google Workspace process defined in the available Google material. Google Workspace provides Gmail and custom business email, but its public product page does not prescribe a warmup schedule, duration, volume, or tool. Check authentication and delivery evidence separately before treating warmup activity as meaningful. ## Quick takeaways - Google Workspace includes Gmail and custom business email for an organization's domain. - The available Google Workspace material does not define a Gmail or Google Workspace warmup procedure. - Warmup providers describe automated message exchanges, opens, replies, and gradual ramps as features of their own products. - Vendor claims do not prove that Google rewards warmup-network engagement or that inbox placement will improve. - SPF, DKIM, and DMARC need their own technical checks because a warmup service cannot establish that messages authenticate correctly. - A public diagnostic can inspect current DNS-related security posture, but it cannot predict Gmail placement. ## How Google email warmup works in practice [Google Workspace describes Gmail as custom business email](https://workspace.google.com/), including addresses such as `you@your-company.com`. That confirms the product context, but it does not create a Google-defined warmup workflow. In industry usage, a warmup service connects to a mailbox and creates controlled email activity. For example, [Mailwarm describes automated warm-up emails](https://mailwarm.com/) that are opened, marked important, and replied to. [Warmup Inbox says its service can connect an inbox through OAuth into Gmail, Outlook, or SMTP](https://warmupinbox.com/), then exchange automated messages through its network. These are vendor descriptions of their services. The missing link is important: those product descriptions do not establish that Gmail treats the generated activity as a positive reputation signal. They also do not prove that a mailbox will reach an inbox, remain out of spam, or perform well after the service stops. Email delivery has more than one input. A legitimate business message still needs valid authentication, a sending path that uses the intended domain, and evidence from real delivered mail. See [email deliverability](/email-deliverability) for the broader distinction between successful delivery and inbox placement. ![Decision flow separating Google email warmup vendor claims from technical authentication checks and real delivered-message evidence](/images/editorial/google-email-warmup/google-email-warmup-decision-rule.webp "1200x676") *Source: Palisade.* ## When the answer changes The answer changes based on the question being asked. If the question is, "What warmup volume does Google require?", there is no supported answer in the available Google Workspace material. Do not substitute a vendor's suggested schedule for a Google requirement. If the question is, "Can a warmup service send automated messages through a connected inbox?", some vendors say yes. Mailwarm describes automated warm-up emails and engagement actions. Warmup Inbox recommends a gradual ramp and states that its own full ramp takes 14 to 21 days minimum. That is a vendor recommendation, not a verified Google rule. If the question is, "Does this domain technically authenticate?", warmup activity is the wrong evidence. Authentication requires DNS and message-level checks. [AI email warmup](/learning/ai-email-warmup) has the same boundary: automation can describe or create activity, but it cannot prove a receiver's private inbox decision. Use this decision rule: - If you need to know what Google requires, rely on current Google documentation that states the requirement. - If you need to assess a vendor's warmup feature, read that vendor's current product terms and setup guidance. - If you need to assess your domain's sending posture, inspect SPF, DKIM, DMARC, and a real delivered message from the production path. - If you need to know why Gmail placed one message in spam or inbox, use message evidence and the relevant Google account or administrator signals. A warmup dashboard cannot establish that cause. ## A worked example: what a warmup claim can and cannot show Consider a new Google Workspace mailbox that will send legitimate business mail from `yourdomain.com`. ```text Mailbox: sales@yourdomain.com Vendor claim: Automated warm-up emails are exchanged and receive opens or replies. Technical evidence still needed: - SPF or DKIM pass for a real message from sales@yourdomain.com - Alignment with the visible From domain, yourdomain.com - A valid DMARC policy record for yourdomain.com - Delivery and placement evidence from the actual production sending path ``` The first line describes the mailbox. The vendor claim describes what the service says it does. Neither establishes the four technical results beneath it. A real production validation has separate layers: - DNS: confirm the published authentication records through authoritative DNS and at least one public resolver. - Vendor: confirm the sending application reports that its domain authentication setup is complete. - Message: send a real message through the same application and inspect its authentication results. - DMARC: review aggregate-report data after reports accumulate to identify sources and alignment issues. A delivered message can contain `Authentication-Results` fields that report authentication evaluation. [RFC 8601 defines the Authentication-Results header field](https://datatracker.ietf.org/doc/html/rfc8601), including results for methods such as SPF and DKIM. A passing result supports an authentication finding for that message. It does not guarantee future Gmail inbox placement. For a warmup product that advertises a free feature, keep the claim narrow. [Woodpecker advertises "Free warm-up" and says it "Automatically builds your sender reputation"](https://woodpecker.co/). The available material does not establish feature eligibility, limits, setup requirements, or an independently verified reputation outcome. ## Check the sending domain before relying on warmup Start with the evidence you control. Check the domain's published email-security posture, then compare it with a real message sent by the application that will handle production mail. The [Palisade Email Security Score](/tools/email-security-score) can inspect public DNS-related signals for a domain. For a broader operating view, use the [email deliverability hub](/email-deliverability). A good score or a published record is only a starting point. It does not prove the connected Google Workspace mailbox is using the intended DKIM signing path, that every sender aligns, or that Gmail will place a future message in the inbox. If aggregate reports reveal unknown senders, authentication failures, or alignment issues across domains, Palisade is agentic DMARC software that analyzes DMARC aggregate-report data, identifies sending sources and issues, and creates prioritized remediation tickets. It can propose a next policy step when the evidence supports it, while your team reviews the evidence and applies any DNS change. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=email_deliverability&utm_content=google-email-warmup) Palisade does not control Gmail's private placement decisions, guarantee delivery, or prove that every future message will authenticate. ## Sources and further reading - [Google Workspace and Gmail custom business email](https://workspace.google.com/) - [Mailwarm product page](https://mailwarm.com/) - [Warmup Inbox product page](https://warmupinbox.com/) - [Woodpecker warm-up feature](https://woodpecker.co/) - [RFC 8601: Authentication-Results header field](https://datatracker.ietf.org/doc/html/rfc8601) - [Palisade Email Security Score](/tools/email-security-score) ## Frequently asked questions ### How do I warm up a Gmail account? Start by confirming the domain authenticates, because Google does not publish a warmup procedure for Gmail or Google Workspace. Check that SPF and DKIM pass and align for the address you will send from, then send real mail through the production path and read the headers. Warmup vendors will hand you a schedule, but that schedule is theirs, not Google's. ### Does email warm up actually work? Vendors say it does, but Google publishes no rule that rewards warmup activity, so nobody can show the practice itself improves Gmail placement. Mailwarm, Warmup Inbox, and Woodpecker each describe automated exchanges, opens, and replies inside their own networks. That activity is not evidence that Gmail reads it as a positive signal for your mailbox. ### How can I warm up email for free? Woodpecker advertises a free warm-up feature, which is the only free option named on this page. It does not publish the eligibility rules, limits, setup steps, or whether the feature stays free after a trial, so read its current terms before you connect a mailbox. Raising your own sending volume gradually costs nothing and needs no tool at all. ### What is the best email warm up tool? There is no best one, because no independent comparison of these products exists and none of them control Gmail's placement decision. Mailwarm, Warmup Inbox, and Woodpecker each describe their own features, which tells you what they do but not how they rank against each other. Choose on the connection method they document, the access they need, and what you can verify from your own delivered mail. ### Does a warmup service fix SPF, DKIM, or DMARC? No, because those are DNS and message-level settings that a warmup service never touches. Its message activity cannot make an SPF or DKIM result align with your visible From domain, and it cannot publish a DMARC record for you. Check those separately with a DNS lookup and the headers of a real delivered message. --- # Google one-click unsubscribe requirements Canonical: https://www.palisade.email/learning/google-one-click-unsubscribe > Google one-click unsubscribe requires bulk senders to support RFC 8058 headers and a visible unsubscribe link for marketing and subscribed Gmail messages. Google one-click unsubscribe applies to senders that send close to 5,000 messages or more to personal Gmail accounts in a 24-hour period. Google requires marketing and subscribed messages from those senders to support one-click unsubscribe, use the required `List-Unsubscribe` headers, and include a clearly visible body unsubscribe link. The requirement began on February 1, 2024, with an implementation deadline of June 1, 2024 for senders that already had an unsubscribe link. ## Quick takeaways - Google requires one-click unsubscribe for marketing and subscribed messages from senders that send close to 5,000 messages or more to personal Gmail accounts in a 24-hour period. - Transactional messages, such as password resets and reservation confirmations, are excluded from Google's one-click unsubscribe requirement. - A compliant message includes both `List-Unsubscribe` and `List-Unsubscribe-Post` headers. - The `List-Unsubscribe` header must contain an HTTPS URL for Google's requirement. - A visible unsubscribe link in the message body is still required for affected marketing and subscribed messages. - Gmail decides whether to show an unsubscribe control after its automated eligibility checks. ## Who is affected? Google's [Email sender guidelines](https://support.google.com/mail/answer/81126) apply the one-click unsubscribe requirement to senders that send close to 5,000 messages or more to personal Gmail accounts in a 24-hour period. The threshold concerns messages sent to Gmail accounts, not an organization's total mail volume across all recipients. The affected traffic is marketing and subscribed email. Google's [sender-guidelines FAQ](https://support.google.com/mail/answer/14229414) says transactional messages are excluded. Its examples include password reset messages, reservation confirmations, and form submission confirmations. A sender can have both types of mail. A password-reset system and a newsletter platform should not be treated as one stream merely because they use the same organizational domain. Classify messages by their recipient-facing purpose, then ensure commercial and promotional traffic has the required headers and body link. Google says recipients, rather than Google, determine whether they regard a message as promotional or transactional. When a message mixes an operational notice with promotional content, avoid assuming that its technical purpose alone makes it exempt. The broader [sender requirements guide](/learning/gmail-bulk-sender-guidelines) is the better place to track changing provider rules across message types and mailbox providers. ## What are the requirements? ### Marketing and subscribed messages must support one-click unsubscribe Google says affected bulk senders' marketing and subscribed messages must support one-click unsubscribe. The message must also include a clearly visible unsubscribe link in its body. Google's requirement is separate from a recipient's ability to mark a message as spam. Its FAQ says messages that do not meet the one-click unsubscribe requirement are not automatically rejected or marked as spam for that reason. Unwanted mail without an easy unsubscribe path is more likely to be reported as spam, which can affect delivery. A visible footer link alone does not satisfy the one-click requirement. Google permits a preference-center link in the message body, but says it does not comply with RFC 8058 when used without the required message headers. ### Outgoing messages need two List-Unsubscribe headers Google's sender guidelines specify these two headers for Gmail one-click unsubscribe: ```text List-Unsubscribe: <https://yourdomain.com/unsubscribe/opaque-recipient-token> List-Unsubscribe-Post: List-Unsubscribe=One-Click ``` The URL is illustrative only. Generate the real recipient-specific URL in the sending platform or list-management system. Do not publish a live subscriber token in documentation, tickets, or test messages. ![Google one-click unsubscribe checklist showing the required HTTPS List-Unsubscribe URL, List-Unsubscribe-Post value, visible body link, and message classification](/images/editorial/google-one-click-unsubscribe/google-one-click-unsubscribe-checklist.webp "1200x639") *Source: Palisade.* Google's FAQ says a `mailto` link can still be supported, but it does not meet Google's one-click unsubscribe requirement. The `List-Unsubscribe` header must include one HTTPS URL. RFC 8058 is the controlling IETF standard for the one-click mechanism. It is a Standards Track RFC published in January 2017. The RFC defines the signal a sender places in the message and the HTTPS POST a receiver can send after obtaining the user's consent. It does not require Gmail, or any other mailbox provider, to render an unsubscribe control for every message. ### The one-click request is an HTTPS POST Google documents the POST body it sends when a recipient uses one-click unsubscribe: ```text POST /unsubscribe/opaque-recipient-token HTTP/1.1 Host: yourdomain.com Content-Type: application/x-www-form-urlencoded List-Unsubscribe=One-Click ``` RFC 8058 says the receiver should use `multipart/form-data` and may use `application/x-www-form-urlencoded`. An interoperable endpoint accepts either format. The unsubscribe endpoint needs to process the request at the HTTPS URL in the message header. RFC 8058 says the request must not depend on browser cookies, HTTP authentication, or an HTTPS redirect. A preference center can still exist for a body link, but a receiver's background POST must be able to remove the recipient from the relevant list without a browser session. ### DKIM must protect the one-click headers RFC 8058 requires at least one valid DKIM signature to cover both `List-Unsubscribe` and `List-Unsubscribe-Post`. This helps a receiver determine that an authorized sender supplied the one-click instructions. A sending platform's "DKIM enabled" indicator does not prove these header fields are signed. Inspect a delivered marketing message's raw headers and confirm that the `h=` list in a valid DKIM signature includes both field names. The adjacent [Gmail one-click unsubscribe guide](/learning/gmail-one-click-unsubscribe) can help with the Gmail-specific implementation context. ![One-click unsubscribe validation flow from message headers through DKIM verification and suppression update](/images/editorial/google-one-click-unsubscribe/google-one-click-unsubscribe-validation-flow.webp "1200x522") *Source: Palisade.* ## When does the requirement take effect? Google's bulk-sender requirements took effect on February 1, 2024. The sender-guidelines FAQ states that senders who already included an unsubscribe link had until June 1, 2024 to implement one-click unsubscribe in all commercial and promotional messages. RFC 8058 itself is not a new Google policy. It has been a final IETF Standards Track RFC since January 2017. Google uses the RFC 8058 mechanism in its current sender requirements. Google previously referred to these as Bulk sender guidelines. Its current [Email sender guidelines FAQ](https://support.google.com/mail/answer/14229414) describes the policy as requirements for sending mail to personal Gmail accounts. Check the current guidance when changing a sending platform, adding a new message stream, or reviewing a high-volume campaign. ## How do I implement the requirement? ### 1. Identify Gmail-bound marketing and subscribed traffic Inventory every production system that sends marketing, newsletter, subscription, or promotional mail to Gmail accounts. Include ESPs, CRM campaigns, product-notification systems, and custom mail services where they send this type of traffic. Separate transactional templates from promotional templates, but keep the classification review documented. A sender that crosses Google's threshold cannot solve the requirement by adding headers only to its largest newsletter. ### 2. Generate a recipient-specific HTTPS unsubscribe URL Configure the sending platform or list system to create an HTTPS URL that identifies the recipient and relevant mailing list without exposing a plain email address. The endpoint must have enough information to process the removal when Gmail submits the POST. Use an opaque token that is difficult to guess. Treat a repeated valid POST as idempotent, so a recipient who is already removed remains removed without creating duplicate work. > Do not make the endpoint redirect to a login page, confirmation page, consent screen, or preferences page. RFC 8058 says an HTTPS redirect is not part of the one-click transaction. ### 3. Add the two headers before DKIM signing Add `List-Unsubscribe` with the HTTPS URL and `List-Unsubscribe-Post: List-Unsubscribe=One-Click` to each affected outbound message. Ensure the final DKIM signing stage covers both fields. If an ESP inserts or modifies headers after another system signs the message, inspect the final delivered copy. The right configuration in an upstream service can still fail if a later mail hop changes the signed header set. ### 4. Keep a visible unsubscribe link in the message body Add a clearly visible unsubscribe link to the body of every affected marketing and subscribed message. This link may lead to a preference center, but it does not replace the header-based one-click implementation. For platform-specific implementation and validation patterns, see [Mailchimp one-click unsubscribe](/learning/mailchimp-one-click-unsubscribe) if Mailchimp is part of the sending path. ### 5. Update suppression at the source of truth When the one-click endpoint receives a valid request, remove the recipient from the mailing list covered by that message. Ensure the suppression update reaches every production sender that can send that list's traffic. The one-click endpoint is not a substitute for consent records, list governance, or a process for handling recipient requests across separate brands and systems. ## How do I validate compliance? Start with a real delivered marketing message sent through the same production route used for Gmail recipients. Inspect its raw headers for the HTTPS `List-Unsubscribe` value and `List-Unsubscribe-Post: List-Unsubscribe=One-Click`. Then confirm a valid DKIM signature covers both header names. Next, use a safe test recipient and submit the fixed POST payload to a test unsubscribe URL in both `application/x-www-form-urlencoded` and `multipart/form-data` formats. Confirm the endpoint completes without cookies, credentials, browser JavaScript, or redirects. Verify the recipient's suppression state in the list-management source of truth, then test that the same sending path no longer sends covered marketing traffic to that recipient. Use Gmail's view as an additional check. Gmail's [unsubscribe help](https://support.google.com/mail/answer/15433283) tells recipients to open a message and select Unsubscribe next to the sender's name when the option is available. Google says the top-of-message control is displayed only for messages that pass its automated eligibility checks. Its absence does not by itself prove that the headers are absent or that the sender is noncompliant. Validation needs four layers: - DNS: confirm the sending domain's required authentication records are published through authoritative DNS and a public resolver. - Vendor: confirm the platform that sends the message shows the intended authentication and header configuration. - Message: inspect the delivered message from the exact production route. - DMARC: review aggregate-report data after messages have accumulated to identify sending sources and authentication outcomes. An [email security score](/tools/email-security-score) can check public sender-authentication posture. It cannot submit an unsubscribe POST, inspect every production message, prove Gmail will display its control, or guarantee future delivery. ## Check the broader Gmail sender requirements One-click unsubscribe is one part of Google's sender policy. The same affected sending stream also needs authentication, alignment, transport, and spam-rate controls described in Google's current guidance. [Review the current sender requirements](/learning/gmail-bulk-sender-guidelines) That requirements guide can help you compare the policy with the rest of your sending program. It does not prove that a particular message has the correct headers, that an unsubscribe endpoint updates every suppression system, or that Gmail will display the control. ## Sources and further reading - [RFC 8058: Signaling One-Click Functionality for List Email Headers](https://datatracker.ietf.org/doc/html/rfc8058) - [Google Email sender guidelines](https://support.google.com/mail/answer/81126) - [Google Email sender guidelines FAQ](https://support.google.com/mail/answer/14229414) - [Gmail Help: Unsubscribe from an email](https://support.google.com/mail/answer/15433283) - [Google One Help: Cancel your Google One membership](https://support.google.com/googleone/answer/9056360) ## Frequently asked questions ### Is one-click unsubscribe mandatory? Yes, but only for Gmail bulk senders' marketing and subscribed messages. Google requires it once a sender sends close to 5,000 messages or more to personal Gmail accounts in a 24-hour period. Transactional messages are excluded from this particular requirement. ### What is Google one-click? Google one-click unsubscribe is Gmail's use of the RFC 8058 mechanism for qualifying marketing and subscribed messages. The sender includes `List-Unsubscribe` with an HTTPS URL and `List-Unsubscribe-Post: List-Unsubscribe=One-Click`, then Gmail can send the defined POST when a recipient chooses to unsubscribe. ### How do I unsubscribe from Gmail one-click? Open the message in Gmail and select Unsubscribe next to the sender's name when Gmail displays that option. Confirm the action in the pop-up. Some senders instead show Go to website because their unsubscribe process requires their website. ### How do I unsubscribe from Google One? On a computer, Google says to open Google One, select Settings, then Cancel membership, and confirm the cancellation. If you bought the subscription through the Apple App Store or another third party, cancel it through that channel instead. Google One is a paid membership, so this is a different job from unsubscribing from a Gmail message. ### Does a visible unsubscribe link meet Google's requirement? No, a visible link on its own is not enough, because Google asks affected senders for both. The message body needs a clearly visible unsubscribe link, and the message also needs RFC 8058 headers: an HTTPS `List-Unsubscribe` URL plus `List-Unsubscribe-Post: List-Unsubscribe=One-Click`. ### Does Gmail always show the unsubscribe control? No, Gmail shows the top-of-message control only for messages that pass its own automated eligibility checks. Correct headers are necessary for one-click unsubscribe, but they do not guarantee that Gmail displays a control on every message you send. --- # Google Postmaster domain and IP reputation dashboard Canonical: https://www.palisade.email/learning/google-postmaster-domain-and-ip-reputation-dashboard > Google Postmaster domain and IP reputation dashboards are legacy views being retired in v2. Learn what their ratings mean and what to check next. The Google Postmaster domain and IP reputation dashboard refers to legacy Postmaster Tools views that rate the sending domains and IP addresses Google sees in mail sent to personal Gmail accounts. Google says the Domain Reputation and IP Reputation dashboards are being retired from Postmaster Tools v2, and its v2 API excludes those reputation reports. If a legacy view is still available to your account, treat it as a Gmail-specific signal, not a general measure of delivery everywhere. [Google's Postmaster Tools deprecation notice](https://support.google.com/mail/answer/16594218) explains the change. ## Quick takeaways - Google's old Postmaster Tools interface includes separate Domain Reputation and IP Reputation dashboards. - Google says those two reputation dashboards are being retired from Postmaster Tools v2. - Legacy reputation data applies to mail sent to personal Gmail accounts, not every mailbox provider. - The Domain Reputation dashboard attributes data to the exact domain used for DKIM or SPF authentication. - Google describes reputation as a quality rating based on sending behavior for a domain or IP address. - A public IP reputation lookup cannot reveal Google's private reputation decision or guarantee Gmail inbox placement. ## How the legacy reputation dashboards work [Google's Postmaster Tools dashboard documentation](https://support.google.com/mail/answer/14668346) describes IP Reputation as a quality rating for sending IP addresses and Domain Reputation as a quality rating for sending domains. Google says these views show reputation for domains and IP addresses that send DKIM-authenticated messages to Gmail accounts. If the sender does not use DKIM, Google uses SPF-authenticated messages for the display. The legacy Domain Reputation dashboard has an important scope rule. Google says it only displays messages sent from the exact domain used during DKIM and SPF authentication. A visible From domain alone does not establish which domain will appear in that report. This is why reputation work belongs inside a broader [email deliverability](/email-deliverability) investigation. A reputation state is one Gmail signal. It does not identify every source that sends as your domain, prove that a given message reached the inbox, or explain another receiver's filtering decision. Google's older dashboard documentation lists four reputation ratings: - `Bad` indicates a history of regularly sending a high volume of spam. - `Low` indicates a history of regularly sending a significant volume of spam. - `Medium` indicates mostly legitimate mail with occasional spam. - `High` indicates a history of very low spam rates and compliance with Gmail's sender guidelines. Google also warns that dashboard data is not real time and that low outgoing volume can leave data out of the dashboards to protect Gmail user privacy. Do not treat a missing value as a clean result. ## When the answer changes The practical answer depends on which version of Postmaster Tools your account can access. If the account still exposes a legacy reputation view, read the domain and IP ratings separately. An IP rating concerns the sending address Google observed. A domain rating concerns the exact domain authenticated through DKIM or SPF. A poor result in one view does not, by itself, document the cause of a result in the other. If the account uses Postmaster Tools v2 and the old reputation cards are unavailable, do not assume there is a replacement card with the same labels or meaning. Google's deprecation notice says new dashboards will provide more actionable information, but it does not document a direct replacement for the old Domain Reputation or IP Reputation dashboards. Use the dashboards and error evidence that are available in the account, then compare them with the sender's actual authentication and delivery data. Google's [email sender guidelines](https://support.google.com/mail/answer/81126) also make shared IP addresses a separate consideration. Activity from other senders on a shared IP can affect that IP's reputation. That warning does not mean a shared-IP customer can see or control every sender's behavior. ![Decision flow for interpreting a legacy Google Postmaster reputation result versus a Postmaster Tools v2 account without the legacy reputation dashboards](/images/editorial/google-postmaster-domain-and-ip-reputation-dashboard/google-postmaster-domain-and-ip-reputation-dashboard-reputation-decision-flow.webp "1200x767") *Source: Palisade.* ## A practical decision rule for a reputation result Start with the evidence Google actually reports, then collect evidence from the same sending path. This rule avoids treating a dashboard color as a root-cause diagnosis. ```text Illustrative decision rule If a legacy Domain Reputation or IP Reputation result is available: Record the date, the exact authenticated domain, and the sending IP. Compare the result with the Spam Rate, Authentication, and Delivery Errors views. Inspect a delivered message from the same production sender. If the old reputation views are unavailable in Postmaster Tools v2: Do not infer an old-style reputation rating. Use available Gmail dashboards, delivery errors, and message authentication evidence. Check public IP signals separately when the sending IP is known. ``` For a delivered message, inspect the receiver-added `Authentication-Results` header rather than relying on an ESP setup screen. [RFC 8601](https://datatracker.ietf.org/doc/html/rfc8601) defines that header field for reporting message authentication results. A passing DKIM or SPF result can help establish what Google associates with the traffic, but it does not prove a high reputation state. When the problem concerns the domain identity rather than the infrastructure address, review the distinction in [what is a domain reputation](/learning/what-is-a-domain-reputation). When the issue is broader sender trust, [email sender reputation](/learning/email-sender-reputation) covers the surrounding concept without treating any one provider dashboard as universal. ## What to check after a reputation result Use the evidence you have: - If you have access to legacy Postmaster Tools, compare the displayed reputation with Google’s Spam Rate, Authentication, and Delivery Errors data for the same period. - If you have a Gmail delivery error, preserve the exact error and inspect a message from the affected production path. Google documents low sending IP and low sending domain reputation as separate delivery-error categories in its [Postmaster Tools dashboard guidance](https://support.google.com/mail/answer/14668346). - If you know the sending IP, check public signals for that address separately, and [check the domain against public blocklists](/tools/domain-reputation) as well. This can help identify an external blocklist issue, but it cannot reproduce Google's private reputation calculation. - If the mail uses a third-party sender, identify the authenticated domain and actual sending IP before changing DNS or routing traffic. Google’s documentation does not make a vendor setup screen proof of the production sending path. ### Check the public reputation signals for the sending IP When a legacy Google IP rating is unavailable, or when you need a second source of evidence for a known sending address, inspect that IP before deciding whether the issue is isolated to Gmail. [Check the sending IP](/tools/ip-reputation) A public IP check cannot show Google’s current reputation rating, prove why Gmail filtered one message, or guarantee future Gmail placement. If aggregate reports show several legitimate sources using the same domain, the ongoing work is identifying which paths pass aligned authentication and which need remediation. Palisade autonomously analyzes DMARC aggregate-report data, identifies authentication or alignment issues, and creates prioritized remediation tickets. It does not change Google’s reputation decision or guarantee delivery. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=deliverability&utm_content=google-postmaster-domain-and-ip-reputation-dashboard) ## Sources and further reading - [Google: Postmaster Tools dashboards](https://support.google.com/mail/answer/14668346) - [Google: Set up Postmaster Tools](https://support.google.com/mail/answer/9981691) - [Google: Learn about the deprecation of the old Postmaster Tools interface](https://support.google.com/mail/answer/16594218) - [Google: Email sender guidelines](https://support.google.com/mail/answer/81126) - [RFC 8601: Message Authentication Status](https://datatracker.ietf.org/doc/html/rfc8601) ## Frequently asked questions ### Are Google Postmaster domain and IP reputation dashboards still available? The two dashboards still appear for accounts on the legacy Postmaster Tools interface, but Google is retiring both from Postmaster Tools v2. Availability therefore depends on which interface version your account uses. The v2 API leaves the reputation reports out as well. ### Does a high Google reputation rating guarantee Gmail inbox placement? No, a high rating makes inbox delivery more likely rather than certain. Google says senders with a high reputation are more likely to have mail delivered to the Gmail inbox instead of spam. That describes a pattern across traffic, not a promise for one message, recipient, or future send. ### Does Google domain reputation use the visible From domain? Google reports on the exact domain used during DKIM or SPF authentication, which matches the visible From domain only when that same domain authenticates the mail. If a third-party service signs with its own domain, that service's domain is what appears in the dashboard. Confirm which domain actually authenticates before you read the rating as a verdict on your brand domain. ### Why is there no reputation data in Postmaster Tools? Google says dashboard data is not real time and may omit data on days with low outgoing email volume. Missing data does not prove that the sender has a positive reputation or that Gmail has no data. ### Can an IP blocklist lookup replace Google Postmaster Tools? No, because a blocklist lookup reads public signals while Postmaster Tools reports what Google itself observed. A public lookup can show whether a known sending IP appears on a list. It cannot show Google’s private rating, your account-level Postmaster data, or the placement decision for one Gmail message. --- # Google Postmaster Tools DMARC: what the data means Canonical: https://www.palisade.email/learning/google-postmaster-tools-dmarc > Google Postmaster Tools DMARC data shows Gmail DMARC pass rates. Check its limits, inspect your published record, repair evidence, and retest. Google Postmaster Tools shows the percentage of mail that passes DMARC for messages sent to personal Gmail accounts with your domain in the From header. Use that percentage as a Gmail-specific signal, then inspect the published record separately and validate authentication on real delivered messages. It does not document why a particular percentage changed, whether a DMARC policy enforces, or how mail performs at other receivers. ## Quick takeaways - Google Postmaster Tools Authentication reports the percentage of email that passes SPF, DKIM, and DMARC. - Its dashboard data applies only to mail sent to personal Gmail accounts, including `@gmail.com` and `@googlemail.com`. - Google can omit data on low-volume days, and it does not publish the volume threshold. - A DMARC pass-rate percentage does not identify the failing sending source, alignment failure, or published `p=` policy. - The [Palisade DMARC checker](/tools/dmarc) reads the public DMARC DNS record, not Google Postmaster Tools data or DMARC aggregate reports. - A working DMARC workflow needs DNS evidence, sender verification, a delivered message, and aggregate-report evidence after reports accumulate. ## What this tool checks Google's [Postmaster Tools Authentication dashboard documentation](https://support.google.com/mail/answer/14668346) says the dashboard displays the percent of email that passes SPF, DKIM, and DMARC. Postmaster Tools has eight dashboards, including Authentication, Compliance status, Spam rate, IP Reputation, Domain Reputation, Feedback loop, Encryption, and Delivery errors. For DMARC, the important boundary is scope. Google says dashboard data applies only to messages with your sending domain in the From header that were sent to personal Gmail accounts. It is useful evidence about that Gmail audience. It is not a complete view of every mailbox provider, every recipient, or every sending path that uses the domain. The [Palisade DMARC checker](/tools/dmarc) answers a different question. It accepts a domain and checks its currently published public DNS record. It can show whether the record has an enforcing policy and whether reporting addresses are present, but it cannot see a production message, the sender's signing configuration, Google Postmaster Tools percentages, continuous state, or why one receiver rejected one message. ![Decision flow separating Google Postmaster Tools DMARC pass-rate data from a public DMARC DNS check](/images/editorial/google-postmaster-tools-dmarc/google-postmaster-tools-dmarc-result-map.webp "1200x829") *Source: Palisade.* For broader protocol context, see the [DMARC learning hub](/learning/dmarc) and [what DMARC is](/learning/what-is-dmarc). ## How to run the check ### 1. Add the domain to Google Postmaster Tools Google's [Postmaster Tools setup instructions](https://support.google.com/mail/answer/9981691) say to add either the DKIM `d=` domain or the SPF Return-Path domain. Verify control of that domain with the DNS TXT or CNAME record that Google generates. Google states that verification is usually immediate, though the status can take up to 10 minutes to update. Do not use a record copied from another account. Publish the value generated for the domain you are verifying. ### 2. Open the Authentication dashboard After verification, open Authentication in Postmaster Tools and select the domain. Google uses messages signed with SPF, DKIM, or both for dashboard data. Review the DMARC percentage as an aggregate Gmail signal, not as a per-message diagnosis. If the dashboard has no data for a day, do not infer that DMARC passed or failed. Google says it might omit data when outgoing volume is too low to protect Gmail user privacy, and does not disclose the threshold. ### 3. Check the published DMARC record independently Enter the visible From domain in the Palisade DMARC checker. A public lookup is repeatable outside either interface: ```bash dig +short TXT _dmarc.yourdomain.com ``` A structural example of a DMARC record is: ```text v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com ``` > Do not publish an example reporting mailbox unless you control it. Use the reporting address and authorization setup appropriate for your own domain and report processor. The DNS answer establishes what receivers can retrieve now. It does not prove that the sender uses aligned SPF or DKIM, and it does not explain a Google Postmaster Tools percentage. ### 4. Preserve a real-message sample Send a new message through the same application, marketing platform, or transactional sender that is under review. Keep its raw headers with private addresses and identifiers redacted. The receiver-added `Authentication-Results` header is the message-layer evidence for SPF, DKIM, and DMARC outcomes. [RFC 8601 defines that header field and its authentication-method results](https://datatracker.ietf.org/doc/html/rfc8601). This separates a valid record from a valid production sending path. ![Evidence checklist for investigating a Google Postmaster Tools DMARC percentage change](/images/editorial/google-postmaster-tools-dmarc/google-postmaster-tools-dmarc-evidence-checklist.webp "1200x530") *Source: Palisade.* ## How to interpret the results ### Google Postmaster Tools shows a DMARC percentage The Authentication dashboard's DMARC number is the percentage of qualifying mail that passes DMARC in Google's documented scope. It does not provide a documented mapping from a percentage to an alignment problem, a source IP, a particular sender, or a DMARC enforcement setting. Do not set an invented repair threshold such as a target percentage. Google does not document one. Instead, use a percentage change as a reason to collect stronger evidence: compare a recent delivered message, confirm the DNS record, and investigate sending sources through DMARC aggregate reports. ### Google Postmaster Tools has missing data Missing dashboard data can result from low daily volume. Google's documentation explicitly allows this privacy-related omission. Wait for more qualifying mail, then review the dashboard again. A missing day is not proof that your configuration is broken. ### The Palisade checker shows "Domain protected" The checker uses "Domain protected" when its policy state is `dmarc-policy-reject-full`, meaning it found a published `p=reject` record with `pct=100` or an equivalent full-reject state. That result is DNS evidence about the published policy. It still does not establish that all production messages authenticate or align. Check the sender configuration and a delivered message before treating the policy as operationally effective. ### The Palisade checker shows "Domain partially protected" The checker uses "Domain partially protected" for its partial quarantine and partial reject policy states. This means the published policy does not meet the tool's full-reject state. Inspect the record details before changing it, because a stricter policy can affect legitimate mail that has not yet been identified and aligned. ### The Palisade checker shows "Domain not defended" or "Domain defense is invalid" "Domain not defended" corresponds to the `dmarc-policy-none` state. "Domain defense is invalid" corresponds to `dmarc-invalid`. A missing record maps to "Domain not protected." These are public DNS diagnoses, so first confirm the exact domain and authoritative answer before editing DNS. Google's [email sender guidelines](https://support.google.com/a/answer/81126) require bulk senders to set up DMARC, but state that the DMARC enforcement policy may be `none`. A DMARC record is therefore distinct from an enforcing policy. ### The monitoring status needs separate attention The checker joins its policy state and monitoring state in one headline. "Monitoring is not in place" indicates missing reporting configuration. "Monitoring is invalid" indicates invalid monitoring configuration. "Double check monitoring emails" indicates external monitoring, while "Monitoring with Palisade" indicates Palisade-managed monitoring. A record can be protected while monitoring is absent. For example, a full `p=reject` record without a reporting address can still produce the protected policy state and a missing-monitoring state. That is why policy strength and report visibility need separate checks. ## How to act on the result Start with the evidence closest to the failure. - If the Postmaster Tools percentage changed, identify the sending applications that use the From domain. Check each application's SPF and DKIM configuration, then inspect a fresh message from each path. A Gmail percentage alone does not identify the responsible source. - If the published record is missing or invalid, query the authoritative DNS provider and at least one public resolver before changing it. Correct the exact `_dmarc` owner, not a similarly named subdomain. - If the record uses `p=none`, collect and review aggregate reports before moving to quarantine or reject. A policy change affects receivers' handling of mail that fails DMARC. - If monitoring is absent, add a valid aggregate-report destination. The checker describes a missing `rua=` tag as missing aggregate reporting needed to analyze DMARC vulnerabilities. - If DNS is correct but a real message fails DMARC, inspect its SPF and DKIM results and alignment against the visible From domain. DNS validity does not prove the application's production settings. For report files you already have, the [DMARC Report Analyzer](/tools/dmarc-report-analyzer) accepts aggregate RUA reports. It can help interpret report data, but it does not replace a delivered-message check or reveal Google's private recipient-level decisions. ## Investigate this with your coding agent Use this when a public DMARC check and the Postmaster Tools view do not give enough evidence to identify the sender or record behavior. Prepare a redacted checker result, a redacted delivered-message result, and the exact DNS owner you intend to inspect. ```agent Problem: Google Postmaster Tools shows a DMARC pass-rate change, but the published DMARC record and production sender outcome need to be separated. Evidence: Redacted Palisade DMARC checker result for yourdomain.com, redacted Authentication-Results header from a new message, and the current _dmarc.yourdomain.com TXT answer. Repository scope: The DMARC checker route, DNS parser, and deterministic parser tests in this repository. Constraints: Inspect before editing. Do not apply changes until I approve the proposed diff. Do not use credentials, private keys, tokens, unredacted headers, customer data, or make DNS or production changes. Requested output: Diagnosis, minimal proposed change, rollback, and unknowns. Verification: Re-run the same public DMARC lookup for yourdomain.com and compare a newly delivered message from the same sending path. Stop if: Credentials, private data, production mutation, or missing evidence is required. ``` ## How to retest After a DNS correction, query the same `_dmarc` owner again and rerun the Palisade checker with the same domain. If you changed a sender configuration, send a new message through that exact sender and inspect the new `Authentication-Results` header. Then allow time for later Google Postmaster Tools data to appear and compare like-for-like Gmail traffic. The expected change is evidence that the public record is now valid and that the tested message passes the intended authentication branch. A later percentage movement can support that diagnosis for personal Gmail traffic, but it does not prove future inbox placement or all-recipient performance. ## Check the record behind the Gmail signal Use the [Palisade DMARC checker](/tools/dmarc) to inspect the published record for the same From domain that appears in Postmaster Tools. Compare its policy and monitoring states with a fresh delivered-message result before changing enforcement. A DNS check cannot explain a specific Google Postmaster Tools percentage, identify every production sender, monitor future changes, or guarantee delivery. If your team needs to inventory senders and work through DMARC aggregate-report evidence over time, [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=dmarc_tools_validation&utm_content=google-postmaster-tools-dmarc). Palisade analyzes DMARC aggregate-report data, identifies authentication or alignment issues, and proposes prioritized remediation work. A human reviews the evidence and applies any DNS or policy change. ## Sources and further reading - [Google Postmaster Tools dashboards](https://support.google.com/mail/answer/14668346) - [Set up Google Postmaster Tools](https://support.google.com/mail/answer/9981691) - [Google email sender guidelines](https://support.google.com/a/answer/81126) - [RFC 8601: Authentication-Results header field](https://datatracker.ietf.org/doc/html/rfc8601) - [Palisade DMARC checker](/tools/dmarc) ## Frequently asked questions ### Does Google Postmaster Tools show DMARC alignment failures? No. Google's Authentication dashboard documentation says it displays the percentage of email that passes DMARC. It does not document an alignment breakdown, per-message view, or per-source diagnosis. ### Does Google Postmaster Tools cover all recipients of my domain's mail? No. Google says its dashboard data applies only to messages sent to personal Gmail accounts with the sending domain in the From header. It is not a view of other mailbox providers or every recipient. ### Does a Google Postmaster Tools DMARC percentage show my DMARC policy? No. Google does not document Authentication as a view of the published `p=` value, subdomain policy, or enforcement status. Query the public `_dmarc` DNS record to inspect the published policy. ### Can a missing Postmaster Tools day mean DMARC failed? No. Google says dashboard data can be missing when daily volume is too low, to protect Gmail user privacy. The published documentation does not state the threshold. ### Does a passing DMARC record check prove every sender is configured correctly? No. A public record check shows the DNS record available to receivers. Confirm each production sender with its configuration and a delivered message's authentication results. --- # Google and Yahoo one-click unsubscribe requirements Canonical: https://www.palisade.email/learning/google-yahoo-one-click-unsubscribe > Google Yahoo one-click unsubscribe requirements differ on sender thresholds, dates, message scope, processing time, and enforcement consequences. Google and Yahoo both set one-click unsubscribe expectations for bulk senders, but they do not use the same threshold, enforcement timing, or processing deadline. Google applies its rule to senders of more than 5,000 messages per day to personal Gmail accounts from 1 February 2024. Yahoo does not publish a numeric bulk-sender threshold, began List-Unsubscribe enforcement in June 2024, and requires unsubscribes within two days. ## Quick takeaways - Google requires one-click unsubscribe for senders of more than 5,000 messages per day to personal Gmail accounts. - Google's requirement took effect on 1 February 2024 and does not apply to Google Workspace accounts. - Yahoo does not publish a numeric threshold for bulk senders. - Yahoo requires a functioning list-unsubscribe header for marketing and subscribed messages, while transactional messages are excluded from that requirement. - Yahoo began enforcing its List-Unsubscribe policy in June 2024 and requires unsubscribes to be honored within two days. - RFC 8058 defines the one-click header and HTTPS POST mechanism that both providers reference. ## Who is affected? Google and Yahoo assess their own recipient traffic and sender requirements. One-click unsubscribe is part of wider mailbox-provider expectations that can affect deliverability, alongside authentication and complaint handling. See the [deliverability learning center](/email-deliverability) for the surrounding operational context. ### Google: senders above 5,000 messages per day to personal Gmail accounts [Google's email sender guidelines](https://support.google.com/a/answer/81126) require senders of more than 5,000 messages per day to personal Gmail accounts to support one-click unsubscribe. The guideline applies to mail sent to personal Gmail accounts, not Google Workspace accounts. That qualifier matters for B2B programs. A sender that mails only Google Workspace recipients is outside this specific Google rule, even though its mail can still be subject to other authentication, spam, and recipient-policy checks. Google's published threshold is a daily message volume, not a count of subscribers, campaigns, or domains. ### Yahoo: significant-volume bulk senders, without a published number Yahoo uses a different definition. Its [sender FAQ](https://senders.yahooinc.com/faqs/) states: "A 'bulk' sender is classified as an email sender sending a significant volume of mail. We will not specify a volume threshold." Do not apply Google's 5,000-message figure to Yahoo. Yahoo's rule may affect senders that cannot classify themselves from a published volume cutoff, so marketing teams should treat the requirement as an operational standard for meaningful Yahoo-bound campaign volume. Yahoo also limits the one-click requirement by message type. Its FAQ states: "One-click unsubscribe is only required for promotional/marketing messages. The requirement does not apply to transactional messages." Google’s guidelines read for this article do not document that same message-type carve-out, so it should not be treated as a shared rule. ## What are the requirements? ### Google requires RFC 8058 one-click unsubscribe above its threshold Google says qualifying bulk senders must support one-click unsubscribe with the `List-Unsubscribe` and `List-Unsubscribe-Post` headers defined in [RFC 8058](https://www.rfc-editor.org/rfc/rfc8058.html). ```text List-Unsubscribe: <https://unsubscribe.yourdomain.com/list/opaque-token> List-Unsubscribe-Post: List-Unsubscribe=One-Click ``` RFC 8058 is an IETF Standards Track RFC published in January 2017. Section 4 requires both headers to be covered by the DKIM signature's `h=` tag. The standard describes the protocol mechanism, while Google decides which senders must use it. For the header construction, DKIM coverage, and endpoint behavior, use the focused [RFC 8058 one-click unsubscribe guide](/learning/google-one-click-unsubscribe). A published record or platform setting alone does not prove that delivered production mail carries the required headers. ### Yahoo requires a functioning list-unsubscribe header for covered mail Yahoo's [sender best practices](https://senders.yahooinc.com/best-practices/) say bulk senders should "Implement a functioning list-unsubscribe header, which supports one-click unsubscribe for marketing and subscribed messages". The same page says the POST method in RFC 8058 is "highly recommended." Yahoo's [sender FAQ](https://senders.yahooinc.com/faqs/) describes the requirement more directly: "You must implement the list-unsubscribe header (preferably according to RFC 8058) in order to meet the requirement for one-click unsubscribe." Those statements should be read together. Yahoo requires a functioning list-unsubscribe header for the covered message types, and identifies RFC 8058 as the preferred one-click method. Do not turn Yahoo's "highly recommended" wording for the RFC 8058 POST method into a universal Yahoo mandate. ![Comparison of Google and Yahoo one-click unsubscribe requirements, including threshold, scope, enforcement date, and processing deadline](/images/editorial/google-yahoo-one-click-unsubscribe/google-yahoo-one-click-unsubscribe-requirements.webp "1200x488") *Source: Palisade.* ![One-click unsubscribe implementation and validation flow for Google and Yahoo sender requirements](/images/editorial/google-yahoo-one-click-unsubscribe/google-yahoo-one-click-unsubscribe-flow.webp "1200x829") *Source: Palisade.* ### Yahoo requires unsubscribes within two days Yahoo's best-practices page requires senders to "Honor unsubscribes within 2 days." Its FAQ confirms: "If the unsubscribe is not honored in 2 days, then it would not meet the requirement." This is a Yahoo-specific processing deadline. Google's sender-guidelines page states no processing deadline, so two days is not a shared Google and Yahoo requirement. The deadline concerns the durable suppression outcome. An HTTP response from an unsubscribe endpoint does not establish that all relevant campaign systems, ESPs, and production sending paths will stop sending the covered mail. ### Yahoo may route noncompliant mail to spam or reject it Yahoo's FAQ states: "If you do not meet the requirements, your mail may be sent to the spam folder or rejected. If mail is rejected, we will return a specific error code with information about the rejection." "May" is important. Yahoo does not say every noncompliant message will be rejected. The public documentation confirms that a specific error code can accompany a rejection, but it does not enumerate the exact strings. Yahoo also requires bulk senders to keep spam complaint rates below 0.3%, which is separate from one-click unsubscribe. For the wider provider checklist, see Yahoo bulk sender requirements. ## When does the requirement take effect? Google's sender guidelines state that the requirements for senders of more than 5,000 messages per day took effect on 1 February 2024. The applicable scope is personal Gmail accounts. Yahoo's staged timeline is different. Its FAQ states: "Enforcement will begin in February 2024, and we will continue to gradually roll out enforcement as we monitor compliance metrics. Note: Enforcement of the List-Unsubscribe policy will begin in June 2024." The February 2024 Yahoo date refers to enforcement beginning for its broader requirements. June 2024 is the source-backed enforcement date for Yahoo's List-Unsubscribe policy specifically. Do not collapse those dates into a single shared deadline. ## How do I implement the requirement? ### 1. Classify the traffic by recipient and message type Measure daily volume to personal Gmail accounts separately from Google Workspace recipients. For Yahoo, identify marketing and subscribed mail separately from transactional mail. Keep this classification tied to the actual production sending path. A campaign tool's audience estimate may not match final recipient routing or send volume. ### 2. Configure the list-unsubscribe mechanism in the sending platform Configure the sender to include a functioning list-unsubscribe header for the covered messages. For Google-qualifying bulk mail, configure the RFC 8058 one-click headers. The header values, recipient token design, and POST endpoint are implementation details covered in the dedicated [one-click unsubscribe requirements guide](/learning/google-one-click-unsubscribe). Use values generated for your own sending environment. Do not copy another tenant's unsubscribe URLs or identifiers. ### 3. Ensure DKIM signs the relevant RFC 8058 headers For RFC 8058 use, send a controlled message and inspect its actual DKIM signature. RFC 8058 requires the DKIM `h=` tag to cover both `List-Unsubscribe` and `List-Unsubscribe-Post`. A vendor screen that says DKIM is enabled is not evidence that the delivered message signed these fields. ### 4. Connect the unsubscribe action to the production suppression state Test an unsubscribe with a safe test recipient. Confirm that the action updates the system that governs every relevant campaign sender, not only a web preference center or one application database. For Yahoo-covered promotional or marketing mail, verify that the recipient is suppressed within two days. Preserve only the evidence needed for troubleshooting, and avoid storing full recipient-specific unsubscribe URLs in routine logs. > A redirect, login requirement, or browser-only confirmation flow can break the RFC 8058 one-click transaction. Test the same HTTPS POST behavior that a mailbox provider can use. ## How do I validate compliance? Validate one-click unsubscribe at four layers. - DNS: Confirm the domain's DMARC and DKIM records resolve through the authoritative DNS service and a public resolver. This confirms published DNS, not delivered-message behavior. - Vendor: Check the sending platform's current authentication and unsubscribe configuration. A green platform status does not prove the production path adds the headers. - Message: Send a real test message through the exact production path and inspect its raw headers. Confirm the required list-unsubscribe headers are present and, for RFC 8058, covered by a valid DKIM signature. - DMARC and delivery: Review aggregate-report data after mail has been sent. For Yahoo, use [Yahoo Sender Hub](https://senders.yahooinc.com) to review its aggregated domain delivery statistics where available. A successful unsubscribe test proves the tested path. It does not prove that every future message, recipient system, or mailbox interface will behave the same way. ## Check the wider sender posture behind the unsubscribe requirement One-click unsubscribe is only one provider expectation. Use the [email security score](/tools/email-security-score) to inspect the domain's public authentication posture before comparing it with delivered-message headers and the sender platform's settings. The score cannot verify a list-unsubscribe header, test an unsubscribe endpoint, monitor future sender changes, or prove how Gmail or Yahoo will place an individual message. ## Sources and further reading - [RFC 8058: Signaling One-Click Functionality for List Email Headers](https://www.rfc-editor.org/rfc/rfc8058.html) - [Google email sender guidelines](https://support.google.com/a/answer/81126) - [Yahoo sender best practices](https://senders.yahooinc.com/best-practices/) - [Yahoo sender FAQs](https://senders.yahooinc.com/faqs/) ## Frequently asked questions ### How do I unsubscribe from Gmail and Yahoo one-click? As a recipient, use the unsubscribe control your mailbox provider puts on the message. As a sender, one-click unsubscribe means publishing a working List-Unsubscribe mechanism so Gmail or Yahoo can submit the request on the recipient's behalf. Google and Yahoo each set their own sender requirements rather than sharing one recipient interface. ### What happened to one-click unsubscribe? Google made one-click unsubscribe a requirement for senders of more than 5,000 messages per day to personal Gmail accounts effective 1 February 2024. Yahoo began enforcing its List-Unsubscribe policy in June 2024 for its bulk-sender requirements. ### How do I stop my Yahoo subscription? Use the unsubscribe control on the message, then the sender has to act on it. Yahoo requires covered bulk senders to honor an unsubscribe within two days for promotional and marketing messages. If you are the sender, confirm that the removal actually reaches your production suppression list, because that is where these requests tend to get lost. ### How do I unsubscribe from Gmail one-click? Use the unsubscribe control Gmail shows on the message, which sends the request to the sender for you. Senders above Google's threshold must support the RFC 8058 one-click mechanism on mail to personal Gmail accounts, and that requirement is what makes the control work. Google does not document the same behavior for every message, so the control is not always there. ### Do Google and Yahoo have the same one-click unsubscribe requirements? No, their rules differ in both scope and timing. Google publishes a threshold of more than 5,000 messages per day to personal Gmail accounts, effective 1 February 2024. Yahoo publishes no numeric threshold, began enforcing its List-Unsubscribe policy in June 2024, and requires unsubscribes to be honored within two days. ### Does Yahoo require one-click unsubscribe for transactional email? No, Yahoo limits the requirement to promotional and marketing messages and states that it does not apply to transactional mail. That carve-out is Yahoo's own, so do not assume Google draws the line in the same place. Check each provider's current sender requirements for the mail you actually send. --- # How does reverse DNS work for email? Canonical: https://www.palisade.email/learning/how-does-reverse-dns-work-for-email > How does reverse DNS work for email? Learn how PTR records map sending IP addresses to hostnames, and how forward confirmation works for email delivery. Reverse DNS for email starts with a sending server's IP address and looks up the hostname published for that address in a special DNS branch. The lookup uses a PTR record, then a receiver can look up that hostname's A or AAAA record to see whether it points back to the same IP address. This matters to anyone operating outbound SMTP infrastructure or assessing a sending IP's identity. ## Quick takeaways - Reverse DNS maps an IP address to a hostname through a PTR record. - IPv4 reverse lookups use the `in-addr.arpa` DNS tree with reversed address octets. - IPv6 reverse lookups use the `ip6.arpa` tree with reversed hexadecimal nibbles. - A PTR result alone does not prove forward-confirmed reverse DNS. - The IP owner or its provider usually controls the reverse DNS zone. - SMTP does not require an EHLO name to match the connecting IP address. ## Who is affected? Reverse DNS affects organizations that send email directly from public SMTP server IP addresses, along with the MSPs and infrastructure teams that manage those servers. It also affects receivers that inspect connection details as part of their mail processing. A domain owner does not necessarily control its reverse DNS entry. Microsoft explains that [reverse zones are typically maintained by the ISP](https://learn.microsoft.com/en-us/connectivity-analyzer/ip-address-does-not-have-ptr-record-dns). In practice, the public IP owner, hosting provider, or upstream network operator publishes the PTR record. Managing a website domain's normal DNS zone does not automatically give an administrator control over the reverse zone for a mail server IP. Reverse DNS is part of the wider set of DNS and transport dependencies covered in the [email infrastructure learning hub](/learning/infrastructure). For a closer explanation of the DNS record itself, see [what a PTR record is](/learning/what-is-a-ptr-record). ## What are the requirements? ### A PTR record maps the address to a domain name RFC 1035 defines a PTR record's data as a domain name that points to a location in the DNS namespace. For reverse mapping, that location is constructed from the address rather than from a normal hostname. For IPv4, RFC 1035 defines the reverse namespace under `IN-ADDR.ARPA`. Each address octet becomes a label in reverse order. The reversal lets DNS operators delegate reverse zones along network boundaries. ```text Illustrative only. Do not publish this as a production record. 52.0.2.10.in-addr.arpa. IN PTR mail.yourdomain.com. ``` For the IPv4 address `10.2.0.52`, RFC 1035 places reverse data at `52.0.2.10.IN-ADDR.ARPA`. A PTR query for that reverse name can return `mail.yourdomain.com`. The record does not authenticate a sender by itself. It states what hostname the reverse DNS zone publishes for an IP address. ### IPv6 uses reversed hexadecimal nibbles IPv6 reverse DNS uses a separate `IP6.ARPA` tree. [RFC 3596](https://www.rfc-editor.org/rfc/rfc3596.txt) specifies that an IPv6 address is represented as dot-separated hexadecimal nibbles, followed by `.IP6.ARPA`. ```text Illustrative only. Do not publish this as a production record. 8.b.d.0.1.0.0.2.ip6.arpa. IN PTR mail.yourdomain.com. ``` The full reverse name for a production IPv6 address contains all 32 hexadecimal nibbles in reverse order. RFC 3596 also records that `IP6.ARPA` replaced the older `IP6.INT` domain. ### Forward confirmation checks the returned hostname A common receiver check has two DNS stages: - Query the IP address for PTR records and collect the returned hostnames. - Query each returned hostname for A records, AAAA records, or both, then check whether the original IP address appears in those results. [RFC 8601 defines this method as `iprev`](https://www.rfc-editor.org/rfc/rfc8601.txt). If the client IP is `I`, PTR results are set `N`, and the corresponding forward DNS addresses are set `L`, the test passes when `I` is a member of `L`. ```text Illustrative only. 198.51.100.25 PTR query -> mail.yourdomain.com A query for mail.yourdomain.com -> 198.51.100.25 Result -> forward-confirmed reverse DNS passes ``` ![Reverse DNS flow showing an SMTP server IP queried for PTR, followed by a forward A or AAAA lookup of the returned hostname](/images/editorial/how-does-reverse-dns-work-for-email/how-does-reverse-dns-work-for-email-reverse-dns-flow.webp "1200x829") *Source: Palisade.* This is why a PTR result is only half the mechanism. A PTR can exist while the returned hostname resolves to a different address, has no usable A or AAAA record, or encounters a DNS error. RFC 8601 registers `pass`, `fail`, `temperror`, and `permerror` result values for `iprev` in the `Authentication-Results` header field. A receiver can report such a result, but the RFC also cautions that applications should avoid treating reverse mapping as authentication or a security control. The method remains common, yet it does not establish ownership of a message's From domain or replace SPF, DKIM, and DMARC. ### EHLO and PTR are related signals, not the same requirement An SMTP client identifies itself with `EHLO` or `HELO`. That name is often compared with connection information, but [RFC 5321 section 4.1.4](https://www.rfc-editor.org/rfc/rfc5321.txt) does not require a server to reject mail because the EHLO domain does not correspond to the client IP. The RFC states: ```text An SMTP server MAY verify that the domain name argument in the EHLO command actually corresponds to the IP address of the client. However, if the verification fails, the server MUST NOT refuse to accept a message on that basis. ``` A mismatch can still be useful for logging and tracing. It is not a universal SMTP rule that makes the message invalid. For the specific operational case where these names disagree, see [when reverse DNS does not match the SMTP banner](/learning/reverse-dns-does-not-match-smtp-banner). ## When does the requirement take effect? The underlying DNS mechanism has no single new operative date. RFC 1035, which defines IPv4 reverse mapping and PTR records, was published in November 1987. RFC 3596, published in October 2003, specifies IPv6 address mapping in `IP6.ARPA`. RFC 8601, published in May 2019, defines the `iprev` result method for Authentication-Results. Mailbox providers can add their own sender requirements. Google's [Email sender guidelines](https://support.google.com/a/answer/81126) state that all senders must have valid forward and reverse DNS from February 1, 2024. Google requires the sending SMTP server's public IP to have a PTR record resolving to a hostname, and that hostname to have an A record for IPv4 or AAAA record for IPv6 resolving back to the same public IP. That is a Google sender requirement, not a new universal SMTP requirement. A receiver can also apply private filtering policies that are not published as an RFC. ## How do I implement the requirement? ### 1. Identify the public IP used for the SMTP connection Use the IP that connects to recipient mail servers. This can differ from a web server address, a NAT gateway, or an internal mail host address. For a hosted sending service, determine whether the provider assigns the public IP and controls its reverse DNS. Do not assume a domain's normal DNS administrator can change the PTR record. ### 2. Find the reverse DNS owner Identify the provider that owns or delegates the reverse zone for the sending IP. The provider may be an ISP, cloud platform, hosting company, or dedicated IP service. Ask that owner to publish the desired PTR hostname if its documented process allows it. The hostname should be one the organization can also publish in forward DNS. ### 3. Publish the corresponding forward record Publish an A record for IPv4 or AAAA record for IPv6 so that the hostname returned by the PTR lookup resolves to the same public sending IP. This guidance creates the two-way DNS relationship that Google's sender guidance describes. It does not make reverse DNS an identity standard or guarantee a receiver will accept a message. ### 4. Keep SMTP identity evidence separate Inspect the actual SMTP exchange and delivered message headers separately from DNS. An EHLO name, a PTR hostname, an SPF identity, DKIM signing domain, and DMARC alignment can be related but are different protocol fields and checks. A correct PTR record does not prove that an application sent through that IP, that the message was signed correctly, or that a receiving mailbox provider accepted the message. ## How do I validate compliance? Start with the authoritative reverse lookup for the public sending IP. Confirm that it returns the intended hostname. Then query that hostname's A record or AAAA record and verify that the original IP appears in the answer. Use the [IP reputation checker](/tools/ip-reputation) to inspect the PTR hostname returned for a public IP. It can show a published PTR result, but it does not perform the follow-up A or AAAA lookup needed to establish an `iprev` result. A timeout or empty result also needs careful interpretation because public DNS responses can vary with resolver reachability and timing. For a full mail-path validation, gather evidence at separate layers: - DNS: confirm the PTR record and matching forward A or AAAA record through the authoritative DNS path and a public resolver. - Vendor: review the sending provider's current verification status when it manages the SMTP service. - Message: inspect a delivered message from the exact production path, including relevant `Authentication-Results` and SMTP tracing headers. - DMARC: review aggregate-report data after mail has accumulated to understand the domains and sources actually using the organization’s identity. A published PTR record does not prove future DNS state, receiver enforcement, inbox placement, or message authentication. ## Check the PTR hostname for your sending IP A reverse lookup can show which hostname the IP owner currently publishes before you investigate a mismatch or contact the provider that controls the reverse zone. [Check the IP's published PTR record](/tools/ip-reputation) This check returns a PTR result for an IP address. It does not forward-confirm the hostname, repair a mismatch, monitor the production sending path, or predict how a mailbox provider will treat a future message. ## Sources and further reading - [RFC 1035: Domain names, implementation and specification](https://www.rfc-editor.org/rfc/rfc1035.txt) - [RFC 3596: DNS extensions to support IP version 6](https://www.rfc-editor.org/rfc/rfc3596.txt) - [RFC 8601: Message header field for indicating message authentication status](https://www.rfc-editor.org/rfc/rfc8601.txt) - [RFC 5321: Simple Mail Transfer Protocol](https://www.rfc-editor.org/rfc/rfc5321.txt) - [Google Email sender guidelines](https://support.google.com/a/answer/81126) - [Microsoft guidance for an IP address without a PTR record](https://learn.microsoft.com/en-us/connectivity-analyzer/ip-address-does-not-have-ptr-record-dns) ## Frequently asked questions ### What are common problems with reverse DNS? Common reverse DNS problems include no PTR record for the sending IP and a PTR hostname that does not resolve back to that same IP through A or AAAA records. The reverse zone is usually controlled by the ISP or IP owner, so a domain administrator may need to request the correction from that provider. For server-side remediation, see the provider-focused reverse DNS setup guidance. ### What is reverse DNS in email? Reverse DNS in email is a DNS lookup from an IP address to a hostname. For IPv4, it queries a reversed address name in `in-addr.arpa`, such as `52.0.2.10.in-addr.arpa` for `10.2.0.52`, and reads the PTR record returned there. IPv6 uses the `ip6.arpa` equivalent. ### Is it legal to do a reverse email lookup? Yes. Reverse email lookup usually refers to finding information about a person from an email address, which can raise jurisdiction-specific privacy and legal issues. This article covers DNS lookups from server IP addresses to hostnames, not people-search services. ### How do I fix SMTP reverse DNS mismatch? Request a PTR correction from the provider that controls the public sending IP, then ensure the returned hostname has an A or AAAA record back to that same IP. An EHLO and IP mismatch alone is not a universal reason for SMTP rejection because RFC 5321 says a server must not refuse a message on that basis alone. See [the SMTP banner mismatch guide](/learning/reverse-dns-does-not-match-smtp-banner) for the operational case. ### Does a PTR record authenticate email? No. A PTR record publishes a hostname for an IP address. RFC 8601 warns against using reverse mapping as authentication or a security mechanism. SPF, DKIM, and DMARC evaluate different parts of a message and domain identity. --- # How to block spoofed emails Canonical: https://www.palisade.email/learning/how-to-block-spoofed-emails > How to block spoofed emails: use separate inbound email-security controls and domain-authorization controls instead of relying on one blocked message. Blocking a single suspicious email can help with that message, but it is not a durable way to block spoofed emails across an organization. Treat the problem as two separate jobs: protect recipients from impersonation attempts with inbound email-security controls, and control who is authorized to use your organization's domain. These controls address related risks, but neither is evidence that every future impersonation attempt will be stopped. ## Quick takeaways - Blocking one sender or message is different from protecting an organization's domain from unauthorized use. - Inbound email security and domain authorization address different parts of an impersonation problem. - Lookalike sender domains are an impersonation signal, even when the visible sender is not your exact domain. - Business email compromise and VIP impersonation are examples of email-security use cases. - A security assessment can identify questions to investigate, but it cannot prove a receiver's future filtering decision. - Do not treat a single security product claim as proof that all spoofed email will be blocked. ## How blocking spoofed emails works The phrase "block spoofed emails" covers more than one problem. A recipient may be receiving suspicious messages, while an organization may also be concerned about unauthorized messages that appear connected to its brand or people. Inbound email-security controls focus on messages arriving at a mailbox. For example, Abnormal describes its offering as helping stop "BEC, phishing, and account takeover attacks." Its example threat display includes the labels "LOOKALIKE SENDER DOMAIN" and "PAYMENT REDIRECT ATTEMPT," which show the kinds of signals an inbound security product may surface. Those labels are examples of threat context. They do not establish how every email is authenticated or how every mailbox provider will handle a message. [Abnormal's email-security product page](https://abnormal.ai) describes those categories. A separate domain-protection objective is to ensure that trusted senders are the ones using an organization's domain. [IRONSCALES describes DMARC Management](https://ironscales.com) with the outcome, "Ensure only trusted senders can use your domain." That is a useful control objective, but it does not by itself document the record configuration, rollout steps, or handling outcome at a recipient. For the wider set of impersonation and phishing risks, see Palisade's [email threats learning hub](/learning/threats). The important distinction is practical: an inbound control evaluates incoming risk, while a domain-authorization program addresses the organization's own sending identity. ## When the answer changes Choose the next action based on the evidence you have. - If an employee received a suspicious message, preserve the message and use the reporting, investigation, and response process approved for that mailbox environment. The available evidence does not establish a universal rule for blocking, reporting, deleting, or marking that message as spam. - If the concern is a lookalike domain, treat it as an impersonation signal. It is not, by itself, proof of the message's authentication state or the sender's intent. - If the concern is that messages appear to come from your organization's domain, focus on domain authorization and the sending systems your organization approves. The available evidence supports that goal, but not a particular configuration procedure or enforcement result. - If the concern is broad inbox protection, assess inbound email-security controls as part of a wider [email security](/learning) program. Do not collapse these cases into one fix. A mailbox action can be appropriate for a particular suspicious message. It does not establish which systems may use a company domain, and a domain-authorization effort does not replace an organization's process for investigating a suspicious inbound email. > Do not make a DNS or authentication-policy change based only on one suspicious message. First establish which domain, mailbox environment, and approved sending path are actually involved. ![Decision flow separating a suspicious inbound message, a lookalike-domain concern, and a concern about unauthorized use of an organization's domain](/images/editorial/how-to-block-spoofed-emails/how-to-block-spoofed-emails-decision-rule.webp "1200x829") *Source: Palisade.* ## A worked decision rule Use this decision rule to keep an investigation within the evidence available. It is a triage aid, not a guarantee that a message will be blocked or that a sender is legitimate. ```text Illustrative decision rule If the evidence is a suspicious message in one mailbox: Use the mailbox provider's approved reporting and investigation process. If the evidence is a lookalike sender domain: Treat it as an impersonation signal. Assess the message and the recipient risk separately. If the evidence is concern about use of your organization's domain: Identify the approved sending systems. Review domain-authorization controls with the responsible email team. If the evidence is a broad security concern: Review inbound email-security controls and domain protection as separate workstreams. ``` The rule avoids an unsupported shortcut: a suspicious message does not prove that a domain-wide authorization control failed, and a vendor's security alert does not prove a specific authentication result. The same separation applies to business email compromise and VIP impersonation. [IRONSCALES lists Business Email Compromise and VIP impersonation](https://ironscales.com) among its email-security use cases. Those categories help describe the risk under review. They do not reveal why a particular message arrived, whether a recipient will receive another message, or which control will resolve the case. ## What to check next Start with the evidence closest to the problem. For a suspicious message, use the recipient's approved security process and collect only the information that process permits. The available material does not verify a universal mailbox-provider workflow, so follow the documentation and escalation path for the service your organization uses. To decide whether a single message is forged before escalating it, see [how to spot an email sender spoof](/learning/email-address-spoofing-prevention), which covers the visible signals and the header lines that settle it. For an organization-wide concern, write down the exact question before selecting a control: - Is the concern inbound phishing or impersonation attempts against employees? - Is the concern a lookalike sender domain? - Is the concern unauthorized use of the organization's own domain? - Is the concern an approved sender that needs review by the email team? You can also use Palisade's [Email Security Score](/tools/email-security-score) as a starting point for assessing your email-security posture. Review the result with the evidence from the actual message and your approved sending inventory. A public check or score cannot prove the production sending path, a mailbox provider's private filtering decision, continuous security state, or future inbox placement. It also cannot repair a suspicious message or establish that every sender using a domain is approved. ## Review the email-security controls around the incident When the concern extends beyond one message, review the organization-wide controls that cover inbound impersonation risk and domain authorization. [Explore email security](/learning) This guidance cannot determine why a particular mailbox received a message, block a future message, or confirm that all approved senders use the organization's domain correctly. ## Sources and further reading - [Abnormal email security](https://abnormal.ai) - [IRONSCALES email security and DMARC Management](https://ironscales.com) - [Palisade email threats learning hub](/learning/threats) - [Palisade email security guide](/learning) ## Frequently asked questions ### Why do I keep getting spam emails even after blocking them? Blocking stops one sender address, and whoever sent it simply uses a new one. Most spam arrives from a churn of throwaway addresses and lookalike domains, so a personal block list can never keep pace on its own. Use your mailbox provider's report-as-spam control instead of only blocking, because that feeds its filtering rather than just your own mailbox. ### Why am I getting 20 spam emails a day? Volume like that usually means your address sits on lists that get resold and reused, often after it appeared in a breach or on a public page. The count itself does not point to any single cause, and it does not mean your domain has been compromised. Keep this separate from the different question of whether someone is sending mail that looks like it came from your domain. ### Why should you never delete spam emails? You usually can delete them, and that advice is really about preserving evidence rather than about spam in general. Keep a message when your security team needs it for an investigation, or when your mailbox provider asks you to report it first. Otherwise report it, delete it, and do not click anything inside it. ### Can someone spoof my email address? Yes, because nothing in plain email stops someone writing your address into the From line. That is what SPF, DKIM, and DMARC exist to counter, since together they let a receiver check whether a message really came from a sender authorized for your domain. Publishing a DMARC record and working it toward enforcement is how you make spoofing your domain harder. ### Does inbound email security replace domain authorization? No, because the two defend different directions. Inbound email security screens the messages arriving at your people, while domain authorization controls who is allowed to send as your domain. You need both, and in most organizations they sit with different owners and rest on different evidence. --- # How to enable DMARC policy in cPanel? Canonical: https://www.palisade.email/learning/how-to-enable-dmarc-policy-in-cpanel > How to enable DMARC policy in cPanel: confirm your cPanel interface version, find the applicable official instructions, then validate the published DNS. You should enable a DMARC policy in cPanel only by following the official instructions for your exact cPanel interface version and then checking the DNS record that your domain publishes. cPanel's documentation distinguishes interface versions, including Jupiter and Meridian, so an unverified menu path can be wrong for the account in front of you. Do not treat a saved DNS change as proof that mail is using the intended policy. ## Quick takeaways - cPanel publishes version-specific user documentation for interfaces including Jupiter and Meridian. - Confirm the interface version before following any cPanel DNS instructions. - The available cPanel documentation does not establish one universal DMARC settings path. - A DMARC policy must be published for the exact domain whose visible From address needs the policy. - A public DNS lookup can show a published record, but it cannot prove that every production message passes DMARC. - A subdomain can require separate policy consideration from its parent domain. ## How cPanel DMARC configuration works [cPanel's user documentation](https://docs.cpanel.net) says it covers account access, features, and cPanel interfaces, and asks readers to choose an interface version: Jupiter or Meridian. That version choice matters before changing DNS because the available material does not document a single, version-independent cPanel procedure for adding or editing a DMARC record. DMARC is a domain-level email authentication policy. If you need the protocol context before making a DNS change, start with [Palisade's DMARC guide](/learning/dmarc). The practical point for cPanel is narrower: identify the domain, identify the cPanel interface version, and use the official documentation that applies to that interface and account. Do not rely on an unlabeled tutorial, a screenshot from another hosting provider, or a record copied from another organization. DNS records can contain domain-specific reporting destinations and other values that should not be reused without authorization. ![Decision flow for confirming a cPanel interface version and validating the published DMARC record](/images/editorial/how-to-enable-dmarc-policy-in-cpanel/how-to-enable-dmarc-policy-in-cpanel-cpanel-validation-flow.webp "1200x676") *Source: Palisade.* ## When the answer changes The correct next action changes with the evidence you have. - If you do not know whether the account uses Jupiter or Meridian, begin at the [cPanel documentation site](https://docs.cpanel.net) and select the interface version before seeking a DNS procedure. - If your organization has an approved DMARC record and an authorized DNS change process, compare the intended record with the one that DNS currently publishes before changing anything. - If the visible From address uses a subdomain, determine whether that subdomain has its own policy requirements. See [DMARC policy for subdomains](/learning/dmarc-policy-for-subdomains) before assuming that a parent-domain change answers the question. - If a recipient has rejected a message, preserve the delivered-message evidence and the provider's exact error. A public record lookup alone does not establish why that recipient made its decision. The related guidance on a [550 5.7.0 DMARC policy violation](/learning/550-5-7-0-dmarc-policy-violation) addresses that distinct symptom. > Do not publish a copied record from another tenant. A DMARC record can include addresses and controls that belong only to the organization that generated it. The available cPanel material does not confirm whether an account exposes a dedicated DMARC control or requires a general DNS TXT-record change. It also does not document a current validation message, save behavior, or error state. Use the official documentation for the selected cPanel interface rather than inferring those details. ## A safe evidence checklist before enabling the policy Use this decision rule: do not make a DNS change until the account interface, the authorized domain, and the approved record source are all known. ```text Before a cPanel DMARC change: Interface version: Jupiter or Meridian confirmed Domain: the exact visible From domain identified Change authority: DNS owner and approval path confirmed Record source: approved organization-specific DMARC value available Post-change check: authoritative DNS and public DNS lookup planned Message check: real production message headers retained for review ``` This is a change-control checklist, not a DMARC record to publish. The available cPanel documentation does not provide a verified record syntax or a cPanel-specific field mapping, so the actual value must come from your organization's approved configuration or applicable official documentation. After the change is complete, validate at separate layers: - DNS: query the authoritative DNS service and at least one public resolver. - Vendor: check the relevant cPanel or hosting status only if the applicable official interface documentation defines that status. - Message: send a real message through the production application and retain its authentication results. - DMARC: review aggregate-report data after it accumulates. A green hosting-panel indicator and a visible TXT record are different evidence. Neither one proves that the production sender is signing, aligned, or accepted by every receiver. ## What to do next with the evidence you have If you have only a domain name, inspect its currently public DMARC record before requesting or approving a cPanel change. [Check the published DMARC record](/tools/dmarc) Compare the result with the approved record and the exact domain used in the visible From address. If the domain has a cPanel account, use the official documentation for its confirmed interface version to locate the applicable DNS workflow. If you have a delivery failure instead, preserve the raw message headers and the provider's error before changing policy. A published-record check cannot show which production source sent the message, repair a cPanel configuration, monitor later DNS changes, or prove a receiver's private delivery decision. For an ongoing inventory of sending sources and alignment issues, Palisade is agentic DMARC software that analyzes DMARC aggregate-report data, identifies authentication or alignment issues, and proposes a next policy step for human review. It does not autonomously change your cPanel DNS policy or guarantee delivery. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=dmarc_policy_alignment&utm_content=how-to-enable-dmarc-policy-in-cpanel) ## Sources and further reading - [cPanel documentation](https://docs.cpanel.net) - [Palisade DMARC learning hub](/learning/dmarc) - [Palisade DMARC checker](/tools/dmarc) - [DMARC policy for subdomains](/learning/dmarc-policy-for-subdomains) ## Frequently asked questions ### How to enable DMARC in cPanel? Confirm which cPanel interface the account uses, Jupiter or Meridian, then follow the DNS instructions in cPanel's own documentation for that version. Add the DMARC record your organization approved, for the exact domain that appears in your visible From address. After you save it, query both authoritative DNS and a public resolver to confirm the record really published. ### How do you enable a DMARC policy? Publish a DMARC TXT record at `_dmarc.yourdomain.com` for the domain in your From address. Start at `p=none` so you collect reports without changing how receivers handle your mail, then read those reports to find every legitimate sender before you tighten to quarantine or reject. In cPanel, that record goes in whichever DNS editor your interface version provides. ### How to fix DMARC policy not enabled? Start by looking up what `_dmarc` currently publishes for the exact domain in your From address. That phrase comes from whichever checking tool reported it rather than from cPanel, so note which tool said it and which domain it checked. Then compare the published record with the one your organization approved, and check any subdomain separately. ### Does the DMARC policy need to be enabled? Yes for any domain you send business mail from, because without a DMARC record you get no reports and no say in how receivers treat mail that fails authentication. cPanel does not require it and will not decide it for you. How far past `p=none` you go depends on your sending setup and on the requirements of the mailbox providers you send to. ### Does a public DMARC lookup prove that cPanel is configured correctly? No, because a lookup only reads what DNS publishes at that moment. It cannot show which cPanel screen created the record, whether your production mail aligns with it, or how a receiver will handle your next message. Confirm those with a real delivered message and, later, with DMARC aggregate reports. --- # How to improve HubSpot email deliverability Canonical: https://www.palisade.email/learning/hubspot-improve-email-deliverability > HubSpot improve email deliverability by checking sender authentication, message results, and list signals before changing campaign practices. Improve HubSpot email deliverability by treating it as a sending-path diagnosis, not a single platform setting. Confirm that the domain used in the visible From address has aligned SPF or DKIM authentication, inspect headers from real delivered messages, then review list and campaign signals. A successful configuration screen or DNS lookup alone cannot prove that HubSpot messages reach the inbox. ## Quick takeaways - HubSpot deliverability depends on the authentication and reputation evidence receivers see for each message. - DMARC passes when SPF or DKIM passes and aligns with the visible From domain. - A public DNS result can show published records, but it cannot prove HubSpot used them on a production message. - Delivered-message headers provide evidence of SPF, DKIM, and DMARC results for one sending path. - List quality and recipient engagement can affect inbox placement after authentication succeeds. - HubSpot's Knowledge Base offers "Setup, how-to, and troubleshooting guides" for account-specific configuration. ## How HubSpot email deliverability works Email deliverability is the ability to deliver a message to its intended recipient, while inbox placement is the receiver's decision about where an accepted message appears. The distinction matters when improving [email deliverability](/email-deliverability): a message can be accepted but filtered to spam, or it can fail before placement is considered. For a HubSpot campaign, receiving systems evaluate the message that arrives from its actual sending infrastructure. They can inspect the visible From domain, envelope sender, DKIM signature, IP address, content, recipient signals, and their own local policy. HubSpot is the sending platform, but the receiving system makes its own delivery and placement decision. Authentication is an early diagnostic point because it gives a domain owner evidence that the message is authorized to use the visible From domain: - [RFC 7208 defines SPF](https://datatracker.ietf.org/doc/html/rfc7208) as a DNS-based authorization check for the SMTP envelope sender or HELO identity. - [RFC 6376 defines DKIM](https://datatracker.ietf.org/doc/html/rfc6376) as a signed message authentication mechanism. - [RFC 7489 defines DMARC](https://datatracker.ietf.org/doc/html/rfc7489) as a policy and reporting framework that evaluates SPF and DKIM in relation to the visible From domain. A passing authentication result supports deliverability. It does not guarantee inbox placement, because a receiver can still apply its own reputation, content, and user-signal assessments. ## When the answer changes The right next action depends on the evidence you have. Use this decision rule: - If you only know the sending domain, inspect its public authentication posture first. - If you have a delivered campaign message, inspect its raw headers before changing DNS or campaign behavior. - If authentication passes on the delivered message but inbox placement is poor, investigate recipient engagement, list acquisition practices, message content, and receiver-specific signals through the relevant mailbox-provider tools or reports. - If different HubSpot campaigns use different visible From domains or sending paths, validate each path separately. One passing message does not prove that every campaign authenticates the same way. - If HubSpot shows an account-level status that conflicts with message headers, treat the headers as evidence of what the receiving system processed for that message and use HubSpot's [Knowledge Base](https://knowledge.hubspot.com/) for the account-specific path. Do not copy DNS records from another HubSpot account or an online example. Authentication records, selectors, CNAME targets, and verification values can be generated for a specific account or domain. Use the values shown in your own HubSpot configuration and publish them only in the DNS zone you control. > A DNS record check and a green platform status do not prove a real campaign message passed DMARC. Send a controlled message through the production HubSpot path and inspect its received headers. ![Decision flow for improving HubSpot email deliverability based on available DNS, message-header, and placement evidence](/images/editorial/hubspot-improve-email-deliverability/hubspot-improve-email-deliverability-diagnostic-flow.webp "1200x676") *Source: Palisade.* ## A worked authentication example A delivered message can contain an `Authentication-Results` header. [RFC 8601 defines this header field](https://datatracker.ietf.org/doc/html/rfc8601) for reporting message-authentication results. The exact wording and properties vary by receiver, but the result can help separate an authentication problem from an inbox-placement problem. ```text Authentication-Results: receiver.example; spf=pass smtp.mailfrom=mail.yourdomain.com; dkim=pass header.d=yourdomain.com; dmarc=pass header.from=yourdomain.com ``` This illustrative example supports a narrow conclusion: for that message, the receiver reported SPF and DKIM passes, and reported a DMARC pass for `yourdomain.com`. It does not show that every HubSpot message uses the same path. It also does not prove the message reached the inbox, that future campaigns will receive the same treatment, or that all recipients see the same result. If the header instead reports `dmarc=fail`, compare the visible From domain with the SPF identity and DKIM `d=` domain. DMARC needs an aligned SPF or DKIM pass. If both SPF and DKIM pass but neither aligns with the visible From domain, DMARC can still fail. ## What to check next Start with the evidence available to you, in this order: - Check the domain's public records if you have only a domain name. Look for SPF, DKIM, and DMARC publication, then compare them with the account-generated values in HubSpot. The [ESP setup hub](/learning/esp-setup) covers the broader task of validating sender-domain configuration for email platforms. - Send a controlled campaign or test through the same HubSpot configuration used for production. Save the raw headers from a delivered copy and identify the SPF, DKIM, and DMARC results. - Compare results across important message types. Marketing messages, lifecycle emails, and automated notices can use different From domains, reply-to addresses, or sender paths. - If authentication is sound, use HubSpot's official setup and troubleshooting material to investigate the account-specific sending configuration. Its Knowledge Base is intended for setup, how-to, and troubleshooting guidance. - Review placement evidence by recipient domain where available. A result at one mailbox provider does not establish the cause of filtering at another provider. For a first public check, run the domain through Palisade's [email security score](/tools/email-security-score). It can help identify publicly visible email-authentication gaps before you change campaign cadence or make list decisions. ## Check the domain before changing HubSpot campaigns A public check is a useful first step when the only evidence you have is the sending domain. Inspect the authentication posture, then compare the result with a real message header from the HubSpot production path. [Check the email security score](/tools/email-security-score) A public-domain check cannot prove HubSpot used the published records, identify a receiver's private inbox decision, repair campaign configuration, or guarantee future inbox placement. If your team manages several HubSpot sending domains, the unresolved gap is ongoing sender inventory and DMARC alignment evidence across each production path. Palisade is agentic DMARC software that analyzes DMARC aggregate-report data, identifies sending sources and authentication or alignment issues, and proposes the next policy step for human review. It does not change DMARC policy automatically or guarantee delivery. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=email_deliverability&utm_content=hubspot-improve-email-deliverability) ## Sources and further reading - [HubSpot Marketing Hub](https://hubspot.com/) - [HubSpot Knowledge Base](https://knowledge.hubspot.com/) - [RFC 7208: Sender Policy Framework](https://datatracker.ietf.org/doc/html/rfc7208) - [RFC 6376: DomainKeys Identified Mail](https://datatracker.ietf.org/doc/html/rfc6376) - [RFC 7489: Domain-based Message Authentication, Reporting, and Conformance](https://datatracker.ietf.org/doc/html/rfc7489) - [RFC 8601: Authentication-Results header field](https://datatracker.ietf.org/doc/html/rfc8601) ## Frequently asked questions ### Can HubSpot improve email deliverability by itself? No, HubSpot cannot do it alone, because the receiving system makes its own delivery and placement decision for every message. HubSpot sends the campaign, so your job is to improve what receivers see. Start with an aligned SPF or DKIM pass on real delivered messages, then look at list quality and recipient engagement. ### Does a HubSpot authentication status prove DMARC passes? No, a HubSpot account status only confirms part of the configuration on HubSpot's side. A delivered message header shows the result the receiving system actually reported for that sending path. Check the visible From domain, the SPF identity, the DKIM `d=` domain, and the DMARC result together. ### Should I change my sending domain after a spam-folder result? Hold off until you have read the authentication results in a delivered message and traced the campaign's sending path. A spam-folder result can have causes that have nothing to do with the visible From domain, including recipient-specific filtering and sender reputation signals. Changing the domain first moves the campaign without explaining the result. ### Can a public email security check show HubSpot inbox placement? No, a public check cannot show inbox placement. It inspects published DNS and authentication posture, which tells you nothing about your HubSpot account configuration, a receiver's private filtering decision, or where a future campaign will land. ### Where can I find HubSpot-specific setup instructions? Use the [HubSpot Knowledge Base](https://knowledge.hubspot.com/) for current setup, how-to, and troubleshooting guidance. Follow the instructions for your own account because generated authentication values and available options can differ by configuration. --- # Is one-click unsubscribe mandatory? Canonical: https://www.palisade.email/learning/is-one-click-unsubscribe-mandatory > Is one-click unsubscribe mandatory? Gmail requires it for qualifying bulk marketing and subscribed mail. Learn the scope, dates, headers, and checks. Yes, one-click unsubscribe is mandatory for marketing and subscribed messages sent by bulk senders to personal Gmail accounts. Gmail defines a bulk sender as one that sends close to 5,000 messages or more to personal Gmail accounts in a 24-hour period, and its requirements began on February 1, 2024. It is not a universal requirement for every email or every mailbox provider, and transactional messages are excluded from Gmail's one-click rule. ## Quick takeaways - Gmail requires qualifying bulk senders to support one-click unsubscribe for marketing and subscribed messages. - Gmail's bulk-sender threshold is close to 5,000 messages or more to personal Gmail accounts in a 24-hour period. - Transactional messages such as password resets, purchase receipts, and one-time passwords are excluded from Gmail's one-click unsubscribe requirement. - RFC 8058 defines the HTTPS header and POST mechanism used for one-click unsubscribe. - A visible unsubscribe link in the message body does not replace Gmail's required one-click headers. - One-click unsubscribe is a mailbox-provider requirement, not a universal legal rule for all messages and jurisdictions. ## Who is affected? Gmail's [Email sender guidelines](https://support.google.com/mail/answer/81126) apply the one-click unsubscribe requirement to senders that send close to 5,000 messages or more to personal Gmail accounts in a 24-hour period. The affected traffic is marketing and subscribed mail. Gmail's [sender-guidelines FAQ](https://support.google.com/mail/answer/14229414) says transactional messages are excluded. Its examples include password reset messages, reservation confirmations, form-submission confirmations, purchase receipts, and one-time passwords. The requirement is based on the traffic sent to Gmail accounts, not solely on a sender's total database size. A sender that is below the threshold today can cross it during a campaign, so teams should classify message streams before a volume increase. The sender or its email service provider must add the headers and operate the HTTPS endpoint. The mailbox provider decides whether to display an unsubscribe control to its users. Implementing the headers does not require Gmail to render a button for every message. For wider context, the [sender requirements guide](/learning/gmail-bulk-sender-guidelines) tracks mailbox-provider requirements that sit alongside authentication, alignment, and spam-rate controls. These requirements affect [email deliverability](/email-deliverability), but they do not guarantee inbox placement. ## What are the requirements? ### The message must support RFC 8058 one-click unsubscribe Gmail says qualifying bulk senders' marketing and subscribed messages must support one-click unsubscribe. Its implementation guidance requires both headers below, with an HTTPS URL in `List-Unsubscribe`. ```text List-Unsubscribe: <https://unsubscribe.yourdomain.com/list/opaque-token> List-Unsubscribe-Post: List-Unsubscribe=One-Click ``` The URL and token are illustrative only. Generate the actual recipient-specific endpoint in the sending platform or subscription system. Do not publish real recipient identifiers or reusable unsubscribe tokens. [RFC 8058](https://datatracker.ietf.org/doc/html/rfc8058) is an IETF Standards Track RFC published in January 2017. It defines the mechanism that signals one-click functionality for list email. The RFC requires a `List-Unsubscribe` field containing an HTTPS URI and a `List-Unsubscribe-Post` field with the `List-Unsubscribe=One-Click` value. ![Decision checklist showing when Gmail one-click unsubscribe applies and the required headers](/images/editorial/is-one-click-unsubscribe-mandatory/is-one-click-unsubscribe-mandatory-decision-checklist.webp "1200x639") *Source: Palisade.* ### The unsubscribe endpoint must process the POST directly Gmail documents the one-click request as an HTTP POST with the following body: ```text List-Unsubscribe=One-Click ``` RFC 8058 says the sender **MUST NOT** return an HTTPS redirect in response to the one-click POST. The endpoint cannot rely on a browser session, login, cookie, preference form, or a confirmation page to complete the removal. A normal visible unsubscribe link can still take a recipient to a preference center. That body link has a different role. Gmail's FAQ says a `mailto` link or a web unsubscribe link by itself does not meet its one-click requirement. ### The message needs a visible body unsubscribe link too Gmail's bulk-sender guidelines require marketing and subscribed messages to support one-click unsubscribe and include a clearly visible unsubscribe link in the message body. The two controls are not substitutes for each other. The header-based path lets a mailbox provider request removal without a browser navigation. The body link gives the recipient a direct, visible route to unsubscribe or manage preferences. Keep the body link usable even when the mailbox interface does not display an unsubscribe control. ### The headers must be covered by a valid DKIM signature RFC 8058 requires at least one valid DKIM signature to cover both `List-Unsubscribe` and `List-Unsubscribe-Post`. A message can have a passing DKIM status while still failing this specific condition if its signed-header list does not include both fields. Inspect the delivered message headers. Check the `h=` value in the valid DKIM signature and verify that both one-click fields appear in it. A sending platform's authentication status is not proof that the production message included and signed the required unsubscribe headers. ## When does the requirement take effect? Gmail's general sender requirements, including the bulk-sender requirements, took effect on February 1, 2024. Gmail's FAQ says senders that already included an unsubscribe link had until June 1, 2024 to implement one-click unsubscribe for commercial and promotional messages. Gmail has also stated that, starting in November 2025, it was ramping up enforcement for traffic that does not meet its sender requirements. Its current guidance says missing one-click unsubscribe can make qualifying bulk senders ineligible for delivery mitigations. Gmail does not say that every individual message missing one-click unsubscribe is automatically rejected or marked as spam. RFC 8058 itself has no bulk-sender threshold or enforcement date. It defines the protocol. Gmail defines when qualifying senders must use it. ## How do I implement the requirement? ### 1. Classify the sending stream Separate marketing and subscribed traffic from transactional traffic. Identify every platform, subdomain, and From address that sends covered mail to Gmail recipients. Do not classify a message as transactional only because it contains an account notice. If it also promotes products, newsletters, or optional campaigns, review it against Gmail's subscription-message guidance. ### 2. Create a recipient-specific HTTPS endpoint Generate an opaque URL that lets the subscription system identify the recipient and mailing list without requiring a login. The endpoint should process an already-unsubscribed recipient safely, because a valid request may be repeated. Do not use a token that exposes a plain email address in the URL. Limit logging of the complete URL because it can contain recipient-linked data. ### 3. Add the two headers before DKIM signing Configure the sending platform to add `List-Unsubscribe` and `List-Unsubscribe-Post` to every covered message before DKIM signing occurs. Confirm that the DKIM signer includes both headers in its signed-header list. If a third-party platform cannot add these headers or cannot sign them correctly, use that provider's documented one-click unsubscribe feature or raise the gap with its support team. ### 4. Keep the body unsubscribe link visible Add a clearly visible unsubscribe link in the HTML and text versions of covered messages. The link may lead to a preference center, but it cannot replace the RFC 8058 header-based action. ### 5. Process the POST without browser context Accept the `List-Unsubscribe=One-Click` request at the HTTPS endpoint and update the suppression state used by the relevant sending list. Return a direct response rather than redirecting the request to a web page. > Do not test a one-click endpoint with a production recipient unless the recipient can safely be suppressed. Use a controlled test address and verify which list the request removes it from. ## How do I validate compliance? Validate the implementation at four layers. - **DNS:** Confirm the sending domain's public authentication records resolve from the authoritative DNS service and a public resolver. DNS alone does not prove that the application added one-click headers. - **Vendor:** Check the sending platform's current authentication and unsubscribe configuration. A green vendor status does not prove the headers appeared on a delivered production message. - **Message:** Send a covered message through the exact production path to a controlled Gmail mailbox. Inspect the raw headers for `List-Unsubscribe`, `List-Unsubscribe-Post`, and a valid DKIM signature whose `h=` list covers both fields. - **DMARC:** Review aggregate-report data after traffic accumulates to confirm the production sources and aligned authentication results. One-click unsubscribe is separate from DMARC authentication, but the same sending inventory helps find platforms that were missed. Test the endpoint with the RFC 8058 POST body, then verify that the recipient is suppressed in the system that controls the relevant list. Repeat the request to confirm that it does not create duplicate work. Test that the endpoint does not require cookies, HTTP authentication, or a redirect. The [Gmail one-click unsubscribe requirements](/learning/gmail-one-click-unsubscribe) article covers the Gmail-specific implementation context. An [email security score](/tools/email-security-score) can check public sender-security posture, but it cannot inspect a recipient-specific unsubscribe endpoint, a delivered message's signed headers, or Gmail's private delivery decisions. ## Check the current sender requirement for your traffic Use the [sender requirements guide](/learning/gmail-bulk-sender-guidelines) to compare the mailbox-provider rules with your actual message type and Gmail sending volume. One-click unsubscribe is mandatory only within the provider and traffic scope that requires it. That guide cannot prove that a particular production message contained valid headers, that an unsubscribe endpoint processed a request, or that Gmail will display an unsubscribe control. ## Sources and further reading - [RFC 8058: Signaling One-Click Functionality for List Email Headers](https://datatracker.ietf.org/doc/html/rfc8058) - [Gmail email sender guidelines](https://support.google.com/mail/answer/81126) - [Gmail email sender guidelines FAQ](https://support.google.com/mail/answer/14229414) - [FTC CAN-SPAM Act compliance guide](https://www.ftc.gov/business-guidance/resources/can-spam-act-compliance-guide-business) ## Frequently asked questions ### Is one-click unsubscribe a law? No, one-click unsubscribe is not a law in itself. RFC 8058 is a technical standard, and Gmail's one-click rule is a requirement Google places on senders. Laws vary by jurisdiction and message type: in the United States, the FTC says the CAN-SPAM Act requires commercial email to offer a clear way to opt out, without making RFC 8058 headers a legal requirement. ### Why should I not click unsubscribe? The one good reason to avoid an unsubscribe link is a message you cannot verify, because the link may belong to a phishing attempt rather than a real list. The FTC advises consumers not to engage with unexpected phishing messages. For mail you knowingly subscribed to, unsubscribing is the right way to stop it. ### Is an unsubscribe facility mandatory? Yes in many cases, though the exact obligation depends on the mailbox provider, the message type, your sending volume, and the law where you send. Gmail requires one-click unsubscribe for qualifying bulk marketing and subscribed mail. Separately, United States commercial email must offer a clear opt-out method under the CAN-SPAM Act. ### Is it illegal to not have an unsubscribe option? It can be, depending on the jurisdiction and the type of message. In the United States, commercial email covered by the CAN-SPAM Act must include a clear opt-out mechanism. Rules elsewhere differ, so take legal advice for the jurisdictions and message categories your organization sends to. --- # Kitterman SPF checker: interpret and retest an SPF lookup Canonical: https://www.palisade.email/learning/kitterman-spf-checker > Kitterman SPF checker results explained: inspect the public SPF record, repair evidenced DNS issues, check lookup limits, and retest safely. A Kitterman SPF checker lookup can show the SPF policy currently published in public DNS, but it cannot prove that a production message used that policy or passed SPF at its recipient. Use the lookup to identify the exact DNS issue, make a narrow correction, then retest the same hostname. Confirm delivery separately with headers from a new message. ## Quick takeaways - An SPF checker reads the public TXT record for the domain's SPF identity. - SPF permits only one record beginning with `v=spf1` for a domain. - SPF evaluation has a limit of 10 DNS lookups during a single check. - A valid public SPF record does not prove that an application sent with the expected envelope sender. - Keep a copy of the returned record and lookup count before changing DNS. - Use a delivered message's authentication results to confirm the production path after a DNS repair. ## What this tool checks A Kitterman SPF checker is useful for a one-off inspection of a domain's published SPF policy. For a current public-DNS check, use the [Palisade SPF checker](/tools/spf). Enter the domain that appears in the SMTP envelope sender or, when that evidence is unavailable, the domain whose public SPF policy you need to inspect. The checker returns public DNS evidence: the SPF record it found, a validity finding, its lookup count, and detected senders. That supports a DNS diagnosis. It cannot see which outbound application generated a message, its `MAIL FROM` identity, its headers, a receiver's private filtering decision, or changes that occur after the lookup. SPF authorizes hosts for a domain used in the SMTP transaction. [RFC 7208 defines the SPF record format and evaluation rules](https://www.rfc-editor.org/rfc/rfc7208). It is one part of email authentication, alongside the concepts explained in [Palisade's email authentication guide](/learning). A public DNS result is useful evidence, but it is not a message-delivery test. ## How to run the check ### 1. Choose the SPF identity to inspect Start with the envelope sender domain from a delivered message if you have one. In an `Authentication-Results` header, this commonly appears as `smtp.mailfrom`. That identity can differ from the visible From address, so do not assume the visible domain is the one SPF evaluated. [RFC 8601 defines the Authentication-Results header field and its properties](https://www.rfc-editor.org/rfc/rfc8601.html). If no message is available, inspect the domain whose SPF record you plan to change. Record the hostname before opening a checker so you can retest the identical target later. ### 2. Run the public SPF lookup Submit the hostname to the [Palisade SPF checker](/tools/spf). Save the returned SPF record, validity finding, lookup count, and detected-sender list. Those fields establish what was publicly visible at that time. You can repeat the public lookup from a terminal with an example domain: ```bash dig +short TXT yourdomain.com ``` Look for the single TXT value that begins with `v=spf1`. The command may return other TXT records that are unrelated to SPF. A resolver answer is still public-DNS evidence. It does not show whether the exact production sender used this record. ![SPF record interpretation map showing one SPF TXT record, lookup-limit review, and message validation](/images/editorial/kitterman-spf-checker/kitterman-spf-checker-records.webp "1200x600") *Source: Palisade.* ### 3. Preserve message evidence before changing DNS If the lookup relates to a delivery failure, send a new test through the same application, account, sender identity, and recipient path. Open the received message's raw headers and preserve the receiver-added `Authentication-Results` value. A DNS checker may show a syntactically valid policy while the production message uses another envelope sender or does not pass SPF. For a header-led investigation, use the related guide on [checking DMARC alignment](/learning/check-dmarc-alignment). Keep the lookup result and the delivered-message result as separate observations. ![Palisade SPF checker showing a public SPF lookup result for the inspected domain](/images/editorial/kitterman-spf-checker/kitterman-spf-checker-shot-1.png "1600x900") *Source: https://www.palisade.email/tools/spf?domain=gmail.com* ## How to interpret the results ### A single valid SPF record is returned A valid result means the checker found one publicly visible SPF record beginning with `v=spf1` and could evaluate its published structure. It does not mean every listed sending service is active, every message uses the policy, or every recipient will accept a message. Review each mechanism in the returned policy. An `include:` delegates part of the evaluation to another domain's SPF policy. An `ip4:` or `ip6:` mechanism authorizes specified addresses. The terminal `all` mechanism sets the result for senders that did not match earlier mechanisms. [RFC 7208 describes these SPF mechanisms and their evaluation](https://www.rfc-editor.org/rfc/rfc7208). ### No SPF record, or an invalid SPF policy, is returned First confirm the queried domain. SPF applies to the identity being evaluated, not automatically to the visible From domain. Then inspect the authoritative DNS provider to determine whether the TXT record is absent, published under the wrong hostname, or malformed. Do not add an SPF record beside an existing one without checking first. The repair target is the exact SPF identity and its existing TXT records. If an application generated a record for setup, copy only the value generated for your account and domain. Never reuse a record from another tenant. ### More than one SPF record is present A domain must not publish multiple SPF records. [RFC 7208 treats multiple SPF records as a permanent error](https://www.rfc-editor.org/rfc/rfc7208.html#section-4.5). Consolidate the authorized mechanisms into one policy, then remove or replace the duplicate SPF TXT value according to your DNS provider's record editor. > Removing a record can stop legitimate mail from passing SPF. Before consolidation, inventory every authorized `include:`, `ip4:`, `ip6:`, `a:`, and other active mechanism from the existing policy. For a focused duplicate-record repair workflow, see [how many SPF records a domain can have](/learning/how-many-spf-records-per-domain). ### The lookup count reaches or exceeds the limit SPF has a maximum of 10 DNS lookup-causing terms during evaluation. The count can include nested `include:` mechanisms, so a short-looking record may still exceed the limit. [RFC 7208 section 4.6.4 specifies the limit](https://www.rfc-editor.org/rfc/rfc7208.html#section-4.6.4). Treat a high count as a maintenance issue before it becomes a failure. Remove services that no longer send mail, verify whether overlapping includes are still needed, and ask each active sender which SPF authorization it requires. Do not flatten a record by copying addresses from an unrelated domain or from an outdated supplier article. Address ownership can change. ### The detected-sender list needs review A detected-sender list reflects mechanisms visible in the published policy. It is an inventory starting point, not proof that each source currently sends for the domain. Compare it with approved sender records and a message from each important production path. A sender can pass SPF with an unaligned envelope domain. If DMARC is the concern, compare the SPF identity with the visible From domain and inspect the DKIM result as well. [Why Brevo does not provide SPF alignment by default](/learning/brevo-spf-alignment) illustrates why SPF authorization and DMARC alignment are separate questions. ## How to act on the result Repair only the issue established by the public result. For a missing or malformed record, obtain the current record value from the sending service that requires authorization, then publish it at the correct root domain. For duplicates, merge only known, active authorization mechanisms into one SPF policy. For excessive DNS lookups, remove stale sender entries before considering structural changes. Then validate at four layers: - Check the authoritative DNS provider and at least one public resolver for the corrected TXT answer. - Confirm the sending service still reports the intended domain or authentication setup. - Send a new message through the same production route and inspect `Authentication-Results`. - Review DMARC aggregate-report data after it accumulates to find sources or alignment failures that a one-off SPF lookup cannot expose. For recurring SPF updates, [Palisade Hosted SPF documentation](https://docs.palisade.email/page-breakdowns/hosted-spf/) describes an optional model where the root SPF record delegates through one `include:` mechanism and Palisade publishes the included updates. Its setup requires copying every existing authorization into the Hosted SPF configuration before publishing the new root record. Hosted SPF does not validate sender alignment or guarantee delivery. ## Investigate this with your coding agent Use this after you have saved a redacted public SPF result and a redacted header from the affected message. Do not include private keys, tokens, full recipient addresses, or customer message content. ```agent Problem: A public SPF lookup for yourdomain.com reports a missing, duplicate, invalid, or lookup-limit SPF policy. Evidence: Redacted checker result for yourdomain.com, returned v=spf1 value, lookup count, and redacted Authentication-Results with smtp.mailfrom. Repository scope: DNS-as-code files or deployment configuration that publishes TXT records for yourdomain.com. Constraints: Inspect before editing. Do not apply changes until I approve the proposed diff. Do not alter unrelated TXT records, credentials, private keys, tokens, or production DNS. Requested output: Diagnosis, minimal proposed change, rollback, and unknowns. Verification: Query dig +short TXT yourdomain.com, rerun the same public SPF lookup, then send a new message through the same production path and inspect Authentication-Results. Stop if: Credentials, private data, production mutation, or missing evidence is required. ``` ## How to retest Wait until the authoritative DNS provider shows the intended answer, then repeat the same public lookup for the exact hostname. The expected change is narrow: one valid SPF record, with the corrected mechanism set and a lookup count below the evaluation limit where that was the issue. Next, send a new message through the same source that exposed the problem. Check the recipient's `Authentication-Results` field for the `smtp.mailfrom` identity you intended to authorize. A passing public lookup without that message evidence leaves the production-path question open. ## Check the published SPF policy after the repair Recheck the exact SPF identity after the DNS answer changes, then compare the result with a new message from the affected sender. [Check the SPF policy](/tools/spf) A public record check cannot repair DNS, prove that a particular production message used the record, monitor later changes, or guarantee delivery. If recurring sender inventory or alignment issues remain after the immediate repair, Palisade can analyze DMARC aggregate-report data, identify sending sources and authentication or alignment issues, and create prioritized remediation tickets. It does not change DNS or control a receiver's filtering decision. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=email_authentication&utm_content=kitterman-spf-checker) ## Sources and further reading - [RFC 7208: Sender Policy Framework](https://www.rfc-editor.org/rfc/rfc7208) - [RFC 8601: Authentication-Results header field](https://www.rfc-editor.org/rfc/rfc8601.html) - [Palisade SPF checker](/tools/spf) - [Palisade Hosted SPF documentation](https://docs.palisade.email/page-breakdowns/hosted-spf/) ## Frequently asked questions ### Does a valid SPF checker result prove that email will be delivered? No. It proves only that the public SPF policy could be evaluated at the time of the lookup. Delivery also depends on the production sending path, message authentication results, recipient policy, and other receiver decisions. ### Can a domain have two SPF TXT records? No. A domain must have one SPF record beginning with `v=spf1`. Multiple SPF records produce an SPF permanent error under RFC 7208. ### Does every include count as one SPF lookup? Not always. An `include:` causes evaluation of another policy, and nested mechanisms can cause further DNS lookups. Count the complete evaluation path, not only the mechanisms visible in the root record. ### Should I change SPF after one failed message? Only when the message evidence and public DNS result identify an SPF authorization problem. First verify the envelope sender domain and the receiver's `Authentication-Results`, because the visible From domain may not be the identity SPF evaluated. ### Can Hosted SPF fix DMARC alignment? No. Hosted SPF manages SPF record updates through a delegated include. DMARC SPF alignment still depends on the domain used in the production message's envelope sender and the visible From domain. --- # Lemlist email warmup: what Lemwarm does and cannot prove Canonical: https://www.palisade.email/learning/lemlist-email-warmup > Lemlist email warmup uses Lemwarm to send warm-up activity and track deliverability signals, but its score alone does not prove inbox placement. Lemlist email warmup refers to Lemwarm, Lemlist's included automated warm-up and deliverability product. Lemwarm says it creates inbox activity through its network, tracks a deliverability score, and flags risks related to sending behavior and content. Those signals can help assess an inbox before a campaign, but they do not prove that a real production campaign will reach a recipient's inbox. ## Quick takeaways - Lemlist says every Lemlist seat includes Lemwarm, its automated warm-up and deliverability booster. - Lemwarm says its network includes more than 20,000 healthy domains in more than 100 countries. - Lemwarm reports a deliverability score and alerts for risks related to sending behavior and content. - Lemwarm recommends about four weeks of warm-up, then two more weeks before real campaigns begin. - A warm-up score is a product-provided signal, not receiver-side proof of inbox placement. - SPF, DKIM, DMARC, MX records, sending volume, list quality, and content can all affect deliverability risk. ## How Lemlist email warmup works [Lemlist describes Lemwarm as an automated warm-up and deliverability booster included with every Lemlist seat](https://lemlist.com). The associated [Lemwarm product page](https://lemwarm.com) says its service warms inboxes across a network of more than 20,000 healthy domains in more than 100 countries, with "Real inboxes, real replies, no bots." The vendor also says Lemwarm monitors a deliverability score and detects spam risks that may affect campaigns based on sending behavior and content. That makes it a vendor-provided monitoring signal for the connected inbox. It is part of the broader work described in [email deliverability](/email-deliverability), where technical authentication, sender behavior, and receiver-specific decisions all matter. Lemwarm identifies several risk categories: - Missing or misconfigured SPF, DKIM, DMARC, or MX records. - Sudden sending-volume increases. - Unverified recipient lists. - Content risks. These categories are useful checks, but they are not a complete model of why a specific receiver accepted, filtered, or placed a message. A mailbox provider can make its own decision using signals that a warm-up product cannot observe. ![Flow showing how Lemwarm activity and alerts can inform a sending decision without proving inbox placement for a real campaign](/images/editorial/lemlist-email-warmup/lemlist-email-warmup-decision-flow.webp "1200x676") *Source: Palisade.* ## When a Lemwarm score changes the answer Use a Lemwarm score or alert as an input to investigate, not as the final answer to "Will this campaign land in the inbox?" The answer changes with the evidence available: - If Lemwarm identifies an SPF, DKIM, DMARC, or MX issue, inspect the published technical configuration before raising production volume; for a routing alert, [check which MX records the domain publishes](/tools/mx). [What SPF is](/learning/what-is-spf) explains one part of the authentication layer. - If the score shows a risk after a volume increase, compare the planned campaign volume with recent sending behavior. A warm-up pattern does not establish that a larger campaign has the same receiver response. - If the score flags content or list risk, test the approved campaign through the real sending path and review the list's collection and consent process. - If recipients report spam placement or messages are missing, collect message headers and delivery evidence from the exact campaign path. The warm-up score alone cannot explain a recipient's mailbox decision. Lemwarm's stated onboarding recommendation is about four weeks of warm-up, followed by two more weeks before starting real campaigns. It also recommends leaving Lemwarm running afterward. This is [Lemwarm's product guidance](https://lemwarm.com), not a Gmail, Outlook, or other receiver requirement. It does not guarantee sender reputation, acceptance, spam avoidance, or inbox placement. For a broader discussion of automated warm-up products and their limits, see [AI email warmup: what it is and what it cannot prove](/learning/ai-email-warmup). ## A practical decision rule for Lemlist email warmup Treat the result as a signal that determines the next check: ```text Illustrative only Lemwarm score or alert | |-- Authentication or MX risk appears | -> Check SPF, DKIM, DMARC, and MX records. | |-- Volume, list, or content risk appears | -> Review the real campaign plan and test a controlled production path. | |-- No risk appears -> Do not assume inbox placement. Send a real test and inspect its results. ``` A passing warm-up signal does not establish four separate layers of evidence. - **DNS:** The intended SPF, DKIM, DMARC, and MX records resolve through authoritative DNS and a public resolver. - **Vendor:** Lemwarm or the sending provider reports its own connection or risk status. - **Message:** A delivered message from the real campaign path shows the relevant authentication results in its raw headers. - **DMARC:** Aggregate reports show which sources are using the visible From domain and whether their SPF or DKIM identifiers align. A green result at the vendor layer does not replace a delivered-message check. It also cannot reveal every later change to DNS, sending sources, campaign content, list quality, or a mailbox provider's private placement decision. ## What to check before starting a real campaign Start with the evidence you already have. If you have a Lemwarm alert about technical setup, check the domain's public authentication and mail-routing signals. If your concern is campaign behavior, compare the planned list, content, and volume with the activity that produced the alert. If mail has already been sent, inspect a real delivered message and the sending platform's delivery evidence. Lemwarm says Gmail and Outlook can connect in one click, and lists Zoho, FastMail, and Proton as other supported providers. The available vendor statements do not establish the current setup screens, whether warm-up starts automatically, or the precise controls available for each provider. Use [Lemlist's Help Center](https://help.lemlist.com) for current provider and technical-setup instructions. A public diagnostic can help find visible domain issues before a campaign starts. It cannot validate the private connection state of a Lemlist inbox, prove a production message used the expected signing path, or predict recipient inbox placement. ## Check the domain signals behind a Lemwarm alert If Lemwarm identifies a technical risk, inspect the public SPF, DKIM, DMARC, MX, and related email-security signals for the sending domain before changing campaign volume. [Check the email security score](/tools/email-security-score) A public domain check cannot prove that Lemwarm is configured correctly, repair a campaign, monitor future sender behavior, or show how a specific recipient mailbox will place a message. For teams that need ongoing visibility after launch, Palisade autonomously analyzes DMARC aggregate-report data, identifies sending sources and authentication or alignment issues, and creates prioritized remediation tickets. It can propose the next DMARC policy step when the evidence supports it, while a human reviews the evidence and applies the change. It does not control Lemwarm, change a mailbox provider's placement decision, or guarantee delivery. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=warmup_sending_practices&utm_content=lemlist-email-warmup) ## Sources and further reading - [Lemlist product page](https://lemlist.com) - [Lemwarm product page](https://lemwarm.com) - [Lemlist Help Center](https://help.lemlist.com) - [Palisade email security score](https://www.palisade.email/tools/email-security-score) ## Frequently asked questions ### Is Lemwarm included with Lemlist? Yes, Lemwarm comes with every Lemlist seat. Lemlist says each seat includes its built-in deliverability tools, and Lemwarm is one of them. ### Does Lemwarm guarantee inbox placement? No, Lemwarm cannot guarantee placement, because receiving mail systems make that decision themselves. Lemwarm gives you a score and risk alerts, and Lemlist does not claim those signals confirm where a real campaign lands. ### How long does Lemwarm recommend warming up an inbox? Lemwarm recommends about four weeks of warm-up, then two more weeks before starting real campaigns. It recommends leaving the service running afterward. This is vendor guidance, not a universal mailbox-provider rule. ### Can Lemwarm identify DMARC problems? Lemwarm can point at a DMARC problem only indirectly, through the risk categories it flags. It lists missing or misconfigured SPF, DKIM, DMARC, and MX records among common deliverability concerns, which can point you at a problem without diagnosing it. Confirm the actual DNS records and check a real production message before treating the issue as resolved. ### Does a good warm-up score mean a campaign is safe to send? No, a good score does not make a campaign safe to send, because it says nothing about the campaign itself. Your list, volume, content, and sending path all still shape the result, and each receiver decides placement on its own. Treat the score as a reason to keep checking, not as a green light. --- # Lemwarm email warmup Canonical: https://www.palisade.email/learning/lemwarm-email-warmup > Lemwarm email warmup exchanges emails through its network and reports a daily score. Learn what its score can indicate and what to verify separately. Lemwarm email warmup is Lemwarm's service for warming an inbox through email exchanges in its network while showing a daily deliverability score. Lemwarm says it exchanges "safe, real emails" with a network of "20,000+ real users." That score may be a useful product signal, but it does not independently prove inbox placement, sender reputation at a particular receiver, or that your production messages authenticate correctly. ## Quick takeaways - Lemwarm describes itself as an email warm-up and deliverability tool. - Its homepage says the service exchanges warm-up emails through a network of real users. - Lemwarm says it checks email setup and displays a daily score. - Lemwarm's suggested timeline is about four weeks of warm-up, then two more weeks before real campaigns. - A warm-up score does not prove how Gmail, Outlook, or another receiver will place a future campaign. - Check SPF, DKIM, DMARC, and MX records separately before increasing send volume. ## How Lemwarm email warmup works According to the [Lemwarm homepage](https://lemwarm.com), the service "Warms up your inbox by exchanging safe, real emails with a network of 20,000+ real users." Lemwarm also says it "Checks your email setup so Gmail and Outlook trust you as a sender" and "Shows you a daily score so you know your emails are safe to send." Those statements describe Lemwarm's product and its intended use. They do not establish that a specific score predicts inbox placement at a given mailbox provider. Inbox placement is a receiver-controlled outcome. A receiver can consider authentication, sending reputation, content, recipient engagement, local policy, and other unpublished signals. Lemwarm says it connects with Gmail and Outlook "in one click" and that providers such as Zoho, FastMail, and Proton work too. Treat that as the vendor's current compatibility statement. The exact connection method, permissions, and available controls can differ by provider or account configuration. For the broader operational context, see [email deliverability](/email-deliverability). Warm-up activity is one possible part of a sending practice, while sender authentication and the production message path need their own evidence. ## When a Lemwarm score changes the next action Use the score as a signal to decide what to inspect next, not as a final deliverability result. If your domain has no confirmed authentication records, start with DNS. SPF, DKIM, and DMARC each answer different questions about authorized sending and domain alignment. The [AI email warmup guide](/learning/ai-email-warmup) explains why warm-up activity cannot prove that a message will pass those protocol checks. If DNS is present, verify the sender application itself. A published DKIM record does not prove the mail system is applying a matching DKIM signature to the messages you send. Likewise, an SPF record does not prove the production envelope sender uses an authorized path. Then test a real message sent through the exact account and service you plan to use. Review its raw headers and the receiver's `Authentication-Results` fields. [RFC 8601](https://datatracker.ietf.org/doc/html/rfc8601) defines that header field as the place where a receiving system can report its authentication assessment. A domain-level check cannot substitute for delivered-message evidence. > Do not increase campaign volume because a warm-up score looks favorable if SPF, DKIM, DMARC, or the production sending path remains unverified. A record that looks correct in DNS can still be unused by the sender. Use this decision rule: ![Decision flow for interpreting a Lemwarm score, checking email authentication records, and validating a real production message before scaling](/images/editorial/lemwarm-email-warmup/lemwarm-email-warmup-decision-flow.webp "1200x980") *Source: Palisade.* - A Lemwarm score is available: treat it as a Lemwarm product signal, then inspect the domain's email-security posture. - SPF, DKIM, DMARC, or MX records are missing or unexpected: [read the domain's published MX records](/tools/mx), then correct the configuration through the responsible sender or DNS owner before scaling. - Records look correct: send a controlled production-path test and inspect its delivered headers. - Headers show an authentication or alignment failure: repair that specific sender path and retest. - Headers pass: continue to observe actual campaign outcomes at the intended audience and sending volume. ## Worked example: what to check outside Lemwarm A public DNS result can confirm what the domain publishes. It cannot confirm that your email platform uses the corresponding credentials or that a recipient placed the message in the inbox. For `yourdomain.com`, these are example lookup targets: ```text SPF record: yourdomain.com DKIM record: selector1._domainkey.yourdomain.com DMARC record: _dmarc.yourdomain.com MX records: yourdomain.com ``` These are illustrative record locations only. Do not copy a selector, CNAME target, token, or value from another account. Your email provider generates the actual DKIM selector and any account-specific DNS values. After DNS resolves, send a message from the exact production mailbox. Look for receiver-generated authentication results similar in structure to this example: ```text Authentication-Results: receiver.example; spf=pass smtp.mailfrom=yourdomain.com; dkim=pass header.d=yourdomain.com; dmarc=pass header.from=yourdomain.com ``` This example shows the type of evidence to inspect, not a guaranteed result or a universal header format. RFC 8601 specifies the `Authentication-Results` field format and its authentication methods, while each receiver determines its own assessments and final handling. A passing result is meaningful only for that message path and receiver. It does not prove that every future message will authenticate or reach the inbox. For another vendor-oriented view of the same boundary, see [Apollo email warmup](/learning/apollo-email-warmup). ## What to do after connecting an inbox Lemwarm's homepage recommends "About 4 weeks of warm-up, then 2 more weeks before you start real campaigns. After that, leave lemwarm running." This is Lemwarm's guidance, not a universal deliverability standard or a verified inbox-placement guarantee. Use the period to establish independent evidence: - Confirm DNS through the authoritative DNS provider and at least one public resolver. - Confirm the email provider's own authentication or domain-verification status. - Send a real message from the production path and inspect its delivered headers. - Review DMARC aggregate reports after reporting data accumulates, especially before moving a domain toward a stricter DMARC policy. The [Brevo email warmup guide](/learning/brevo-email-warmup) covers the same distinction between a warm-up product's reported activity and receiver-controlled delivery outcomes. ## Check the domain posture behind the warm-up score If Lemwarm reports a score or flags setup concerns, inspect the public SPF, DKIM, DMARC, and MX posture for the sending domain. That gives you a separate DNS-based view before you change volume or investigate the sender platform. [Check the domain's email security score](/tools/email-security-score) A domain security score does not prove inbox placement, warm-up effectiveness, the production sending path, or a receiver's filtering decision. For an ongoing program with several domains or senders, [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=warm-up_and_sending_practices&utm_content=lemwarm-email-warmup). Palisade analyzes DMARC aggregate-report data, identifies sending sources and authentication or alignment issues, and creates prioritized remediation tickets. It can propose a next DMARC policy step for human review, but it does not control a mailbox provider's private reputation decision or guarantee delivery. Signup and trial do not require a credit card. ## Sources and further reading - [Lemwarm email warm-up and deliverability tool](https://lemwarm.com) - [Lemlist help center: Lemwarm](https://help.lemlist.com) - [RFC 8601: Authentication-Results header field](https://datatracker.ietf.org/doc/html/rfc8601) - [Palisade email security score](https://www.palisade.email/tools/email-security-score) ## Frequently asked questions ### What is the best email warm up tool? There is no best one, because no independent comparison of these products exists and none of them control a receiver's placement decision. Lemwarm describes its own network, setup checks, and daily score, which tells you what it does but not how it ranks. Compare the providers each tool supports, the access it asks for, and what your own delivered mail shows. ### Is Lemwarm a good product? That depends on whether what it documents matches how you send. Lemwarm says it warms an inbox by exchanging real emails across a network of more than 20,000 users, checks your email setup, shows a daily score, and connects to Gmail and Outlook in one click. Weigh that against your mailbox provider, your security review, and the results you can see from your own production sends. ### How do I warm up an email address? Check the domain's authentication first, then either connect the mailbox to a warm-up service or raise your own volume gradually. Lemwarm's own guidance is about four weeks of warm-up plus two more weeks before real campaigns, which is its recommendation rather than an industry standard. Confirm SPF, DKIM, and DMARC for the sending domain, then read the headers of a real delivered message. ### Does email warmup guarantee inbox placement? No, because mailbox providers make placement decisions with their own signals and policies, and no warm-up product has any control over those. A warm-up tool can report its own network activity or a score, and that score describes the tool, not the receiver. Verify SPF, DKIM, DMARC, and the authentication results on a real message sent through the path you actually use. ### Can a DMARC record prove that Lemwarm is working? No, because a DMARC record only shows the policy and reporting addresses your domain publishes. It says nothing about whether Lemwarm activity changed your delivery, whether the production sender is set up correctly, or where a receiver will place your next campaign. Use delivered-message headers for that, and DMARC aggregate reports once they accumulate. --- # Mailchimp email warmup: what is documented Canonical: https://www.palisade.email/learning/mailchimp-email-warmup > Mailchimp email warmup is not a documented Mailchimp workflow in available official evidence. Check authentication and sending evidence instead. Mailchimp email warmup is not a Mailchimp-specific procedure that the available official Mailchimp evidence documents. Mailchimp describes itself as an email and SMS marketing platform with segmentation, analytics, and reporting, but those capabilities do not establish a warmup schedule, a receiver acceptance result, or inbox placement. Treat authentication, audience evidence, and delivered-message results as separate checks. ## Quick takeaways - Mailchimp's public product page does not document a Mailchimp-specific email warmup workflow. - Segmentation can help organize an audience, but it is not evidence that a sender has been warmed up. - Reporting can show the impact of sends, but it does not prove a receiver's private reputation decision. - SPF, DKIM, and DMARC checks are adjacent prerequisites, not proof of inbox placement. - A public domain check cannot confirm the exact production Mailchimp sending path. - Do not rely on a volume ramp or warmup-tool recommendation without current provider documentation for that exact method. ## What Mailchimp email warmup can and cannot mean Mailchimp calls its product an [email and SMS marketing platform](https://mailchimp.com/). Its homepage also says the platform has tools that "make segmentation easy" and offers analytics and reporting to help users measure the impact of sends. Those statements support a narrow conclusion: Mailchimp can provide campaign organization and reporting capabilities. They do not document an email warmup feature, a prescribed sending ramp, or an outcome at Gmail, Yahoo, Microsoft, or another receiver. Email warmup is often used loosely to describe gradually establishing a sending pattern. That broad description is not enough to prove that any receiver will accept, place, or trust a future message. Receiver systems make their own decisions, and a sender platform's controls are different from receiver-side delivery outcomes. For the wider distinction between authentication, sending behavior, and recipient handling, see [email deliverability](/email-deliverability). If the task is configuring the sending domain in Mailchimp, use the [Mailchimp SPF and DKIM setup guide](/learning/how-do-i-set-up-spf-and-dkim-for-mailchimp) instead. That configuration is relevant evidence, but it is not a documented Mailchimp warmup process. ## When the answer changes The answer changes only when current primary documentation establishes a specific Mailchimp feature or recommended workflow. Until then, separate these questions: - **Platform capability:** Does Mailchimp document a control, limit, status, or sending-practice recommendation for the account? - **Domain authentication:** Does the visible From domain have the required published authentication records, and does the production message show an aligned SPF or DKIM pass? - **Audience evidence:** Does the account's own reporting show the result of a particular send to the intended audience? - **Receiver outcome:** Did the target receiver accept and place a message from the exact production path? Mailchimp's public statements about segmentation and reporting relate to the first and third questions. They do not answer the fourth question. Use this decision rule: if you have only a public domain name, inspect the domain's published authentication posture. If you have a delivered test message, inspect its raw headers. If you need an account-specific sending control or status, use Mailchimp's current account documentation or support path. Do not substitute one kind of evidence for another. > A green DNS result does not prove that Mailchimp is signing the messages you send, that the correct return path is in use, or that a receiver will place the message in the inbox. For broader sender-platform configuration, the [ESP setup hub](/learning/esp-setup) separates provider setup work from later message and DMARC validation. ## A worked evidence rule for a Mailchimp send A Mailchimp campaign can produce several evidence objects. Each answers a different question. ```text Published DNS record: _dmarc.yourdomain.com TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com" Delivered-message evidence: Authentication-Results: receiver.example; dkim=pass header.d=yourdomain.com; spf=pass smtp.mailfrom=yourdomain.com; dmarc=pass header.from=yourdomain.com ``` This is illustrative only. Do not publish account-generated values, selectors, return paths, report addresses, or raw customer message headers. The DNS record shows that a DMARC policy is published for `yourdomain.com`. It does not show whether a Mailchimp campaign used that domain or passed DMARC. The delivered-message evidence can show authentication results for one received message. [RFC 8601 defines the Authentication-Results header field](https://datatracker.ietf.org/doc/html/rfc8601), including the authentication method results that a receiver can record. A header from the actual production campaign is more useful for that single message than a public DNS lookup alone. Neither evidence object proves a continuing receiver reputation state or future inbox placement. Aggregate DMARC reports can later show authentication and alignment patterns across reported traffic, while a receiver's final placement decision remains its own. ![Decision flow separating public authentication checks, Mailchimp account evidence, delivered-message headers, and receiver-side outcomes](/images/editorial/mailchimp-email-warmup/mailchimp-email-warmup-evidence-flow.webp "1200x980") *Source: Palisade.* ## What to check next Start with the evidence you actually have. - If you have a domain name, run an [email security score check](/tools/email-security-score) to inspect the public authentication posture. Compare the result with the domain that appears in the campaign's visible From address. - If you have a delivered test message, obtain its raw headers and review the `Authentication-Results` values from the receiving system. Confirm that the evidence came from the same Mailchimp production path you plan to use. - If you can access Mailchimp reporting, use it to review the measured impact of the specific send. Mailchimp states that its analytics and reporting help users [measure the impact of every send](https://mailchimp.com/). - If DMARC reports are available, review them after data accumulates to identify sending sources and alignment issues. A report is not immediate proof for a single test message. This order avoids treating a public record, a platform metric, and a receiver outcome as interchangeable evidence. It also keeps an unverified warmup tactic from becoming a production change. ## Check the domain posture behind the Mailchimp send A domain-level check is a useful first diagnostic when you need to establish whether the visible From domain publishes basic email-authentication signals before reviewing real Mailchimp message headers. [Check your email security posture](/tools/email-security-score) A public security-score check cannot prove Mailchimp's account configuration, inspect a specific campaign's headers, monitor future sending behavior, or guarantee receiver acceptance or inbox placement. For ongoing DMARC work, Palisade can analyze aggregate-report data, identify authentication or alignment issues, and propose a next policy step for human review. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=warm-up_sending_practices&utm_content=mailchimp-email-warmup) ## Sources and further reading - [Mailchimp email and SMS marketing platform](https://mailchimp.com/) - [RFC 8601: Authentication-Results header field](https://datatracker.ietf.org/doc/html/rfc8601) - [Palisade email security score](/tools/email-security-score) - [Palisade guide to Mailchimp SPF and DKIM setup](/learning/how-do-i-set-up-spf-and-dkim-for-mailchimp) ## Frequently asked questions ### Does Mailchimp have an email warmup feature? Mailchimp does not document an email warmup feature. Its public product pages describe segmentation, analytics, and reporting, and none of them name a warmup feature, a sending ramp, or a schedule. Set up [SPF and DKIM for the sending domain](/learning/how-do-i-set-up-spf-and-dkim-for-mailchimp) first, then use Mailchimp's own reporting to watch how each send performs. ### Why are people leaving Mailchimp? Mailchimp does not publish why customers leave, and there is no independent survey of departing customers to point to. What you read on this is usually opinion or a competitor's marketing, so treat it that way. Judge the platform on what it documents and on what your own send reporting shows. ### Does email warm up actually work? Gmail, Yahoo, and Microsoft do not publish a warmup schedule or any rule that rewards warmup activity, so the practice cannot be shown to cause better placement on its own. Building up a sending pattern gradually is a reasonable habit, but the receiver still decides where each message lands. Check your authentication records and the headers of a real delivered message instead of trusting a warmup score. ### What is the best email warmup tool? There is no single best tool, because no independent comparison of them exists and no tool can control a receiver's placement decision. Judge each one on what it documents: the access it needs, the controls it gives you, and how it defines the numbers it reports. Then test your own production sending path before you scale volume. ### Can SPF and DKIM warm up a Mailchimp sender? No, because SPF and DKIM prove who sent a message, not how much or how often you send. They give a receiver useful authentication evidence when your production mail uses and passes them correctly, which is worth having on its own merits. Neither one builds sender trust over time or guarantees inbox placement. --- # Mailshake email warmup Canonical: https://www.palisade.email/learning/mailshake-email-warmup > Mailshake email warmup is a built-in deliverability tool, but it does not replace SPF, DKIM, DMARC, list quality, or real sending-path checks. Mailshake email warmup is a deliverability tool Mailshake describes as "Free email warm up (via SMTP) to give your email a strong reputation." It may be part of a sending program, but it does not verify that your domain authenticates production mail, that your lists are suitable, or that a mailbox provider will place future outreach in the inbox. Check those conditions separately. ## Quick takeaways - Mailshake publicly lists email warmup among its built-in deliverability tools. - Mailshake's public site also lists an email domain setup assistant, list cleaning, and an in-app copy analyzer. - The available public information does not establish Mailshake's current warmup settings, limits, timing, or performance labels. - Warmup does not replace SPF, DKIM, or DMARC authentication checks. - Inbox placement depends on more than an email warmup program. - A public DNS or security check is a point-in-time result, not proof of future inbox placement. ## How Mailshake email warmup fits into deliverability [Mailshake's product site](https://mailshake.com) describes its warmup offering as email warmup via SMTP and says, "Mailshake has multiple deliverability tools built in." The same page identifies an email domain setup assistant, email warmup, list cleaning, and an in-app copy analyzer. That positioning matters because warmup is one part of deliverability work. It is separate from the technical question of whether the production sending domain has valid authentication records and whether messages sent through the actual outreach path produce an aligned SPF or DKIM pass for the visible From domain. For broader context, [email deliverability](/email-deliverability) covers the factors that affect whether recipients receive and place a message. Sender reputation can influence delivery decisions, but no warmup result can guarantee inbox placement at a particular receiver. Mailshake's documentation has a dedicated [Email Warm-up section](https://docs.mailshake.com) with articles covering the tool, how it works, adding an email, changing settings, and interpreting warmup performance. Those article titles confirm that Mailshake documents these subjects. They do not, by themselves, establish the current configuration path, technical behavior, settings, defaults, or recommended timing. A useful way to treat warmup is as a bounded activity: it may support the reputation side of a sender program, while authentication, list handling, content, and actual campaign behavior need their own evidence. [AI email warmup](/learning/ai-email-warmup) has the same practical boundary: a warmup service cannot prove what a production message will do after it reaches a receiver. ![Flow showing that Mailshake email warmup is one input to sender deliverability work, alongside authentication, list quality, message content, and production-message evidence](/images/editorial/mailshake-email-warmup/mailshake-email-warmup-deliverability-flow.webp "1200x829") *Source: Palisade.* ## When warmup is not enough The answer changes when the question is not "Does Mailshake offer warmup?" but "Is this mailbox ready to send outreach safely?" That second question needs evidence from the real sending domain and sending path. Use this decision rule: - If you only know that a mailbox is enrolled in warmup, treat authentication and production delivery as unverified. - If DNS records exist but no real message has been inspected, treat the sending application's use of those records as unverified. - If a delivered production message shows authentication results, compare the visible From domain with the SPF and DKIM domains to confirm DMARC alignment. - If aggregate DMARC reports are available, use them to identify sources and authentication or alignment failures over time. [RFC 8601 defines the `Authentication-Results` header field](https://datatracker.ietf.org/doc/html/rfc8601), which receivers can use to record authentication evaluations. This header can show results such as SPF or DKIM and the identity those checks used. It is evidence about that delivered message, not a guarantee for later mail. A warmup vendor can also distinguish warmup from other placement factors. For example, [Warm Up Your Email says](https://warmupyour.email) that warming an email account is only one factor in inbox placement and identifies content as another factor. That statement is about its own service, not a description of Mailshake's implementation. > Do not treat a warmup status or a public DNS result as permission to increase sending volume. Check the exact production path first, especially when the mailbox sends business-critical outreach. ## Worked evidence example A mailbox can appear ready in a warmup product while its production message still has an authentication problem. Inspect a message sent through the real Mailshake-connected mailbox to a test recipient that preserves full headers. Redact personal addresses and message content before sharing the result. ```text Authentication-Results: receiver.example; spf=pass smtp.mailfrom=yourdomain.com; dkim=pass header.d=yourdomain.com; dmarc=pass header.from=yourdomain.com ``` This is an illustrative header shape, not a Mailshake output. In this example, SPF passes for `yourdomain.com`, DKIM passes with `header.d=yourdomain.com`, and DMARC passes for the visible From domain. The relevant comparison is the authenticated identifier and the visible From domain, not the presence of a warmup enrollment. If the production header instead shows a passing SPF result for a different, unaligned domain and no aligned DKIM pass, warmup does not resolve that DMARC problem. Investigate the sending service's domain-authentication configuration and test again through the same mailbox and sending route. The four useful validation layers are distinct: - DNS: query the published SPF, DKIM, and DMARC records through authoritative DNS and a public resolver. - Vendor: check the sending service's current domain-authentication status. - Message: inspect headers from a real delivered message sent through the production path. - DMARC: review aggregate-report data after mail has accumulated. Mailshake's domain setup assistant and warmup tool are listed separately on its product page. It is therefore reasonable to assess domain authentication separately rather than infer it from warmup activity. ## Check the evidence you have Start with the evidence closest to the uncertainty. If you have a domain but no message headers, use Palisade's [email security score](/tools/email-security-score) to inspect the public security and authentication posture. It can help identify published-record gaps before you send more mail. If you have a delivered message, inspect its full `Authentication-Results` header and compare it with the DNS result. If the header and DNS disagree, investigate the sending application or connected mailbox before changing records. If you have aggregate DMARC data, identify all observed sources and any authentication or alignment failures. A passing record today does not show which sources will appear later or whether a new campaign uses the same authenticated path. For another vendor-specific framing of this limit, see [Apollo email warmup](/learning/apollo-email-warmup). ## Check the sending domain alongside Mailshake warmup Run the domain through the email security score tool to identify public authentication and security gaps that warmup does not check. [Check the email security score](/tools/email-security-score) A public check cannot prove Mailshake's current mailbox configuration, inspect a recipient's private reputation decision, or guarantee inbox placement for a future campaign. ## Use an ongoing DMARC workflow after warmup Warmup does not inventory every source that uses your domain or show whether later production messages fail alignment. Palisade is agentic DMARC software that analyzes DMARC aggregate-report data, identifies sending sources and authentication or alignment issues, and creates prioritized remediation tickets. It can propose the next policy step, while your team reviews the evidence and applies any DNS change. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=warmup_sending_practices&utm_content=mailshake-email-warmup) Palisade does not change your DMARC policy autonomously, repair every sender automatically, or guarantee delivery or inbox placement. ## Sources and further reading - [Mailshake product page](https://mailshake.com) - [Mailshake Help Center](https://docs.mailshake.com) - [RFC 8601: Message Header Field for Indicating Message Authentication Status](https://datatracker.ietf.org/doc/html/rfc8601) - [Warm Up Your Email](https://warmupyour.email) - [Palisade email security score](/tools/email-security-score) ## Frequently asked questions ### Is Mailshake email warmup free? Mailshake presents warmup as free, using the phrase "Free email warm up (via SMTP)" on its product site. Mailshake does not publish whether that covers every plan, what limits apply, or how long the feature stays available. Check your own plan's current terms before you build a process around it. ### Does Mailshake email warmup guarantee inbox placement? No, and Mailshake's own warmup description does not claim that it does. A warmup program cannot control a receiver's private reputation and placement decisions. Authentication, message content, list quality, and production sending behavior all still matter. ### Does email warmup verify SPF, DKIM, and DMARC? No, warmup and email authentication are separate checks that prove different things. To verify authentication, confirm the public DNS records, the sender's domain-authentication status, and the authentication results on a real message sent through the production route. ### Can a passing SPF result still fail DMARC? Yes, because DMARC needs an SPF or DKIM pass whose identifier aligns with the visible From domain. An SPF pass for a different domain does not meet that alignment requirement, so the message can still fail DMARC. ### How do I know whether Mailshake is using my authenticated sending path? Send a real message from the connected production mailbox and read its `Authentication-Results` header. Compare the SPF and DKIM identities in that header with the visible From domain and the records published in DNS. A status shown inside Mailshake cannot answer this on its own. --- # Microsoft email authentication Canonical: https://www.palisade.email/learning/microsoft-email-authentication > Microsoft email authentication can mean account sign-in, account security, or sender-domain authentication. Identify the task before taking action. Microsoft email authentication can mean three different tasks: signing in to a Microsoft account, securing that account with an extra verification step, or checking how a domain authenticates the email it sends. Those tasks use different evidence and different support paths. Start by identifying which one you need: account access, judging a suspicious message, or assessing a sending domain. ## Quick takeaways - Microsoft Support separates Microsoft account sign-in help from account-security help. - A sign-in issue is an account-access task, not evidence about a message's sender domain. - Two-step verification concerns account security and does not establish whether a particular email is legitimate. - A suspicious message needs Microsoft phishing guidance or the relevant organization's security process. - Sender-domain authentication is a separate email-security topic from account sign-in. - A public domain check cannot authenticate a Microsoft account or prove that a specific message is genuine. ## How Microsoft email authentication works as a search intent The phrase "Microsoft email authentication" does not identify one documented Microsoft feature in the available support material. It can describe an account holder trying to log in, a user being asked for an additional verification step, or an administrator trying to understand a domain's email-security posture. Microsoft groups account access under [Signing in with Microsoft](https://support.microsoft.com), including the support topic "How to sign in to a Microsoft account." That is the appropriate branch when the problem is access to an account, such as an inability to complete sign-in or a request to confirm account ownership. Microsoft also lists account-security help, including "Use two-step verification with your Microsoft account." Two-step verification is therefore an account-security topic in Microsoft's support structure. It should not be treated as proof that an email message was sent by Microsoft or by another organization. The third meaning is sender-domain authentication. This concerns the domain shown in an email's visible From address and the evidence used to assess mail sent under that domain. It is different from an employee or consumer signing in to a mailbox. For the broader distinction, see [email authentication](/learning) and [what email authentication means](/learning/what-is-email-authentication-and-why-does-it-matter). ## When the answer changes Use the task in front of you to choose the next action. - If you cannot access a Microsoft account, use Microsoft's sign-in support. The relevant evidence is the account and the sign-in experience, not a public DNS result. - If Microsoft asks for an extra verification step, use Microsoft's account-security guidance for two-step verification. Do not bypass a prompt based on an email alone. - If an email claims to come from Microsoft and you doubt it, treat it as a possible phishing concern. Microsoft lists [Protect yourself from phishing](https://support.microsoft.com) under its account-protection topics, but the available support material does not provide a message-verification procedure or header criteria. - If you administer a domain that sends email through Microsoft services, keep the question separate from mailbox sign-in. You need current administrator documentation and evidence from the actual production sending path before changing domain settings. > Do not change DNS, mail-flow settings, or account-security controls because a login prompt or a suspicious message appears to point to one cause. Those are different problems and may require different owners. The usable decision rule is: match the action to the evidence you have. An account prompt belongs with Microsoft account support. A suspicious message belongs with phishing guidance and your security team. A sender-domain question belongs with the domain's approved email-authentication process. ## A worked decision rule Use this evidence object before following a link, opening a ticket, or changing a setting: ```text Question: "What am I trying to authenticate?" If the evidence is: - A Microsoft sign-in screen or account-access problem Next step: Microsoft account sign-in support - A request for an additional account verification step Next step: Microsoft account-security and two-step verification support - A message claiming to be from Microsoft that seems suspicious Next step: Microsoft phishing-protection guidance or your security process - A domain that sends organizational email through Microsoft services Next step: Review the domain's documented sender-authentication configuration and test the real production message path ``` This rule prevents a common category error: using a domain-security check to solve an account-access problem, or assuming that successful account authentication verifies a message's origin. For domain work, record the exact sending domain, the application that sends mail, and a redacted sample from the real delivery path. A domain's public DNS state is only one layer of evidence. It does not prove that a production application is using the intended configuration, that a receiver accepted a message, or that future messages will reach the inbox. ## Practical next step based on your evidence If your immediate task is account access, go to Microsoft's support area for [how to sign in to a Microsoft account](https://support.microsoft.com). If the task is protecting the account, use the Microsoft Support topic for "Use two-step verification with your Microsoft account." If the task is a message that may be fraudulent, use Microsoft's phishing-protection support and follow your organization's incident process. Avoid replying to the message, sharing a verification code, or entering credentials through a link in the message until the situation is resolved through a trusted path. If you are responsible for a sending domain, first separate the domain question from the mailbox question. Then inspect your broader domain posture with the [Email Security Score tool](/tools/email-security-score). For delivery failures involving Microsoft services, [why Microsoft 365 blocks outbound emails](/email-deliverability/why-is-microsoft-365-blocking-outbound-emails) is a more focused reading path than account sign-in help. A domain check can help you inspect public email-security posture. It cannot authenticate a Microsoft account, validate a specific message claiming to be from Microsoft, prove the production sending path, or determine a receiver's private delivery decision. ![Decision flow separating Microsoft account sign-in, two-step verification, suspicious-message review, and sender-domain authentication](/images/editorial/microsoft-email-authentication/microsoft-email-authentication-decision-flow.webp "1200x829") *Source: Palisade.* ## Continue with the right email-authentication question If you are trying to understand sender-domain authentication rather than Microsoft account access, continue with [email authentication](/learning). That guide covers the broader concept without treating it as a substitute for Microsoft's account-support or phishing-help paths. ## Sources and further reading - [Microsoft Support](https://support.microsoft.com) - [Microsoft Support: Signing in with Microsoft](https://support.microsoft.com) - [Microsoft Support: account security and phishing protection](https://support.microsoft.com) - [Palisade Email Security Score tool](/tools/email-security-score) ## Frequently asked questions ### How do I authenticate my Microsoft email account? Sign in through Microsoft's own account support, which covers signing in to a Microsoft account and setting up two-step verification. Type the support address into your browser rather than following a link in an email, then do whatever your account prompt actually asks for. That process is about account access, and it is separate from how your organization's domain authenticates the mail it sends. ### How do I know if an email from Microsoft is real? Do not try to judge it from the message itself. Open your Microsoft account directly in a browser and see whether the same notice appears there, and use Microsoft's phishing-protection support if it does not. Microsoft does not publish header criteria you can check on your own, so never enter a password or a verification code through a link in the email. ### Why is Outlook asking me to authenticate? Outlook shows that prompt when it needs you to prove access to the account again, and only the wording of your own prompt says why. Microsoft does not publish a list of causes for it, so read what it is asking for: a password, a second verification step, or permission to reconnect the account. Handle it through Microsoft account sign-in or two-step verification support, never through an email. ### Why am I unable to authenticate my email? That phrase covers several different problems, so name yours first. It may be a Microsoft account you cannot sign in to, an account-security step you have not finished, a suspicious message you are trying to verify, or a sending domain that is failing authentication checks. Each has a different owner and a different fix, so identify the evidence in front of you before changing any setting. ### Does signing in to a Microsoft account authenticate an email message? No, because signing in proves you can reach an account and nothing more. It does not confirm that a message you received is genuine, and it says nothing about how your organization's sending domain authenticates outgoing mail. Those are separate checks with separate evidence. --- # Multi-tenant email authentication monitoring Canonical: https://www.palisade.email/learning/multi-tenant-email-authentication-monitoring > Multi-tenant email authentication monitoring needs tenant-level evidence, ownership, triage, verification, and client reporting for each sending domain. Multi-tenant email authentication monitoring is an operating discipline for keeping each client's email evidence, ownership, exceptions, and follow-up work separate while reviewing portfolio risk as a whole. An MSP should use one repeatable tenant record, investigate anomalies at the tenant level, assign remediation to the party that controls the affected system, and report decisions with the evidence behind them. ## Quick takeaways - A portfolio view should identify where to investigate, but the investigation record belongs to the affected tenant. - A compromised customer, tenant, or agent can put other senders' mail at risk when they share sending reputation. - Every open item needs a tenant, domain, evidence source, owner, next action, and review date. - The MSP can coordinate evidence and recommendations, while clients and service providers retain control over their own systems. - A report should distinguish observed evidence, unresolved questions, accepted exceptions, and completed verification. - This workflow is a Palisade operating framework, not a protocol requirement or service-level commitment. ## Operating context and ownership Multi-client monitoring becomes difficult when a portfolio queue hides the difference between a tenant with a routine DNS question and a tenant with an active sending problem. The MSP needs a portfolio-level way to prioritize work, but each investigation needs its own tenant boundary, evidence record, owner, and approval path. MailChannels warns that "[a] compromised customer, tenant, or agent can damage your sending reputation and put every other sender's mail at risk." Its guidance also recommends tracking behavior at the individual sender level and isolating problems before they spread across a platform. [MailChannels describes sender-level tracking and isolation](https://mailchannels.com/) as a control for organizations that send on behalf of customers, tenants, or agents. For an MSP, that premise supports a practical separation of responsibilities: - The MSP owns the operating process, evidence collection, triage queue, client communication, and escalation record. - The client owns business decisions, approval for material changes, and confirmation of legitimate sending activity. - The DNS host controls publication of DNS changes when the MSP does not have delegated access. - The sender or sending-platform owner controls its authentication configuration and message path. - The receiving mailbox provider controls its own acceptance, filtering, and reputation decisions. The workflow does not assume that a single status, dashboard, or public lookup proves production behavior. Keep public DNS results separate from evidence from the configured sender, client confirmation, or delivered-message review. The [Palisade MSP page](/for-managed-service-providers) is the relevant internal starting point for teams building a repeatable managed-email workflow. ![Portfolio workflow showing separate tenant investigation records feeding a shared MSP review queue](/images/editorial/multi-tenant-email-authentication-monitoring/multi-tenant-email-authentication-monitoring-portfolio-workflow.webp "1200x829") *Source: Palisade.* ## Evidence to collect Use one working record for each tenant-domain combination. This prevents a portfolio summary from collapsing different kinds of evidence into one unsupported status. ![Tenant evidence record showing client, domain, evidence, owner, next action, and review date](/images/editorial/multi-tenant-email-authentication-monitoring/multi-tenant-email-authentication-monitoring-portfolio-workflow.webp "1200x630") *Source: Palisade.* A useful record includes: - The client organization and the domain under review. - The specific evidence being reviewed, such as a client report, sender record, DNS response, support case, or redacted message evidence. - The owner who can answer the next question or make the next approved change. - A precise next action, rather than a broad instruction such as "fix authentication." - A dated review point so blocked issues do not disappear from the service queue. - The distinction between a client-confirmed sender, an observed sender, an unknown item, and a retired path. Use a portable format that can move between an MSP ticketing system, client report, and internal operating queue: ```yaml client: example-client domain: yourdomain.com evidence: client-confirmed sending path needs tenant-level review owner: client-email-owner next_action: confirm the sender and provide redacted verification evidence review_on: 2026-08-27 ``` This record is a Palisade operating framework. It does not establish whether a sender is authorized, whether a message will reach a recipient, or whether a provider will make a particular delivery decision. For foundational context on the subject, link client stakeholders to [what email authentication is and why it matters](/learning/what-is-email-authentication-and-why-does-it-matter). Keep the operational record focused on what the MSP can show, who must respond, and what remains unknown. ## How to run the workflow ### 1. Establish the tenant boundary Owner: MSP service owner. Input: client scope, domain list, contacts, and service agreement. Output: one tenant record for each in-scope domain. Start by confirming which legal or operational client owns each domain and who can approve investigation and changes. Do not place domains from different clients in one remediation ticket merely because they appear in the same portfolio queue. Record the client approver, technical contact, DNS change owner, and sender owner where known. If those roles are missing, mark the tenant as blocked and request the missing ownership decision before treating the item as ready for remediation. ### 2. Collect evidence without merging tenant records Owner: assigned MSP analyst. Input: tenant record and available evidence. Output: dated evidence entries with a stated confidence level. Collect evidence under the relevant tenant-domain record. Note whether the item comes from a client statement, a public lookup, a support report, or an observed sending event. A public result may help identify a question, but it does not prove the production sending path or a mailbox provider's private decision. Do not copy a finding from one tenant into another tenant's record unless the shared system and scope have been confirmed. Shared vendors can create similar symptoms, but similar symptoms do not prove a shared cause. ### 3. Triage by spread and business impact Owner: MSP service owner with client input. Input: open tenant records and dated evidence. Output: prioritized queue and escalation decision. Prioritize issues that may affect more than one sender or that involve a potentially compromised tenant. The sender-isolation principle described by [MailChannels](https://mailchannels.com/) supports investigating the affected sender before a problem spreads across a shared sending environment. Keep triage language observable: - "Tenant has an unconfirmed sender and needs client confirmation." - "Tenant evidence conflicts with the current sender inventory." - "Tenant has a business-critical sending path without a named owner." - "Tenant needs a post-change verification record." Avoid labels such as "secure," "fixed," or "compliant" when the record only shows a partial check. ### 4. Assign remediation to the controlling party Owner: MSP service owner. Input: narrowed tenant issue and ownership record. Output: an owner-specific action with approval boundary. The MSP may coordinate the action, but the party that controls the sender, DNS host, or client approval must own the applicable change. Write the action so the completion evidence is clear. For example, ask the client to confirm whether a sending path is legitimate, ask the DNS owner to review an approved change request, or ask the sender owner for redacted evidence from the exact production path. Do not ask a client to "fix email authentication" without identifying the tenant, domain, evidence gap, and responsible party. The [Palisade inbound-email-authentication article](/learning/how-does-palisade-handle-dmarc-for-inbound-emails) can help frame internal discussion about published product documentation. It does not replace tenant-specific evidence or client approval. ### 5. Verify the same tenant and path Owner: MSP analyst and the responsible client or sender owner. Input: completed action and new evidence. Output: verified, unresolved, or escalated status. Verification must return to the same client, domain, and stated issue. A change reported by a vendor or a public check can be useful evidence, but it does not establish that every future message will authenticate or receive a particular delivery outcome. Record what was checked, when it was checked, who supplied the evidence, and what question remains open. If the original evidence cannot be reproduced, keep the item open or classify it as an accepted exception. Do not close it because a separate tenant has a similar successful result. ### 6. Publish a client-readable report Owner: MSP account or service owner. Input: tenant records, completed actions, blocked items, and review dates. Output: tenant report and portfolio summary. The tenant report should separate four states: - Evidence observed. - Action assigned or completed. - Exception accepted by the client. - Decision or evidence still needed. The portfolio summary can show queue age, blocked ownership, unresolved sender questions, and completed reviews. It should not present one score as proof that every message path is monitored, authenticated, or accepted by every receiver. ## Exceptions and escalation Use a decision tree that keeps client boundaries intact: - If the tenant has evidence but no confirmed owner, request a client ownership decision and set a review date. - If the tenant has a known sender but the sender owner cannot provide verification evidence, keep the item open and escalate through the client contact. - If the issue may affect shared sending reputation, isolate investigation to the implicated tenant or sender first, then assess whether other tenant records show independently supported evidence. - If a client requests a change, confirm the approving authority and the rollback or incident contact before any production action. - If the evidence points to a receiving mailbox provider's private decision, route the issue to the relevant provider process or client account owner. The MSP cannot infer that decision from a general portfolio status. - If an active incident, credentials, private customer data, or production access is required, pause the workflow until the authorized party provides the required direction. A client can accept an exception, but the report should retain the evidence, decision owner, date, and next review point. Accepted risk is a service decision, not a technical verification result. ## Reporting and success measures Use a regular cadence that matches the service agreement and the client's business calendar. The report artifact should make accountability visible without claiming an unsupported SLA or security outcome. Track operational measures such as: - In-scope tenant domains with a named owner. - Open records without a next action. - Items past their review date. - Exceptions awaiting client acceptance. - Completed verification records with dated tenant evidence. - Portfolio items that may need sender-level investigation. These measures describe the health of the operating process. They do not prove inbox placement, protection against every compromise, or continuous monitoring of every message path. For clients that need a wider email-security discussion, [Sublime email security](/learning/sublime-email-security) offers related reading. Keep the managed-service report specific to the tenant evidence and service decisions at hand. ## Build a portfolio queue that preserves tenant evidence A recurring portfolio workflow needs more than a one-time public check. Start with separate tenant records, assign each unresolved item to the party that controls the next step, and preserve the evidence needed for a client decision. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=msp_operations&utm_content=multi-tenant-email-authentication-monitoring) Palisade does not replace client approval, change a client's DNS without authorized access, determine a mailbox provider's private decision, or guarantee delivery for every future message. ## Sources and further reading - [MailChannels](https://mailchannels.com/) - [Palisade for managed service providers](/for-managed-service-providers) - [What is email authentication and why does it matter?](/learning/what-is-email-authentication-and-why-does-it-matter) - [What Palisade's published documentation covers about inbound email authentication](/learning/how-does-palisade-handle-dmarc-for-inbound-emails) ## Frequently asked questions ### What is multi-tenant authentication? In an MSP setting, multi-tenant authentication means running email authentication for many client organizations at once, where each client owns its own domains, evidence, and approvals. The technical work is the same SPF, DKIM, and DMARC as for a single company, and what changes is the ownership boundary between them. Keep one record per client and domain so a portfolio view never merges two clients' evidence. ### How can I tell if my email is being monitored? Ask whoever runs the monitoring, because nothing in your mailbox shows it. If an MSP or service provider watches your domains, ask which domains are in scope, what evidence they collect, who receives the alerts, and how they verify a problem on a specific sending path. If nobody can answer those questions, your domains are probably not being monitored at all. ### What are the three pillars of email authentication? People using that phrase almost always mean SPF, DKIM, and DMARC. SPF lists which servers may send for your domain, DKIM signs each message so a receiver can confirm it was not altered, and DMARC checks whether either result aligns with your visible From domain and says what receivers should do when neither does. It is a handy label rather than a formal standard, so do not let it stand in for a real inventory of each client's senders. ### Can an MSP use one portfolio report for every client? No, because each client needs its own record of domains, evidence, approvals, exceptions, and owners. A portfolio view is useful for deciding what to work on next, and that is all it should carry. Merging the underlying records hides which tenant actually needs action. ### Does a public check prove that a client's email is monitored? No, because a public check only reads what DNS publishes at that moment. It cannot show the production sending path, a receiver's private decision, whether anyone is watching the domain continuously, or how future mail will be delivered. Monitoring is proved by the reports someone collects over time, not by a single lookup. --- # MXToolbox DMARC monitoring: check, interpret, and retest Canonical: https://www.palisade.email/learning/mxtoolbox-dmarc-monitoring > MXToolbox DMARC monitoring starts with a DNS check. Learn what a result can show, when to investigate further, and how to retest safely today. MXToolbox DMARC monitoring can help you keep track of DMARC configuration, but a public check is only one piece of evidence. Use it to establish what DNS returns for the domain, then compare that observation with the sending service, a real delivered message, and DMARC aggregate reports before deciding that mail authentication is working. ## Quick takeaways - MXToolbox states that its Delivery Center can keep tabs on DMARC Configuration alongside inbox placement, reputation, and Google Spam Rate. - A public DNS result shows what the lookup retrieved at that time, not whether every production sender authenticates correctly. - A passing DMARC record check does not prove inbox placement or explain a rejection from one receiver. - Forwarding can change a message after initial delivery and can cause DKIM failures, according to MXToolbox. - Retest after a DNS change, then validate the same production message path and review DMARC report data as it accumulates. ## What this tool checks MXToolbox describes its Delivery Center as a place to keep tabs on "Google Spam Rate, Inbox Placement, Email Reputation, DMARC Configuration and more" in its [Delivery Center overview](https://blog.mxtoolbox.com). That establishes the vendor's stated monitoring context. It does not establish the current interface path, record-result labels, alert rules, plan limits, or the exact evidence shown for an individual domain. For a public record check you can also use the [Palisade DMARC checker](/tools/dmarc). Enter the domain you are investigating and treat the returned DNS observation as a starting point. A public record check cannot prove the production sending path, message signing, continuous state, a receiver's private decision, or why one recipient rejected one message. The distinction matters because DMARC is evaluated on messages, not on a DNS record in isolation. A record can be visible publicly while an application sends without the expected authentication, signs with an unrelated domain, or sends through a path that does not produce the expected result. If you need the policy context before investigating a checker result, start with the [Palisade DMARC guide](/learning/dmarc). ![Decision map for interpreting a public DMARC record check](/images/editorial/mxtoolbox-dmarc-monitoring/mxtoolbox-dmarc-monitoring-result-map.webp "1200x856") *Source: Palisade.* ## How to run the check ### 1. Identify the visible From domain Use the domain after the `@` symbol in the visible From address of the message or campaign you are investigating. Do not substitute a mail server hostname, an IP address, or the domain in a Reply-To address. If the problem concerns a specific message, preserve a redacted copy of its raw headers. That message is later evidence for the actual sending path. A public lookup alone cannot replace it. ### 2. Run a public DNS lookup Open the [Palisade DMARC checker](/tools/dmarc) and submit the visible From domain. Record the domain you checked, the time of the run, and the returned DNS details. You can repeat the public lookup independently with an example domain: ```bash dig +short TXT _dmarc.yourdomain.com ``` The command asks DNS for TXT data at the DMARC owner name. Use `yourdomain.com` only as a structural example. Query the real domain only when you are authorized to inspect it. ### 3. Check the authoritative DNS answer A public resolver can return a cached answer. If you are changing DNS or investigating an unexpected result, query the domain's authoritative name server as well. You can also use the [Palisade DNS lookup tool](/tools/dns-lookup) to inspect DNS records. MXToolbox explains on its [MX lookup page](https://mxtoolbox.com) that its MX test queries the authoritative name server. That statement applies to its MX lookup, not necessarily to every MXToolbox product or DMARC workflow. Record the authoritative answer separately from the public result. If they differ, wait for DNS propagation or investigate the zone publication before changing sender settings. ### 4. Preserve the result as DNS evidence Save the result with the checked domain and timestamp. Do not treat a green status, a visible record, or an apparently complete policy as a conclusion about delivery. Move to the sending platform when DNS looks correct but a message still fails. Move to raw message headers when the question is whether the exact message authenticated. Move to aggregate reports when the question is which sources are using the domain over time. ## How to interpret the results ### A DMARC record is returned A returned record means the lookup found DNS data at the expected owner name during that run. It is useful evidence that the public DNS layer is responding. The next question is narrower: does the record match the domain and deployment you intend to operate? Compare it with the DNS value generated or approved by the team responsible for the domain. Do not copy a record from another business unit, sending account, or tenant. Then validate the vendor layer. Check the sending service's current authentication status for the same domain. A vendor status can show the service's configuration view, but it is still separate from a delivered-message result. ### No expected record is returned First, confirm the exact visible From domain. A subdomain and its organizational domain can have different DNS behavior, so changing a parent-domain record without checking the sending domain can create the wrong repair. Next, query the authoritative server and inspect the DNS zone that owns the domain. If the authoritative lookup also returns no expected data, the domain owner needs to publish or correct the intended record. If the authoritative answer is present but a public check differs, treat that as a DNS publication or caching investigation. Do not respond by changing DMARC policy first. Establish the DNS answer before making a policy decision. ### The DNS answer does not match the intended configuration A mismatch is a configuration-control problem. Compare the returned owner name and value against the value approved for that exact domain. Look for an outdated DNS change, a record published in the wrong zone, or a record intended for another sender environment. > Do not delete or replace a DMARC record based only on a public checker result. A mistaken DNS change can affect every sender that uses the visible From domain. After correcting DNS, validate four layers independently: - DNS: the authoritative answer and at least one public resolver return the expected value. - Vendor: the sending provider shows its current authentication status for that domain. - Message: a new message from the exact production path has receiver-added authentication results in its raw headers. - DMARC: aggregate reports show how sources authenticate after report data has accumulated. ### A message still has a DKIM-related failure Do not infer that a visible DMARC record caused a DKIM failure. MXToolbox states in its [forwarding explanation](https://blog.mxtoolbox.com) that forwarding is the most common reason it gives for a message to fail DKIM checks because the message can change after the initial send. Inspect the delivered message's raw headers and compare them with a message sent directly through the production path. If forwarding is involved, identify where the message changed. MXToolbox also says that properly configured SPF records should ensure DMARC compliance in the forwarding scenario it describes. That is vendor commentary about that scenario, not proof that every forwarded message will pass DMARC. ## How to act on the result Start with the evidence that is closest to the fault: - If DNS does not return the intended configuration, correct the exact DNS zone after confirming domain ownership and the approved value. - If DNS is correct but the sender platform is not authenticated, use the provider's documented domain-authentication workflow. - If both DNS and the provider status appear correct but a delivered message fails, inspect the message's `Authentication-Results` and signing headers before changing DNS. - If one source passes and another fails, keep the sources separate. A correct result for one sending application does not validate every application using the domain. - If you need source-level visibility over time, collect and review DMARC aggregate-report data. A one-time public lookup does not inventory all active senders. For broader monitoring options, compare the evidence boundaries in [Best Free DMARC Monitoring Tools](https://www.palisade.email/compare/best-free-dmarc-monitoring-tools). Do not use a monitoring product claim as a substitute for message-level validation. ## How to retest Repeat the same domain check after the authoritative DNS answer changes. Record the before-and-after result so you can tell a true DNS correction from a cached or unrelated change. Then send a new message through the same application, authenticated domain, gateway, and recipient path that produced the original problem. Inspect its raw headers. Finally, review DMARC aggregate reports after they have had time to collect data from the relevant receivers. The expected change depends on the repair: - After a DNS correction, the authoritative and public lookups should return the intended configuration. - After a sender-configuration correction, the provider should show the intended domain status. - After a message-path correction, a new delivered message should show the expected authentication result for that path. - After a source-level remediation, aggregate-report data should show the changed source behavior over time. ## Track the senders a DNS check cannot identify A public DMARC lookup can show the record available for a domain today. It cannot identify every production sending source that later fails authentication or alignment. Palisade is agentic DMARC software for teams that need to analyze DMARC aggregate-report data, identify sending sources and authentication or alignment issues, and create prioritized remediation tickets. It can propose the next policy step when the evidence supports it, while a human reviews the evidence and applies the change. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=dmarc_monitoring&utm_content=mxtoolbox-dmarc-monitoring) Signup and trial do not require a credit card. Palisade does not autonomously change the DMARC policy, repair every sender, or guarantee delivery or inbox placement. ## Sources and further reading - [MXToolbox Delivery Center overview](https://blog.mxtoolbox.com) - [MXToolbox explanation of forwarding and DKIM failure](https://blog.mxtoolbox.com) - [MXToolbox MX lookup](https://mxtoolbox.com) - [Palisade DMARC checker](/tools/dmarc) - [Palisade DMARC guide](/learning/dmarc) ## Frequently asked questions ### Does MXToolbox DMARC monitoring prove that all mail passes DMARC? No, monitoring does not prove that, because a DNS or monitoring result only describes the configuration it can see. It cannot show that every production sender authenticates correctly, or that a given receiver will accept a message. ### Can a public DMARC check explain a single rejected email? No, a public check cannot explain one rejection, because it never sees that message's path. Investigate a single rejection with the message's raw headers, the sending provider's status page, and any diagnostics the receiver gives you. ### Should I change a DMARC record when a checker result looks wrong? Change it only once you have confirmed three things: the visible From domain, the authoritative DNS answer for that exact domain, and the configuration you actually intended. Never paste in a record value copied from another tenant or sending account. ### Why can a message fail DKIM after forwarding? A forwarded message often fails DKIM because the message changed after it was signed. MXToolbox gives forwarding as the most common reason it sees for DKIM failures. Compare a direct delivery with the forwarded copy to find where the path altered the message. ### Is a passing DNS result the same as DMARC monitoring? No, they answer different questions. A passing DNS result is a single observation of what public DNS holds right now. DMARC aggregate reports build separate evidence about which sources send with your domain and how they authenticate over time. ### Do I need DMARC reports after the DNS record is visible? Yes, you still need the reports, because DNS visibility only confirms what you published. The reports are what show which sources are sending with your domain and where authentication or alignment still fails. --- # N8n email warmup: what n8n can and cannot do Canonical: https://www.palisade.email/learning/n8n-email-warmup > N8n email warmup can automate parts of an email workflow, but the available n8n documentation does not establish n8n itself as an email-warmup service or. N8n can automate parts of an email-sending workflow, but the available n8n documentation does not establish n8n itself as an email-warmup service. It is a workflow-automation platform that can connect applications and APIs, run steps visually, and expose each step's inputs and outputs. Treat it as workflow infrastructure, then validate the domain's authentication and real sending path before treating automation as a deliverability solution. ## Quick takeaways - N8n documents workflow automation, pre-built app nodes, and custom API connections. - The available n8n product information does not document an email-warmup feature or a safe warmup configuration. - An automated workflow can coordinate sending-related tasks without proving that a message will reach the inbox. - A domain's DNS configuration and security posture are separate from the behavior of an n8n workflow. - Test data and step-level outputs can help inspect a workflow, but they are not delivered-message authentication evidence. - Email deliverability depends on the production sending path and the receiving system's own decisions. ## How n8n fits into an email workflow [N8n describes its product](https://n8n.io) as workflow automation with "pre-built nodes for common apps" and "Custom API connections for everything else." That supports a narrow, useful conclusion: n8n can connect systems and automate steps around an email process when the relevant application or API is available. N8n also says, "Code when you need it, UI when you don't." A team could use that flexibility to coordinate work around a sending program, such as collecting inputs from another system, passing data to an approved sending service, or recording the result of a workflow step. Those are workflow functions. They do not establish that n8n controls mailbox-provider reputation, inbox placement, or a provider's final decision about a message. This distinction matters when someone searches for "n8n email warmup." Email warmup is a deliverability-adjacent term, but the supplied n8n product information does not define that term, document a native warmup node, or provide a recommended sending cadence. Do not turn generic automation capability into a claim about a specific deliverability outcome. For the broader factors that affect a message after it is sent, see [email deliverability](/email-deliverability). The [Palisade deliverability learning hub](/email-deliverability) also separates sending practices from the domain authentication controls that support trustworthy mail. ## When the answer changes The answer changes only when you have official documentation for the exact integration and sending provider you intend to use. Use this decision rule: - If you have an n8n workflow but no verified provider configuration, you can say the workflow coordinates steps. You cannot say it sends mail correctly. - If you have a provider's documented n8n node or API configuration, follow that provider's current documentation for authentication, permissions, and sending controls. - If a test workflow runs successfully, inspect its inputs and outputs. N8n says users can see "the inputs and outputs right next to the settings of every step." That confirms workflow-level evidence, not a recipient's final disposition. - If a real message has been delivered through the production path, inspect the message headers and the provider's own status. That is separate evidence from a successful n8n execution. - If DMARC aggregate reports have accumulated, use them to identify the sources using the domain and whether SPF or DKIM align for those sources. > Do not use an unverified workflow as a reason to increase sending volume or change a domain's DMARC policy. A workflow run is not evidence that the exact production message authenticated, aligned, or reached the inbox. N8n says workflows can be tested with real data and that users can rerun individual steps rather than the entire workflow. Those features can help isolate a workflow issue. They do not establish a safe ramp schedule, recipient policy, provider limit, or delivery result. ![Decision flow showing the difference between workflow evidence, delivered-message evidence, and DMARC report evidence for an n8n email workflow](/images/editorial/n8n-email-warmup/n8n-email-warmup-evidence-flow.webp "1200x829") *Source: Palisade.* ## Worked example: separate the evidence before calling it warmup A workflow may show that one application passed an instruction to another. That is useful operational evidence, but it answers a narrower question than deliverability. ```text Workflow result: sending-service step completed What this can show: - The workflow reached the configured step. - The step received the expected non-sensitive input. - The service returned the response exposed to the workflow. What this does not show: - The sending domain authenticated on the production message. - SPF or DKIM aligned with the visible From domain. - The receiver accepted, placed, or delivered the message. - Future messages will receive the same treatment. ``` The next evidence object should match the question you need to answer. If the question is "Did n8n execute the step?", inspect the workflow run and the individual step's inputs and outputs. N8n documents both capabilities on its [workflow automation product page](https://n8n.io). If the question is "Did our domain publish the expected authentication controls?", check the domain's public DNS posture. If the question is "Did this exact production message authenticate?", inspect its delivered headers. If the question is "Which systems are sending on behalf of the domain over time?", use DMARC aggregate-report data after it accumulates. The distinction also applies to other products described as warmup tools. An [AI email warmup](/learning/ai-email-warmup) workflow may automate activity, while evidence from the production message and the receiving system remains separate. ## Take the next step based on the evidence you have Start with the item you can actually inspect: - If you only have an n8n run, review the workflow's step inputs and outputs and compare them with the intended provider action. Keep credentials, tokens, private keys, and unredacted recipient data out of shared logs. - If you have control of the sending domain, assess its public email-authentication and security posture before attributing a delivery problem to workflow automation. - If you have a delivered test message, inspect the raw headers from that exact sending path. A passing workflow run cannot replace message evidence. - If you are considering a change to mail authentication policy, wait for DMARC aggregate reports and validate each legitimate sending source first. A public domain check is useful for inspecting published controls, but it cannot prove the production path, a mailbox provider's private decision, or future inbox placement. ## Check the domain posture behind the workflow Before treating an n8n automation as a deliverability fix, assess the sending domain's visible email-security controls. That separates a public DNS issue from a workflow issue and gives the team a concrete starting point for follow-up. [Check the email security score](/tools/email-security-score) A public score cannot prove that an n8n workflow sent a particular message, repair a provider configuration, monitor every future change, or guarantee delivery. For teams that need to inventory sending sources and work toward a stronger DMARC policy over time, Palisade is agentic DMARC software. It analyzes DMARC aggregate-report data, identifies authentication or alignment issues, and creates prioritized remediation tickets. A human reviews the evidence and applies any DNS or policy change. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=email_deliverability&utm_content=n8n-email-warmup) Palisade does not configure an unverified n8n workflow, control a receiver's private reputation decision, or guarantee inbox placement. ## Sources and further reading - [n8n workflow automation platform](https://n8n.io) - [Email deliverability guide](/email-deliverability) - [Palisade email security score](https://www.palisade.email/tools/email-security-score) ## Frequently asked questions ### Is n8n an email-warmup service? No, n8n is a workflow automation tool rather than an email-warmup service. Its own documentation covers workflow automation, pre-built nodes, custom API connections, visual workflows, and code steps. n8n does not document a native warmup feature or a warmup configuration, so you would be automating steps around warmup rather than getting warmup from n8n. ### Can a successful n8n workflow prove email delivery? No, a successful workflow only proves the step ran and returned data. It does not show that a recipient accepted the message, that the message passed DMARC, or that it reached an inbox. ### Can n8n help inspect an email workflow? Yes, n8n gives you several ways to look inside a run. It says you can see inputs and outputs next to each step's settings, test workflows with real data, and rerun individual steps. That shows how your workflow behaved, but not how the receiving system finally handled the mail. ### Should I change DMARC after an n8n workflow test succeeds? No, a workflow test is not a DMARC result and should not trigger a policy change. Before you touch DMARC, check the published DNS record, read the authentication results in a message delivered through the real production path, and review your DMARC aggregate reports. ### Does a public email-security check show the full sending path? No, a public check only inspects the controls a domain publishes openly. It cannot list every production sender, confirm that an application used the configuration you intended, or reveal how one mailbox provider handled a message. --- # Norton phishing protection: what Scam Protection confirms Canonical: https://www.palisade.email/learning/norton-phishing-protection > Norton phishing protection includes advertised Scam Protection on selected plans, but Norton does not document phishing-email coverage or guarantees. Norton phishing protection cannot be confirmed as phishing-email protection from the available Norton product information. Norton lists "Scam Protection" on selected consumer plans, but the product page does not explain whether it detects or blocks phishing emails, which email apps it covers, or what it guarantees. Treat the plan label as an indication of a security feature, not proof that every phishing email will be stopped. ## Quick takeaways - Norton lists "Scam Protection" on several consumer security plans. - The available Norton product information does not document phishing-email detection or blocking coverage. - A plan label does not prove coverage for a particular email service, app, attachment, link, QR code, or browser flow. - Norton also lists features called "Safe Web", "Safe Search", and "Smart Firewall", without describing their phishing-email behavior on the available support page. - Endpoint or browser protection is separate from an organization's email-security controls. - Assess a domain's email-security posture separately from software installed on an individual device. ## What Norton phishing protection currently confirms [Norton's US product page](https://us.norton.com) lists the feature name "Scam Protection" for Norton Mobile Security, Norton AntiVirus Plus, Norton 360 Standard, Norton 360 Deluxe, and Norton 360 with LifeLock Select Plus. The same product material describes Norton AntiVirus Plus and Norton 360 plans as including "Antivirus, malware, ransomware, and hacking protection" alongside "Scam Protection." That establishes a narrow point: Norton presents Scam Protection as part of selected consumer security offerings. It does not establish the scope of protection for phishing emails. The available product page does not state: - Which email providers or email clients are covered. - Whether Norton scans email content, attachments, links, QR codes, or downloaded files. - Whether protection applies before an email is opened, after a link is selected, or only in a browser. - Which operating systems, plans, or settings enable the feature. - How a user reviews a blocked item or handles a false positive. - That all phishing attempts will be detected or prevented. Norton's [support landing page](https://support.norton.com) also lists "Safe Web", "Safe Search", and "Smart Firewall" among product features. That page, as available for this review, does not describe how those features behave with phishing emails. For the underlying threat, see [what phishing is](/learning/what-is-phishing). Norton-branded lures belong in the wider category of [email threats and impersonation](/learning/threats), but a product name in a message does not by itself identify the message as legitimate or malicious. ## When the answer changes The answer changes only when Norton publishes documentation for the exact feature, plan, operating system, and email path you use. Use this decision rule: - If Norton documentation names the email app or service, the protection action, and the limits, use that documentation to assess the stated coverage. - If the documentation only names a plan feature such as "Scam Protection", assume the email-specific scope is unknown. - If a suspicious message is already open, evaluate the message and its destination independently. A product-plan label cannot establish that a specific message is safe. - If you administer an organization's domain, assess sender authentication and domain-level controls separately from consumer endpoint software. This distinction matters because the evidence answers different questions. Device and browser security software may address activity on a device or in a web session. Email security concerns the message path, the sending identity, and the controls used by the receiving mail system. One category of control does not prove the other is present. For an organizational evaluation of phishing controls, [anti-phishing software for business](/learning/anti-phishing-software) covers the comparison task more directly than a consumer-plan feature label. > Do not treat a security product name, an apparent Norton notification, or an email's branding as proof that a message is legitimate. The available Norton material does not document warning strings, notification examples, or a fake-notification response workflow. ![Decision flow for interpreting Norton's Scam Protection label without assuming phishing-email coverage](/images/editorial/norton-phishing-protection/norton-phishing-protection-coverage-decision.webp "1200x676") *Source: Palisade.* ## Worked example: what a plan label does and does not prove The following is a quoted feature-label example, not a configuration record or a promise of email coverage: ```text Plan feature shown by Norton: "Scam Protection" Confirmed from the product page: - The plan lists "Scam Protection". Not confirmed from that label alone: - Phishing-email scanning or blocking - Supported email providers or clients - Attachment, link, QR code, or browser coverage - Detection accuracy or guaranteed prevention - Warning, block, or remediation behavior ``` A customer considering Norton for phishing protection should look for an official feature page that connects the exact product feature to the email scenario in question. For example, documentation would need to state whether protection applies to a specific mail app, whether it evaluates links before or after selection, and what happens when it identifies a suspected scam. Without that documentation, the sound conclusion is limited: the plan advertises Scam Protection, while its phishing-email scope remains unpublished in the available product material. The same restraint applies to apparent Norton notices. A message or pop-up that uses Norton's name is not validated by the name alone. The available Norton pages do not document fake-notification causes, examples, or a reporting process, so this article cannot provide a vendor-specific handling procedure for them. ## Check the control layer that matches your evidence Start with the evidence you actually have. - For a Norton subscription question, check the official plan page and product support documentation for the exact plan, device, and feature setting. - For a suspicious email, follow your organization's established security-reporting procedure or use the mail provider's own reporting controls. Preserve only the information your security team requires. - For a domain-level assessment, use an [email security score check](/tools/email-security-score) to inspect the public security signals associated with a domain. - For broader organizational controls, read [email security](/learning) before treating endpoint software as a substitute for mail-path protections. A public domain check can inspect published signals. It cannot prove what Norton protected on a device, identify a receiver's private filtering decision, confirm continuous security status, or determine whether every future phishing message will be stopped. ## Read the email-security controls behind the message If the unresolved question is how an organization protects its sending domain and inbound mail environment, review [Palisade's email security guide](/learning). It separates domain and mail-flow controls from individual-device security software, so you can evaluate the right layer for the problem. [Review email security controls](/learning) That guide cannot confirm the behavior of a Norton plan, repair a suspicious message, or prove that a device-level product will block a particular phishing attempt. ## Sources and further reading - [Norton US product page](https://us.norton.com) - [Norton support](https://support.norton.com) - [Palisade email security guide](/learning) - [Palisade email security score checker](/tools/email-security-score) ## Frequently asked questions ### Does Norton protect against phishing emails? Norton does not state whether its protection covers phishing email. It advertises a feature called "Scam Protection" on several consumer plans, but its product pages never say what that feature covers, which mail apps it works with, or what it does when it finds something. Check Norton's current documentation for your exact plan before you rely on it for email. ### Why am I getting fake Norton notifications? Scammers copy well-known security brands because an urgent-looking warning gets people to click, and Norton's name is a common choice. Norton does not publish examples of these fakes or a process for reporting them, so treat any unexpected Norton alert as untrusted. Do not click it, and open your Norton subscription directly instead to see whether the same notice is really there. ### Does Scam Protection guarantee that phishing attempts will be blocked? No, and Norton does not claim it does. Its product page names the feature but publishes no detection coverage, no limits, and no description of how it behaves on a particular email path. Assume there are gaps, and keep your own process for reporting suspicious messages. --- # O365 phishing protection Canonical: https://www.palisade.email/learning/o365-phishing-protection > O365 phishing protection requires current Microsoft documentation for the tenant's licensed controls, policies, reporting options, and validation evidence. O365 phishing protection cannot be defined reliably from the generic Microsoft Learn portal alone. A useful answer for a Microsoft 365 tenant requires current Microsoft documentation for the licensed protection service, the active policy controls, the Outlook reporting option, and the evidence used to validate the result. Without those sources, do not treat a tenant's current protection level, configuration path, or reporting-button availability as established. ## Quick takeaways - O365 phishing protection is tenant-specific, so a generic portal page cannot establish the controls active in one organization. - Microsoft 365 phishing, malware, and reporting features need current Microsoft product documentation before they can be described or configured. - A policy name or a green administrative status does not prove how a real delivered message was handled. - A reporting-button request needs documentation that identifies the exact Outlook experience and reporting option in scope. - A phishing-control review needs evidence from the tenant, the message path, and the relevant Microsoft documentation. - [Email security](/learning) is broader than one provider's phishing controls. ## What a complete O365 phishing-protection answer needs The phrase "O365 phishing protection" can refer to several different reader tasks. One administrator may be asking about a policy that evaluates suspicious mail. Another may need a way for users to report messages in Outlook. A security reviewer may need to confirm whether malware protection is included for a particular tenant. Those are separate questions and need separate current Microsoft documentation. [Microsoft Learn](https://learn.microsoft.com) is Microsoft's documentation portal. Its generic landing page does not identify a Microsoft 365 phishing feature, a malware-protection entitlement, a policy setting, a reporting-button installation path, or a recommended configuration. Treat it as a starting point for locating the product-specific documentation, not as evidence that a particular control exists or is enabled. The practical unit of review is the exact tenant and the exact question: - Protection scope: which Microsoft service and license documentation applies to the tenant? - Policy scope: which documented controls are available, and which are currently configured? - Reporting scope: which Outlook reporting mechanism is documented for the users' client and deployment? - Message scope: what does a real delivered or blocked message show about its route and outcome? - Ongoing scope: what evidence shows whether the tenant continues to receive the expected protection after policy or service changes? These questions belong within a wider [threats and impersonation](/learning/threats) program. They do not have a safe universal answer based only on a provider name. ## When the answer changes The answer changes whenever the reader means a different Microsoft 365 task or has different evidence. Use this decision rule: - If the question is "What protection is included?", use the current Microsoft service-description and licensing documentation for the tenant's applicable service. - If the question is "How do I block phishing emails?", use the current Microsoft policy-configuration documentation for the relevant protection policy. - If the question is "How do users report a message?", use current Microsoft documentation that names the reporting option and supported Outlook experience. - If the question is "Did the protection work for this message?", use the actual message outcome and its available mail evidence, then compare it with the documented policy behavior. - If the question is "Is our domain broadly protected?", review the wider domain-security posture separately from Microsoft 365 tenant controls. > Do not change mail-protection policies from a generic article, a screenshot from another tenant, or an assumed default. A policy change can affect legitimate business mail. A public diagnostic can contribute one narrow kind of evidence. For example, an [email security score](/tools/email-security-score) check may help assess publicly visible domain-security signals when its documentation supports the result being reviewed. It cannot establish the Microsoft 365 tenant's active policy, a specific recipient's outcome, or how a future message will be handled. ## A worked evidence request for a Microsoft 365 review A useful review starts by identifying the question before collecting screenshots or changing settings. The following is an intake format, not a Microsoft configuration procedure. ```text Review question: Can this Microsoft 365 tenant document its current phishing protection? Tenant evidence: - Applicable Microsoft service and licensing documentation - Current Microsoft policy documentation for the protection in scope - Redacted policy status or configuration evidence from the tenant - One redacted example of the relevant message outcome - Outlook client and reporting requirement, if user reporting is in scope Decision: - Documented and verified for this tenant - Documented, but tenant evidence is incomplete - Tenant evidence exists, but the current Microsoft documentation is missing - Do not make a configuration claim yet ``` The outcome should match the evidence. For example, a request to add a phish alert button is unresolved until the reviewer can identify the exact Outlook reporting feature or third-party product that the request names. The phrase "phish alert button" is not enough to infer an installation method, a supported client, or an administrator action. ![Checklist showing the documentation, tenant evidence, message outcome, and reporting requirement needed to assess an O365 phishing-protection question](/images/editorial/o365-phishing-protection/o365-phishing-protection-evidence-checklist.webp "1200x524") *Source: Palisade.* The same distinction applies to malware protection. A current Microsoft service-description or anti-malware-policy page is needed before stating whether a tenant has a particular malware control, whether it is included, or how it is configured. For a broader explanation of the threat itself, see [what phishing is](/learning/what-is-phishing). That article can help frame the message-level risk, while a Microsoft 365 review needs provider-specific evidence before it can prescribe an action. ## What to collect next Start with the evidence that matches the reader's question. For a licensing or included-protection question, locate the current Microsoft documentation for the relevant service and edition. Record the exact service name and publication date. Do not infer availability from a tenant screen, a search result, or a generic Microsoft documentation page. For a policy question, use current official Microsoft documentation that names the policy and its supported controls. Then compare that documentation with redacted tenant evidence. A documented setting and a tenant setting answer different questions. Both matter. For a reporting-button question, first establish whether the request concerns Microsoft's own reporting option or a third-party product. Then use the current documentation for that exact option and Outlook context. Do not deploy an add-in or change user reporting flows until the intended product is confirmed. For a message-outcome question, retain redacted evidence from the exact production path. A public domain check, an administrative status indicator, and a message result each cover different parts of the problem. They should not be treated as substitutes. ## Continue with the wider email-security review If the immediate Microsoft 365 question is still being scoped, use the [email security guide](/learning) to place phishing protection alongside the other controls your organization reviews. [Review the wider email-security program](/learning) That guide cannot confirm the active Microsoft 365 policy, add an Outlook reporting button, or prove how a particular message was handled. ## Sources and further reading - [Microsoft Learn documentation portal](https://learn.microsoft.com) - [Palisade email security guide](/learning) - [Palisade threats and impersonation learning hub](/learning/threats) ## Frequently asked questions ### How do I add a phish alert button to Outlook 365? Start by working out which button the request means: Microsoft's own reporting option in Outlook, or a third-party add-in your security team picked. Then follow the current documentation for that exact option and for the Outlook client your users run, because the steps differ by client and by deployment. Do not install an add-in or change the user reporting flow until you know which product is intended. ### Does Microsoft 365 have malware protection? Microsoft 365 has anti-malware policies, but what is actually active depends on your tenant's license and how those policies are configured. Check the anti-malware policy for your own tenant against Microsoft's current service documentation for that plan, rather than assuming the control is on or off. ### How do I block phishing emails in Office 365? Work in the anti-phishing policy for your own tenant, following Microsoft's current configuration documentation for the service your license covers. Read what a setting does before you turn it on, because a protection policy change can also affect legitimate business mail. Then check the result against a real delivered message, not the policy screen alone. ### What are the best practices for anti-phishing in Office 365? Two rules hold in any tenant. Base each setting on Microsoft's current configuration guidance for the service you license, and confirm the effect with a real delivered message rather than an administrative status indicator. The rest is tenant-specific, so a screenshot from another organization or a general phishing article cannot tell you what is safe to turn on in yours. ### Can a public domain check prove that Microsoft 365 blocked a phishing message? No, a public domain check cannot prove that, because it only inspects what a domain publishes openly. It cannot show the active Microsoft 365 policy, a receiver's private decision, or the outcome for one individual message. --- # Open source email warmup: what the term actually means Canonical: https://www.palisade.email/learning/open-source-email-warmup > Open source email warmup is not a defined software category. Learn how to distinguish open-source email infrastructure from documented warm-up tools. Open source email warmup is not a defined software category based on the available primary-source material. An email product can be open source, and a separate product can describe warm-up activity, without either fact proving that there is an open-source warm-up tool. Treat the term as a claim to verify in a project's official documentation, especially before connecting a production sending domain. ## Quick takeaways - Open-source email infrastructure and email warm-up are separate product descriptions. - Forward Email calls itself a free, open-source email service for custom domains, but its public description does not establish a warm-up feature. - Mailwarm describes automated messages and replies across its account network, but that is a vendor description of its own commercial service. - Available evidence does not establish that warm-up activity improves inbox placement or sender reputation. - A project should explicitly document warm-up behavior, controls, and evidence collection before it is called an open-source email-warmup tool. - Authentication posture and real message evidence are more useful starting points than a category label. ## How the distinction works [Forward Email describes itself as "a free, open-source email service for custom domains"](https://forwardemail.net). Its public description concerns custom-domain email forwarding and hosting. That makes it an example of open-source email infrastructure, not evidence of an email-warmup capability. A warm-up service describes a different mechanism. [Mailwarm says its service automatically sends messages to accounts in its network and receives replies](https://mailwarm.com). It also says daily activity can include messages being opened, marked as important, and replied to. Those statements describe Mailwarm's product behavior. They do not establish how a mailbox provider evaluates mail, and they do not prove an inbox-placement or reputation outcome. This distinction matters because "open source" identifies how software is made available, while "warmup" would need to identify a documented operational function. Neither label supplies evidence about a domain's current authentication, a message's delivered headers, or a receiver's private filtering decision. For broader context on the factors that affect mail handling, see [email deliverability](/email-deliverability). If you need evidence from a particular delivered message, [analyzing email headers online](/learning/analyze-email-headers-online) is the adjacent task to start with. ## When the answer changes Call a product an open-source email-warmup tool only when its official materials explicitly establish all of the following: - The project is available under an identified open-source license or has an official public repository. - Its documentation explicitly describes warm-up behavior rather than only forwarding, hosting, sending, or receiving email. - The documentation identifies the operational controls, such as what the software sends or receives and how an operator configures it. - The documentation explains what evidence the tool collects and what the results mean. That is a decision rule inferred from the separate public descriptions of [Forward Email](https://forwardemail.net) and [Mailwarm](https://mailwarm.com). It prevents a category error: email software is not automatically a warm-up product, and a service that describes warm-up is not automatically open source. Forward Email's plan information provides a useful example of why product-specific documentation matters. Its Free plan is forwarding-only and, according to [Forward Email's plan explanation](https://forwardemail.net), cannot send directly from the custom domain or store email on its servers. That is a limitation of that plan, not a rule about open-source software or email warm-up generally. ![Decision rule for classifying a product as open-source email warmup only when official documentation confirms both its open-source status and documented warm-up operation](/images/editorial/open-source-email-warmup/open-source-email-warmup-decision-rule.webp "1200x718") *Source: Palisade.* ## A worked classification example Use the product's own public documentation before applying the label. ```text Product: Forward Email Official description: "a free, open-source email service for custom domains" Documented function: custom-domain email forwarding and hosting Documented warm-up behavior: not established by the cited product description Classification: open-source email infrastructure, not confirmed open-source email warmup ``` Now compare the separate warm-up description: ```text Product: Mailwarm Official description: automated messages sent to and replies received from its account network Open-source license or repository: not established by the cited product description Classification: commercial warm-up service description, not confirmed open-source email warmup ``` Neither example supports a claim that warm-up improves inbox placement. The supplied primary material does not include a mailbox-provider requirement, standards document, or other controlling source that establishes such an outcome. A useful practical test is to separate three questions: - Does the product's documentation establish that it is open source? - Does the documentation establish that it performs warm-up activity? - Does your own sending domain have valid authentication and delivered-message evidence? The first two classify a tool. The third concerns the domain you operate. ## What to check next Start with the evidence you already have. - If you have a project name, read its official repository and documentation. Look for an explicit license, a maintained installation path, a documented warm-up mechanism, and an explanation of the evidence it produces. - If you have a delivered message, inspect the raw headers from that exact sending path. This can show authentication results for that message, but it cannot prove future delivery outcomes or a receiver's private reputation decision. - If you are reviewing a domain before changing sending practices, use the [email deliverability hub](/email-deliverability) to separate authentication, message evidence, and operational questions. - If you are considering a vendor-specific warm-up feature, compare its documented behavior with the limited question you need answered. [Apollo email warmup](/learning/apollo-email-warmup) covers that distinction for Apollo's offering. DNS and a vendor status page are not enough to establish a working sending path. Check the domain's published records through authoritative DNS and a public resolver, then review vendor verification status, a real delivered message's authentication results, and DMARC aggregate-report evidence once it accumulates. ## Check your domain's authentication posture before changing sending practices Before drawing conclusions from an email-warmup label, inspect the domain's current security and authentication posture with Palisade's diagnostic tool. [Check the email security score](/tools/email-security-score) A public domain check cannot prove that a production application sends through the expected path, that a mailbox provider will place a message in the inbox, or that future messages will authenticate. ## Sources and further reading - [Forward Email](https://forwardemail.net) - [Mailwarm](https://mailwarm.com) - [Palisade Email Security Score](/tools/email-security-score) - [Palisade email deliverability learning hub](/email-deliverability) ## Frequently asked questions ### Can I use Forward Email as an open-source email-warmup tool? No, because Forward Email is not a warm-up product. [Forward Email](https://forwardemail.net) describes a free, open-source email service for custom domains, and its documentation names no warm-up feature at all. If warm-up is what you need, look at products that actually describe it. ### Does Mailwarm describe an open-source warm-up product? No, [Mailwarm](https://mailwarm.com) describes a commercial warm-up service. Its page covers its own account-network activity and mentions no open-source licence, public repository, or self-hosted deployment. Treat it as a paid product rather than something you can inspect or run yourself. ### Does email warmup improve inbox placement? Nobody has shown that it does, because no mailbox provider publishes a rule that rewards warm-up activity. Mailwarm describes what happens inside its own service, which is a description of the product rather than a measured placement result. Check your authentication records and the headers of a real delivered message instead. ### Does email forwarding mean a service can send from my custom domain? No, forwarding and sending are different jobs. [Forward Email states that its Free plan supports forwarding only](https://forwardemail.net) and says that plan cannot send directly from the custom domain or store email on its servers. That is a limit of that plan, so check the documentation for whichever plan and service you use. ### What evidence should I review before changing sending practices? Review the domain's published DNS records, the sending vendor's verification status, headers from a real message sent through the production path, and DMARC aggregate reports after data accumulates. Each layer answers a different question. --- # Phishing protection for Office 365 Canonical: https://www.palisade.email/learning/phishing-protection-office-365 > Phishing protection Office 365 requires tenant-specific controls, user reporting, and evidence from real messages. Learn what to verify for your tenant. Phishing protection for Office 365 is not established by one setting or one successful test. A useful assessment needs evidence from the Microsoft 365 tenant, the mail client that users actually use, and real messages received through the production path. Confirm what protection is enabled, how users can report suspicious messages, and whether delivered mail shows the expected authentication and filtering results before treating the tenant as protected. ## Quick takeaways - Office 365 phishing protection is tenant-specific, so a general description cannot confirm your organization’s active controls. - A phishing-reporting button can depend on the Outlook client, tenant configuration, and available Microsoft features. - A public DNS result cannot prove how Microsoft 365 evaluated or handled an individual message. - DKIM and other sender-authentication signals support identity checks, but DKIM alone does not block phishing. - The strongest evidence comes from a real message delivered through the same route your users receive. - Broader phishing and impersonation risk also includes messages that use lookalike domains or compromised legitimate accounts. ## How phishing protection for Office 365 works Phishing protection for Office 365 should be assessed as a chain of controls and evidence, rather than as a label on a license or a single mail rule. The relevant questions are operational: - What Microsoft 365 or Defender protections are enabled for the tenant? - Which Outlook clients do employees use to read and report suspicious mail? - What happens when a suspicious message reaches the tenant? - Which messages are quarantined, delivered, blocked, or reported? - What evidence is available to the administrator after a user reports a message? The exact answers depend on the tenant’s subscription, configuration, mailbox policies, and Microsoft interface. Treat claims about a feature name, a reporting button, or a policy path as tenant-specific until they are confirmed in Microsoft’s current documentation and in the tenant itself. For broader context on phishing, impersonation, and related email threats, see Palisade’s [email-threats learning hub](/learning/threats). A broader [email security guide](/learning) can help place phishing controls alongside authentication, access controls, and operational response. Authentication is one useful input, but it is not a complete phishing decision. A domain can use DKIM to sign legitimate mail, while a phishing message can come from an unrelated domain, a lookalike domain, or an account that has been compromised. If your Microsoft 365 tenant sends mail through Office 365, review [DKIM for Office 365](/resources-post/dkim-for-office-365) as part of the sending-domain assessment. That review does not establish that inbound phishing protections are enabled. ## When the answer changes The practical answer changes with the evidence available and the kind of message involved. Use this decision rule: - If you only have a domain name, inspect its public email-security posture. This can identify published DNS records, but it cannot show the tenant’s active Microsoft 365 policies or a recipient’s mailbox experience. - If you have a suspicious message, preserve the message and collect the available headers and delivery context. That evidence is closer to the event than a DNS lookup. - If a user cannot find a reporting action, check the exact Outlook client and the tenant’s approved reporting guidance. Do not assume a button exists in every client or has the same label everywhere. - If an administrator needs to change blocking behavior, use the tenant’s current Microsoft documentation and administrative interface. A third-party article cannot safely substitute for the controls visible in that tenant. - If the concern is ongoing exposure across domains or sending sources, track authenticated sending and DMARC aggregate-report evidence after it accumulates. > Do not change mail-filtering or authentication policies solely because a public checker reports a weakness. A DNS result is one layer of evidence. It does not show whether Microsoft 365 has applied a tenant policy, whether a message was delivered, or whether a business-critical sender will continue to work. A message that appears to be phishing can also have different causes. It may impersonate a trusted brand from an unrelated domain. It may use a legitimate but newly compromised sender. It may be an expected message that lacks a familiar authentication signal. Those situations need different evidence and different response paths. ![Decision flow for assessing an Office 365 phishing concern using domain evidence, message evidence, Outlook reporting access, and tenant controls](/images/editorial/phishing-protection-office-365/phishing-protection-office-365-evidence-flow.webp "1200x829") *Source: Palisade.* ## Worked evidence example A safe phishing-protection review separates what each artifact can show. The following is an illustrative evidence checklist, not a Microsoft 365 configuration or a message-header example. ```text Illustrative phishing review Domain evidence: - Public DNS records for yourdomain.com - Published SPF, DKIM, and DMARC information where applicable Message evidence: - Redacted full message headers - Visible From address - Recipient mailbox and delivery time - Whether the message was delivered, quarantined, or reported Tenant evidence: - Current Microsoft 365 protection status shown to the administrator - Current user-reporting guidance for the affected Outlook client - Approved incident or remediation record ``` This checklist gives each layer a separate purpose: - **Domain evidence** helps identify what a sending domain publishes publicly. Use Palisade’s [email security score tool](/tools/email-security-score) when the starting point is a domain. It is a diagnostic check, not proof that Microsoft 365 is configured correctly, that an individual message is malicious, or that future messages will be blocked. - **Message evidence** helps connect a suspicious email to the actual mail path. Preserve only the information your incident process permits. Do not paste credentials, private keys, tokens, or customer data into a public tool. - **Tenant evidence** shows what the organization’s current Microsoft 365 environment exposes to administrators and users. This is where current feature availability, policy labels, and reporting workflows must be confirmed. - **DMARC evidence** becomes useful after aggregate reports accumulate. It can help identify sources using a domain and authentication or alignment issues. It does not prove that every inbound phishing message will be stopped. The important distinction is between an identity signal and a final security outcome. Authentication can help a receiving system evaluate claimed domain identity. It does not guarantee inbox placement, block every phishing message, or explain every Microsoft 365 filtering decision. ## What to check next Start with the evidence already available. If the concern begins with a domain, run the domain through the [email security score tool](/tools/email-security-score). Record the date and the published results, then compare them with the DNS records your team intended to publish. Public checks cannot inspect internal Microsoft 365 policy, continuous tenant state, or a receiver’s private filtering decision. If the concern begins with a delivered message, preserve the message according to your incident process and review it in the Microsoft 365 tenant using the current approved workflow. Confirm the exact user client, recipient mailbox, delivery time, and any available report or quarantine outcome. Do not infer those facts from a domain lookup. If employees need reporting instructions, use the organization’s current Microsoft-approved guidance for the Outlook client in use. The available reporting action, its location, and any prerequisite configuration must be confirmed for the tenant before it becomes internal documentation. For a wider operating model, follow the [email security guide](/learning). It helps connect phishing protection with sender authentication and response practices without treating a public domain check as proof of a Microsoft 365 configuration. ## Build evidence for the Office 365 phishing question The next useful action is to review your broader [email security controls](/learning) alongside the suspicious message or tenant evidence you already have. That creates a clearer path for separating published domain posture, real-message evidence, and Microsoft 365 tenant controls. [Review email security controls](/learning) An email-security guide cannot identify the current phishing button in a specific Outlook client, prove that your tenant has a particular Microsoft feature enabled, or guarantee how Microsoft 365 will handle a future message. ## Sources and further reading - [Palisade email security guide](/learning) - [Palisade email-threats learning hub](/learning/threats) - [Palisade email security score tool](/tools/email-security-score) - [DKIM for Office 365](/resources-post/dkim-for-office-365) ## Frequently asked questions ### Where is the phishing button in Office 365? The button sits wherever your own Outlook client puts it, so check the client your employees actually use rather than a generic screenshot. Microsoft does not use one fixed location or label across every Outlook experience, and some tenants add their own reporting add-in on top. Confirm the action in your tenant before you write it into internal instructions. ### How do I block phishing emails in Office 365? Change the blocking behavior in your own tenant, using Microsoft's current guidance for the features your organization licenses. A public domain check can tell you what your domain publishes, but it cannot change a Microsoft 365 policy or explain why one message was delivered. Confirm the change against a real message that arrived through the same route your users receive. ### What is phishing protection with Microsoft Defender for Office 365? Microsoft Defender for Office 365 is the tenant-side layer Microsoft offers for evaluating mail that arrives in a Microsoft 365 tenant. Which policies, actions, and feature names you get depends on the subscription, so treat the phrase as a licensing and configuration question rather than proof that a particular control is active. Confirm the specifics in Microsoft's current documentation and in the tenant itself. ### How do I report phishing to Microsoft 365? Follow your organization’s approved reporting process for the Outlook client in use, then preserve the relevant message evidence according to the incident process. The supported reporting workflow can depend on the tenant and client, so confirm it before directing users to a particular button or add-in. ### Can DKIM stop phishing emails in Office 365? No, DKIM cannot stop phishing on its own, because it only signals whether signed mail really came from the domain it claims. A phishing message can still arrive from an unrelated domain, a lookalike domain, or a real account that has been compromised. Read DKIM alongside your other authentication and tenant-control evidence. ### Does a passing email-security score prove Office 365 phishing protection works? No, a passing score only reflects a point-in-time view of public domain data. It cannot show which Microsoft 365 policy settings are active, how a particular message was handled, what the tenant looks like tomorrow, or where future mail will land. --- # PowerDMARC DKIM checker: lookup and re-test workflow Canonical: https://www.palisade.email/learning/powerdmarc-dkim-checker > PowerDMARC DKIM checker workflow: identify the selector, inspect the published DNS record, correct sender-generated values, and re-test safely. PowerDMARC lists a "DKIM Lookup" tool, but its public pages do not document the current input fields, result labels, or whether the lookup validates a delivered message. Use it as a starting point only after you have the exact sending domain and selector from your email provider or a real message. Then compare the published DNS evidence with the sender's generated record, correct only the affected record, and re-test after DNS caches update. ## Quick takeaways - PowerDMARC publicly lists "DKIM Lookup" among its tools. - A DKIM lookup and a delivered-message validation answer different questions. - Use account-generated selector, key, CNAME, and verification values from the sending service that owns the sender. - Do not copy a DKIM record from another domain, account, or tenant. - A public DNS result does not prove that production mail is signed with the matching key. - DNS caching can delay the result of a re-test after a record change. ## What this tool checks PowerDMARC's public site lists [DKIM Lookup](https://powerdmarc.com) as an available tool, and its support portal lists a [Free DKIM Record Lookup](https://support.powerdmarc.com) under Tools. The public material reviewed for this workflow does not establish the tool's required input, selector-discovery method, result labels, or whether it checks DNS only. That distinction matters. A published DKIM record is one piece of evidence. A real message can provide separate evidence about the path that actually sent mail. An end-to-end validator that receives a message can inspect the headers recipients see, as [DKIMValidator explains](https://dkimvalidator.com). Do not treat a record lookup as proof that every sender is signing, that every recipient will accept a message, or that DMARC will pass. Before using any lookup, identify: - The visible From domain used by the message. - The DKIM signing domain and selector from the sending service, if that service exposes them. - The exact sender or application that produced the message. - Whether the task is DNS inspection or validation of a delivered production message. For context on evaluating vendor and tool options, see [Palisade's comparison hub](/compare). If the domain is also being reviewed for sender authentication, a [DMARC record check](/tools/dmarc) is a separate DNS check with its own limits. ![Decision flow for a DKIM lookup and retest](/images/editorial/powerdmarc-dkim-checker/powerdmarc-dkim-checker-flow.webp "1200x829") *Source: Palisade.* ## How to run the check ### 1. Identify the sending service Find which service sends the mail you are investigating. Use that service's current domain-authentication setup page or its generated DNS instructions. PowerDMARC describes Hosted DKIM as a service to "Simplify DKIM selector and key management for multiple domains with this one-stop service," but that statement does not identify the configuration values for another sender. If the sender is a third-party platform, use its account-generated DKIM instructions. PowerDMARC's support portal describes its [Third-Party Source Configuration category](https://support.powerdmarc.com) as covering DKIM, SPF, and DMARC implementation for third-party email vendors. > Do not replace a record with a selector, CNAME target, public key, or token copied from another account. Those values can be specific to the sending service and account. ### 2. Record the exact domain and selector Use the values generated by the sender that owns the email path. If you have a delivered test message, preserve a redacted copy of its authentication-related headers for comparison with the sending-service configuration. The public PowerDMARC materials do not document whether its lookup accepts a domain, selector, email address, or another input. Follow the current instructions on the official tool page rather than assuming an input format from an older guide or screenshot. ### 3. Run a public DNS lookup Submit only the domain and selector values that apply to the sender being investigated. Record the time, the queried name, and the returned answer or failure. This creates a baseline for the re-test. You can also repeat a public DNS query independently. Replace the placeholders with your own sender-generated values. ```bash dig +short TXT selector1._domainkey.yourdomain.com ``` This command returns a public DNS answer when one is available through the resolver used for the query. It does not prove that the sending application uses the selector, that a message signature validates, or that a mailbox provider made a particular delivery decision. ### 4. Preserve the result before editing DNS Save the result in the change record with the sender name and timestamp. If the lookup does not return the expected record, first verify that the owner name matches the sender's generated instructions. Do not treat an empty result alone as evidence that the sender is broken. The domain, selector, DNS provider, or rollout state may still need confirmation. ## How to interpret the results The available public PowerDMARC material does not document current checker result states or labels. The following interpretation matrix is therefore a method for assessing the DNS evidence you observe, not a description of PowerDMARC interface statuses. ### A record is returned for the expected owner name This is DNS evidence that a public answer was returned for the name you queried. Compare the owner name and returned content with the exact values generated by the sending service. A match supports the DNS layer of the setup. It does not establish the vendor layer, the delivered-message layer, or the DMARC-report layer. Send a real test message through the same production path and inspect the recipient's headers before concluding that the sender is signing correctly. ### No answer is returned for the expected owner name First confirm the selector and domain with the sending service. Then verify that the DNS provider has published the exact owner name that the service generated. A typo, an omitted subdomain, or a record entered in the wrong DNS zone can produce a result that looks like a missing record. Do not publish a replacement value from an example. The sender must generate the real record values for the account and domain. ### An answer is returned, but it differs from the sender's instructions Treat this as a configuration mismatch until you can explain it. Determine whether the sender recently rotated keys, whether an old record remains published, or whether the DNS record was created for another service. Make one scoped correction based on the sender's current instructions, then preserve the previous value for rollback if your DNS process permits it. A domain can have multiple email systems. Keep each sender's evidence separate. A valid result for one sender does not validate another sender's configuration. ### The DNS result looks correct, but the message still has a problem Move to a delivered-message check and the sending-service status. A public lookup cannot show which key the application used when it sent the message. It also cannot establish a receiver's private spam or reputation decision. For a broader sender-authentication review, use the [Palisade DKIM checker](/tools/dkim) after you have confirmed the applicable domain and selector. A public check can inspect DNS evidence, but it cannot prove the production sending path, continuous state, or future inbox placement. ## How to act on the result Start with the smallest verified scope: - If the queried name is wrong, correct the query input before changing DNS. - If the DNS owner name is absent, return to the exact sending service and obtain its current generated record. - If a published value differs from the sender's current instruction, correct only that record in the authoritative DNS zone. - If DNS matches but a message still fails, inspect the sending-service configuration and a newly delivered message from the same application and sender identity. - If several services send mail for the same domain, document each service, its selector, and its validation evidence separately. A DNS host may show a successful save while public resolvers still return an older answer. DKIMValidator notes that DNS records are heavily cached and changes can require hours between tests. That is a caching consideration, not a promise about a specific provider or a fixed propagation time. If the record is hosted in GoDaddy, the [DKIM record workflow for GoDaddy DNS](/learning/add-dkim-record-godaddy) can help you keep the DNS edit scoped to the sender-generated values. For Google sender requirements, [email authentication for Gmail](/learning/authenticate-email-for-gmail) explains why DNS configuration alone is not the complete validation step. ## How to retest Repeat the same lookup with the same domain and selector after the authoritative DNS zone has been updated and caches have had time to refresh. Compare the new answer with the sender's current generated instructions, not with a record copied from another account. Then validate at four layers where they apply: - DNS: confirm the authoritative published record and at least one public-resolver result. - Vendor: confirm the sender's own current authentication or verification status. - Message: send a new message through the exact production application, sender, gateway, and recipient path, then inspect its received headers. - DMARC: review aggregate-report evidence once reports have accumulated. Keep the timestamps and inputs for each layer. A green DNS result is useful, but it does not replace a delivered-message check. ## Check the DNS record, then track the senders that still need work Once you have the exact domain and selector, use Palisade's DKIM checker to inspect the public DNS side of the configuration. If one record is corrected, the ongoing question is which other production sending sources still use the domain and whether their authentication or alignment evidence supports the next DMARC policy stage. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=powerdmarc&utm_content=powerdmarc-dkim-checker) Palisade is agentic DMARC software that analyzes DMARC aggregate-report data, identifies sending sources and authentication or alignment issues, and creates prioritized remediation tickets. It can propose a next policy step when the evidence supports it, while a human reviews the evidence and applies the change. It does not change DMARC policy automatically, repair every sender, prove every future message will authenticate, or guarantee delivery. ## Sources and further reading - [PowerDMARC](https://powerdmarc.com) - [PowerDMARC support portal](https://support.powerdmarc.com) - [DKIMValidator](https://dkimvalidator.com) - [Palisade DKIM checker](/tools/dkim) ## Frequently asked questions ### Does PowerDMARC have a DKIM checker? Yes. PowerDMARC publicly lists "DKIM Lookup," and its support portal lists "Free DKIM Record Lookup." Its public material does not document the current input flow, result labels, or whether the lookup validates a delivered message. ### Can a DKIM lookup prove that email is signing correctly? No. A public lookup can provide DNS evidence for the name queried. A new delivered message from the exact production path is needed to assess what that sender actually used. ### Should I use a selector from another account to repair a missing record? No. Obtain the selector and record values from the sending service and account that own the affected email path. Account-generated DKIM values can differ between tenants and services. ### Why does a corrected DKIM record not appear immediately? DNS records are cached. A re-test can continue to show an older answer until caches refresh, so record the time of the change and repeat the same lookup later. ### Does a valid DKIM record prove that DMARC passes? No. A valid public record is DNS evidence only. DMARC assessment also depends on a real message and its authentication or alignment evidence, followed by aggregate-report data as it accumulates. --- # Proofpoint SPF checker: check and validate an SPF record Canonical: https://www.palisade.email/learning/proofpoint-spf-checker > Proofpoint SPF checker workflow: check a published SPF record, interpret SPF outcomes, repair DNS evidence, and validate a delivered message. A Proofpoint SPF checker can help you inspect the public SPF record for one or more domains, but its result is DNS evidence only. Use the public Proofpoint form to check the published domain, then compare the record with the sender configuration and a real delivered message. SPF authorizes the envelope sender or HELO identity, not the visible From address by itself. ## Quick takeaways - Proofpoint's public Japanese DMARC and SPF tool accepts one domain per line, with up to 100 domains in one check. - An SPF record is a DNS TXT record that authorizes hosts for the MAIL FROM or HELO identity. - A published SPF record does not prove that a production service uses that record successfully. - SPF can pass while failing DMARC alignment if its authenticated domain does not align with the visible From domain. - Check DNS, the sending-service status, a delivered message, and DMARC reports before calling a production path complete. ## What this tool checks The [Proofpoint DMARC/SPF creation and check tool](https://www.proofpoint.com/jp/cybersecurity-tools/dmarc-spf-creation-wizard) has an SPF section headed `チェックするドメイン名を入力して下さい`. Its published instructions state that each line can contain one domain and that you can enter up to 100 domains before selecting `Check`. That form checks information visible in public DNS. It can help establish whether a domain publishes an SPF-related configuration, but it cannot inspect a Proofpoint tenant, a sending application's settings, the private logic used by a receiving mailbox provider, or the authentication result for one delivered message. Proofpoint also documents [Hosted Sender Policy Framework](https://www.proofpoint.com/sites/default/files/product-overview/pfpt-us-to-hosted-spf.pdf) as a DNS service for Proofpoint Email Fraud Defense customers, administered through a customer portal. That product brief does not establish that visitors to the public checker have Hosted SPF access or that a public result reflects a customer's tenant configuration. For a separate public lookup, use the [Palisade SPF checker](/tools/spf). A public record check cannot prove the production sending path, message signing, continuous state, or why a particular receiver rejected a message. ![Decision map for checking a published SPF record, validating the production path, and reviewing DMARC evidence](/images/editorial/proofpoint-spf-checker/proofpoint-spf-checker-result-map.webp "1200x829") *Source: Palisade.* ## How to run the check ### 1. Identify the domain that SPF actually evaluates Start with a delivered message if one is available. SPF evaluates the SMTP `MAIL FROM` identity, also called the envelope sender, or the SMTP `HELO` identity when the MAIL FROM identity is empty. [RFC 7208 defines those SPF identities and the evaluation model](https://www.rfc-editor.org/rfc/rfc7208.html). Do not substitute the visible From domain for the envelope sender without checking the message headers. The two domains may differ. ### 2. Submit the domain to the Proofpoint public form Open Proofpoint's public checker and enter the domain you want to inspect. Keep each domain on its own line. For an operational check involving multiple domains, record the time of the run and preserve which domain produced which result. Use a public DNS query alongside the form so you can compare the visible TXT answer yourself: ```bash dig +short TXT yourdomain.com ``` The command queries a resolver, not necessarily the authoritative DNS server. If results differ during a change, query the authoritative nameserver for the domain as well. ### 3. Isolate the SPF TXT record A domain can publish several TXT records for unrelated purposes. Locate the record that begins with `v=spf1`. [RFC 7208 requires SPF records to be published as DNS TXT records](https://www.rfc-editor.org/rfc/rfc7208.html). An illustrative record shape is: ```text v=spf1 include:spf.example-mail-provider.com -all ``` > Do not copy this record into DNS. Your sending service generates the include domains, IP addresses, and mechanisms that belong to your own sending path. If the domain sends through more than one service, inventory each service before editing. Replacing an existing record with a single provider's example can remove authorization for other legitimate mail. ## How to interpret the results ### The domain has no SPF record If the public lookup finds no TXT record beginning with `v=spf1`, SPF cannot find an authorization policy for that domain. Confirm that the queried domain is the envelope sender domain or HELO domain from the message, rather than assuming the visible From domain is the SPF identity. Then check the sending-service setup. A service may use a provider-owned envelope domain, or it may require you to publish an SPF record for your own domain. The [SPF record mechanics explained in this SPF guide](/learning/what-is-spf) help separate those two cases. ### The domain has more than one SPF record RFC 7208 says a domain must not have multiple SPF records. Multiple records that begin with `v=spf1` create an SPF `permerror` condition. Consolidate authorized mechanisms into one record only after identifying every legitimate sender that currently uses the domain. Do not merge DNS records by guessing which include statements are safe. Compare each mechanism with the current configuration in the sending service and with message evidence. ### The SPF record authorizes the sending host A record can authorize a host and still be incomplete evidence. SPF evaluation can return `pass` only for the MAIL FROM or HELO identity being tested. A valid public record does not show that the application emitted that envelope sender, that DNS was reachable when the receiver evaluated it, or that the receiver accepted the message. Send a new message through the exact production path and inspect its receiver-added `Authentication-Results` field. [RFC 8601 defines the message header field used to report authentication results](https://www.rfc-editor.org/rfc/rfc8601.html). Record the SPF result and the identity shown beside it, such as `smtp.mailfrom` or `smtp.helo`. ### The SPF record has an error or exceeds a processing limit RFC 7208 defines SPF outcomes including `none`, `neutral`, `pass`, `fail`, `softfail`, `temperror`, and `permerror`. It also limits SPF evaluation to ten DNS-query-causing terms. A record can look plausible in a DNS response but fail because recursive `include`, `a`, `mx`, `exists`, `redirect`, or `ptr` processing exceeds that limit. Treat a DNS-processing failure as a record-design issue until message evidence shows otherwise. Trace the include chain from the actual record, identify which sending services require each mechanism, and remove only mechanisms that no longer represent a legitimate sender. ### The SPF result passes but DMARC still fails SPF pass is only one possible DMARC authentication path. For SPF to support DMARC, the domain authenticated by SPF must align with the domain in the visible From address. A provider-owned bounce domain may pass SPF without aligning to your From domain. Check the message's `Authentication-Results` fields and compare the visible From domain with `smtp.mailfrom`. If they do not align, examine DKIM as the alternate DMARC path. The [difference between DKIM and SPF](/learning/dkim-vs-spf-difference) explains why a message can have a useful DKIM result even when SPF alignment is unavailable. ## How to act on the result Work from the narrowest evidence outward. - For a missing record, confirm which identity the sending service uses. Publish only the DNS record generated for your account and sending domain. - For multiple SPF records, make one inventory of every authorized sender, then combine valid mechanisms into one `v=spf1` record. Retain unrelated TXT records. - For a DNS-limit or syntax problem, trace the existing record before shortening it. Removing an include can break mail from a service that still uses it. - For a passing record with an SPF failure in a delivered message, compare the message's envelope identity with the DNS owner you checked. Then inspect the sender's verification or authentication status in its own interface. - For an SPF pass that does not align, validate DKIM on the same message. Do not change the DMARC policy based only on a public SPF lookup. Keep the four evidence layers separate: - DNS: query the published record through the authoritative server and at least one public resolver. - Vendor: confirm the sender's current domain or authentication status in the sending provider's interface. - Message: send a real message through the same production application, sender identity, gateway, and recipient path. - DMARC: review aggregate reports after data accumulates to identify sources and alignment outcomes across the domain. A green DNS result is not a delivered-message test. A sender interface indicator is not proof that a receiving mailbox provider evaluated the same path successfully. ## How to retest After a DNS correction, rerun the same Proofpoint public form with the same domain and repeat the public lookup: ```bash dig +short TXT yourdomain.com ``` Next, send a fresh message through the exact sender you changed. Inspect the delivered message's `Authentication-Results` header and compare the SPF identity with the visible From domain. Finally, review DMARC aggregate-report data after reports have had time to arrive. The expected change is a corrected DNS answer first, then a matching delivered-message result. These observations may not appear at the same time. ## Move from a one-time SPF check to sender inventory A Proofpoint SPF check can show the public record at one point in time. It does not identify every production source that uses the domain, track later DNS drift, or determine when the domain is ready for a DMARC policy change. Palisade is agentic DMARC software that analyzes DMARC aggregate-report data, identifies sending sources and authentication or alignment issues, and creates prioritized remediation tickets. It proposes the next policy step for human review, but it does not autonomously change your DMARC policy or guarantee delivery. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=proofpoint&utm_content=proofpoint-spf-checker) Palisade does not grant access to Proofpoint Hosted SPF, repair a public SPF record automatically, or prove that every future message will authenticate. ## Sources and further reading - [Proofpoint DMARC/SPF creation and check tool](https://www.proofpoint.com/jp/cybersecurity-tools/dmarc-spf-creation-wizard) - [Proofpoint Hosted Sender Policy Framework technical brief](https://www.proofpoint.com/sites/default/files/product-overview/pfpt-us-to-hosted-spf.pdf) - [RFC 7208: Sender Policy Framework](https://www.rfc-editor.org/rfc/rfc7208.html) - [RFC 8601: Message Authentication Status](https://www.rfc-editor.org/rfc/rfc8601.html) - [Palisade SPF checker](/tools/spf) ## Frequently asked questions ### Can I use the Proofpoint SPF checker for several domains? Yes. Proofpoint's public Japanese checker states that you can enter one domain per line and check up to 100 domains. Treat each result as a public DNS observation for that domain, then validate important senders with a delivered message. ### Does a published SPF record prove that mail passes SPF? No. A published record proves only that a DNS record is visible. SPF pass depends on the MAIL FROM or HELO identity used by the actual message, DNS processing during evaluation, and the receiver's evaluation of that message. ### Does SPF pass mean DMARC passes? No. SPF must pass and the authenticated SPF domain must align with the visible From domain to satisfy the SPF branch of DMARC. DKIM can independently provide an aligned authentication path. ### Should I create a second SPF record for a new email provider? No. RFC 7208 permits only one SPF record for a domain. Add the new provider's required mechanism to the existing SPF record after confirming that it belongs to an active sender. ### Can a public SPF checker show my Proofpoint Hosted SPF settings? No. A public checker can inspect public DNS. Proofpoint describes Hosted SPF as a service for Email Fraud Defense customers with a customer portal, and public DNS results do not reveal tenant access or portal settings. --- # Reply.io email warmup: what it does and cannot prove Canonical: https://www.palisade.email/learning/reply-io-email-warmup > Reply.io email warmup starts when you connect a mailbox and tracks warmup activity, but it does not prove inbox placement or instant outreach readiness. Reply.io email warmup is an included feature that starts when you connect a mailbox to Reply.io. Reply.io says it uses automated peer-to-peer interactions between genuine inboxes and shows each inbox's reputation score, warmup stage, and daily activity. That describes activity inside Reply.io. It does not prove inbox placement, establish a universal sending limit, or make a mailbox instantly ready for high-volume outreach. ## Quick takeaways - Reply.io says warmup starts when a mailbox is connected. - Reply.io says warmup is included for every account added to Reply. - Reply.io describes its warmup network as peer-to-peer interactions between real inboxes. - Reply.io displays a reputation score, warmup stage, and daily activity per inbox. - A Reply.io warmup status does not verify how a recipient mailbox provider will place a future campaign. - Domain authentication and real delivered-message evidence remain separate checks. ## How Reply.io email warmup works [Reply.io's email warmup page](https://reply.io) states, "Warmup starts the moment you connect." The same page says the feature is "Included for every account you add to Reply." Reply.io describes the mechanism as a peer-to-peer network: "Every mailbox builds sender reputation through a peer-to-peer network of real inboxes no bots, no manual work, no extra subscriptions." It also says connected mailboxes can use SMTP or OAuth and be managed from the Reply dashboard. The vendor says users can "Track progress per inbox" and monitor a reputation score, warmup stage, and daily activity. Those fields can help an operator see Reply.io's reported warmup activity for a connected mailbox. The supplied public material does not document how the reputation score is calculated, a score that is safe for campaign launch, or a specific interface path for changing warmup settings. Warmup is one input within the wider [email deliverability](/email-deliverability) picture. Recipient systems can use their own signals and local policies when deciding whether to accept, filter, or place mail. A platform-reported score is therefore not the same evidence as a message delivered through the real production path. ## When the answer changes Reply.io's warmup claim changes meaning depending on the question being asked. - If the question is whether Reply.io begins warmup activity after mailbox connection, the vendor says yes. - If the question is whether every connected mailbox has access to warmup, Reply.io says it is included with every account added to Reply. - If the question is whether warmup guarantees inbox placement, the available primary material does not establish that outcome. - If the question is whether a mailbox is ready immediately, the answer is no as a verified deliverability claim. Reply.io says warmup starts immediately after connection, but it separately displays "14 Days from purchase to first send." That is vendor marketing text, not a universal readiness rule. - If the mailbox's domain lacks correct authentication, warmup activity does not replace the need to publish and validate SPF, DKIM, and DMARC. A sender-platform example such as [setting up SPF and DKIM for Customer.io](/learning/how-do-i-set-up-spf-and-dkim-for-customer-io) illustrates the separate authentication work. Use this decision rule: treat the Reply.io warmup status as a platform activity signal, then verify the domain, the sender configuration, and messages sent through the actual route before treating outreach as operationally ready. ![Decision flow showing Reply.io warmup status as one input, followed by domain authentication checks and real-message evidence before outreach assessment](/images/editorial/reply-io-email-warmup/reply-io-email-warmup-decision-flow.webp "1200x829") *Source: Palisade.* ## A worked readiness check A Reply.io warmup stage can answer whether Reply.io reports ongoing warmup activity. It cannot answer whether SPF or DKIM passed for a campaign message, whether those identifiers aligned with the visible From domain, or how a recipient handled that message. Use a record and message evidence checklist instead of treating one dashboard status as a complete result: ```text Illustrative readiness evidence Visible From domain: yourdomain.com SPF: pass with an aligned envelope domain DKIM: pass with a d= domain aligned to yourdomain.com DMARC: pass for the delivered production message Reply.io: warmup stage and daily activity reviewed Recipient evidence: delivered test message and raw Authentication-Results header retained ``` > Do not publish account-generated selectors, SMTP credentials, OAuth tokens, full message headers, or customer addresses when collecting this evidence. An `Authentication-Results` header records a receiving system's authentication assessment. [RFC 8601](https://datatracker.ietf.org/doc/html/rfc8601) defines the header field and its result syntax. It is useful message-level evidence, but it remains evidence from that delivered message and receiving system. This distinction matters when a Reply.io mailbox appears active in warmup but a real campaign path uses a different From domain, return path, signing configuration, or gateway. The warmup view may still be useful, yet it does not prove that the production route uses the authentication configuration you intended. ## What to check next Start with the evidence you have. If you only have the Reply.io dashboard, record the connected mailbox, reported warmup stage, daily activity, and the date reviewed. Do not infer recipient placement from those fields. If you have the sending domain, run it through Palisade's [email security score checker](/tools/email-security-score) to inspect its public email-security posture. Compare the result with the domain used in the visible From address. A public DNS-based check cannot prove that Reply.io is using that configuration for a live message, that a receiving provider will place it in the inbox, or that later DNS changes will not affect sending. If you have a delivered test message, preserve a redacted copy of the raw headers and check its `Authentication-Results` values. Verify that the message came from the exact Reply.io production configuration you plan to use. If you run several domains or regularly add new sending sources, the unresolved issue is inventory and ongoing DMARC evidence. [AI email warmup: what it is and what it cannot prove](/learning/ai-email-warmup) explains why a warmup claim should stay separate from authentication and recipient outcomes. Palisade autonomously analyzes DMARC aggregate-report data, identifies sending sources and authentication or alignment issues, and creates prioritized remediation tickets. It can propose a next DMARC policy step, while a human reviews the evidence and applies any change. ## Check the domain behind the warmed mailbox Before relying on Reply.io's warmup status, inspect the public email-security posture of the exact domain used for outreach. Then compare that DNS evidence with a real delivered message from the configured mailbox. [Check the domain's email security](/tools/email-security-score) A public check does not prove Reply.io's current warmup activity, repair sender authentication, monitor every mailbox, or guarantee inbox placement. For an ongoing multi-domain DMARC workflow, [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=warm-up_sending_practices&utm_content=reply-io-email-warmup). Signup and trial do not require a credit card. ## Sources and further reading - [Reply.io email warmup and mailbox information](https://reply.io) - [RFC 8601: Message Authentication Status](https://datatracker.ietf.org/doc/html/rfc8601) - [Palisade email security score checker](/tools/email-security-score) - [Palisade deliverability learning hub](/email-deliverability) ## Frequently asked questions ### Does email warm up actually work? There is no published evidence that warmup improves inbox placement, so treat the claim as unproven. Reply.io describes the activity it runs and the fields it tracks, which is a product description rather than a measured outcome. Judge readiness from your domain's authentication and from real delivered messages instead. ### How much does Reply.io cost? Reply.io's displayed homepage pricing starts at "$ 49" per user per month billed annually for Email Volume and "$ 89" per user per month billed annually for Multichannel. These are displayed starting prices, not a complete summary of plan entitlements or current account-specific charges. ### How to warm up email instantly? You cannot warm a mailbox instantly, even though Reply.io starts warmup the moment you connect one. Starting the feature is not the same as the mailbox being ready for outreach. Reply.io's own page shows "14 Days from purchase to first send," so plan for a wait rather than an instant switch. ### Does a Reply.io reputation score prove that DMARC passes? No, because the score is Reply.io's own measure and the vendor does not define it as DMARC evidence. To know whether DMARC passes, read the authentication results on a real delivered message and review DMARC aggregate reports once data has accumulated. --- # Reverse DNS for email server Canonical: https://www.palisade.email/learning/reverse-dns-for-email-server > Reverse DNS for email server setup requires the IP owner to publish a PTR record and a matching forward DNS record for the sending hostname. Reverse DNS for an email server requires the organisation that allocated the sending IP address, usually an ISP, hosting provider, or cloud provider, to create a PTR record in its reverse DNS zone. The PTR hostname must resolve back to that same sending IP through an A record for IPv4 or AAAA record for IPv6. Google requires valid forward and reverse DNS records for all senders from February 1, 2024. ## Quick takeaways - A domain owner usually cannot add a PTR record in its normal DNS zone. - The IP address owner controls the reverse DNS zone and must publish the PTR record. - A PTR record maps a sending IP address to a hostname. - The PTR hostname needs a matching A or AAAA record that returns the original IP address. - IPv4 reverse DNS uses `IN-ADDR.ARPA`; IPv6 reverse DNS uses the separate `IP6.ARPA` tree. - RFC 5321 says an SMTP client MUST use a primary hostname in EHLO or HELO when possible. ## Who is affected? This requirement affects organisations that send email directly from a server, virtual machine, appliance, or dedicated outbound IP address. It also affects teams using an email service where they control the sending IP or are responsible for its mail-server configuration. The party that owns the domain is not necessarily the party that controls reverse DNS. Microsoft documents that reverse zones are "typically" maintained by the ISP, which is why a server operator must ask the IP provider to create or delegate the PTR record rather than adding it beside the domain's MX or SPF records in ordinary DNS. This ownership model follows the DNS design. [RFC 1035](https://www.rfc-editor.org/rfc/rfc1035.txt) defines the IPv4 reverse namespace as address-structured, with reversed octets below `IN-ADDR.ARPA`. That structure lets DNS operators delegate reverse zones by network allocation. Control therefore follows the assigned address space. If a third-party email platform sends all production mail from its own shared addresses, that provider may operate the reverse DNS. Confirm the actual outbound IP before opening a request. A hostname configured on an application server does not establish what IP receivers see during SMTP delivery. For background on the DNS layers involved, see [Palisade's infrastructure learning hub](/learning/infrastructure). ## What are the requirements? ### The IP owner publishes a PTR record A PTR record maps an IP address to a domain name. RFC 1035 defines PTR RDATA as one `PTRDNAME`, a domain name pointing to a location in the DNS namespace. For an IPv4 mail server at `192.0.2.25`, the reverse query reverses the address octets: ```text 25.2.0.192.in-addr.arpa. IN PTR mail.yourdomain.com. ``` The example is illustrative only. Ask the IP owner to publish the actual reverse record for the production sending address. Do not copy example values into a live DNS zone. The request should include: - The exact outbound IPv4 or IPv6 address. - The hostname you want the PTR record to return. - Confirmation that the hostname already has a matching forward record. - The purpose of the address, such as outbound SMTP. The provider may have a process for setting reverse DNS directly, may ask for a support request, or may assign a hostname under its own domain. The provider-specific process is outside this rule. What matters is that the authoritative reverse DNS response identifies a hostname that forwards back to the same IP. ### The PTR hostname resolves back to the sending IP Google's [Email sender guidelines](https://support.google.com/a/answer/81126) require all senders to have valid forward and reverse DNS records. The guidance says the PTR record must resolve to the sending server's hostname, and that hostname must resolve back to the same IP address. This two-way relationship is often called forward-confirmed reverse DNS. [RFC 8601](https://www.rfc-editor.org/rfc/rfc8601) describes the `iprev` method as a reverse lookup followed by a forward lookup that confirms the original address. For the preceding IPv4 example, the forward record needs to return `192.0.2.25`: ```text mail.yourdomain.com. IN A 192.0.2.25 ``` For an IPv6 sending address, use an AAAA record instead: ```text mail.yourdomain.com. IN AAAA 2001:db8:25::25 ``` A PTR record by itself does not complete the check. A hostname that resolves to a different IP, or does not resolve at all, does not meet Google's stated forward and reverse DNS condition. ![Reverse DNS validation path from a sending IP through a PTR hostname and back to the same IP](/images/editorial/reverse-dns-for-email-server/reverse-dns-for-email-server-validation-flow.webp "1200x829") *Source: Palisade.* ### IPv6 needs its own reverse DNS request An IPv4 PTR record does not cover an IPv6 address. [RFC 3596](https://www.rfc-editor.org/rfc/rfc3596.txt) specifies that IPv6 reverse mapping uses nibble-reversed labels beneath `IP6.ARPA`. An IPv6 address such as `2001:db8::25` has a structurally different reverse name: ```text 5.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa. IN PTR mail.yourdomain.com. ``` This is illustrative only. The IP provider must create or delegate the real reverse record. If your mail system can send from both IPv4 and IPv6, validate each address separately. ### EHLO or HELO should identify the server hostname Reverse DNS and the SMTP greeting are related operational checks, but they are not the same DNS record. [RFC 5321](https://www.rfc-editor.org/rfc/rfc5321) says an SMTP client "MUST, if possible, ensure that the domain parameter to the EHLO command is a primary host name." Use the PTR hostname as the EHLO or HELO name when your mail-server software allows it and the hostname is a valid primary hostname for that server. This makes the server identity easier to inspect across DNS and SMTP evidence. RFC 5321 also says a receiving SMTP server that verifies the EHLO name against the client IP "MUST NOT refuse to accept a message on that basis" if the verification fails. A mismatch alone is not a universal protocol-level rejection rule. It can still create an operational problem for receiver checks or policy rules, so investigate a mismatch with the guidance in [reverse DNS that does not match an SMTP banner](/learning/reverse-dns-does-not-match-smtp-banner). ## When does the requirement take effect? Google's Email sender guidelines set the operative date: valid forward and reverse DNS records are required for all senders starting February 1, 2024. That date applies to Google's published sender guidance. It is not a universal date created by RFC 1035, RFC 3596, RFC 5321, or RFC 8601. Those RFCs define DNS, SMTP, and the `iprev` method, rather than a mailbox-provider enforcement schedule. The reverse DNS mechanism is older than Google's sender rule. RFC 1035 specifies IPv4 reverse mapping, while RFC 3596 specifies IPv6 reverse mapping. Neither RFC requires a provider to accept a particular reverse-DNS request or says every receiving system will reject mail when reverse DNS is missing. ## How do I implement the requirement? ### 1. Identify every production sending IP Collect the public IP addresses used by the exact SMTP path that sends mail. Include separate IPv4 and IPv6 addresses. Check production message headers, mail-transfer-agent logs, or the outbound relay configuration. Do not use a private address from an application host or a load balancer's internal network. ### 2. Choose the mail-server hostname Choose a hostname under a domain you control, such as `mail.yourdomain.com`. Publish its A record for IPv4 and its AAAA record for IPv6 where applicable. Confirm that the record resolves to the same public address that sends the mail. Do this before asking the IP owner to create the PTR record. ### 3. Ask the IP owner to create the reverse record Open a request with the ISP, host, or cloud provider that allocated the sending IP. Provide the IP address and the fully qualified hostname. Ask whether the provider will publish the PTR record or delegate control of the applicable reverse zone. Do not ask the registrar for your domain unless it also allocated the sending address. > Do not change an existing PTR record until you know every service using that IP. A shared address can support more than one workload, and an unplanned change can disrupt another service's hostname checks. ### 4. Set the SMTP EHLO or HELO hostname Configure the sending mail-transfer agent to use its primary hostname in EHLO or HELO where possible, as RFC 5321 requires. Send a controlled test message through the same production path. Compare the greeting name, the observed sending IP, and the PTR hostname. If the SMTP banner does not match the reverse DNS name, follow the remediation guidance for [reverse DNS that does not match an SMTP banner](/learning/reverse-dns-does-not-match-smtp-banner). ### 5. Repeat for IPv6 If the server sends over IPv6, ask the IPv6 address owner for the separate `IP6.ARPA` reverse mapping. Confirm that the chosen hostname has an AAAA record returning the same IPv6 address. ## How do I validate compliance? Start with the reverse lookup. Use the [IP reputation checker](/tools/ip-reputation) with the public sending IP to inspect the PTR hostname returned for that address. Then use the [DNS lookup tool](/tools/dns-lookup) to query the PTR hostname's A record or AAAA record. Confirm that the forward response includes the original sending IP. This manual sequence follows the two steps described in RFC 8601's `iprev` method. The reverse lookup is a point-in-time DNS check. A timeout or empty response does not prove the mail server has no PTR record, and a PTR result does not prove the hostname forwards back correctly. Public DNS checks also do not prove which IP a specific production message used, how a receiver evaluates SMTP, or future inbox placement. Complete the operational validation with evidence from the same sending path: - Check authoritative DNS and at least one public resolver for the PTR and matching A or AAAA record. - Inspect the provider's reverse-DNS status or support confirmation if it offers one. - Send a real message through the production server and inspect its headers, source IP, and SMTP identity. - Review DMARC aggregate reports after data accumulates to confirm that expected sending sources appear in normal traffic. ## Check the PTR record for the sending IP A reverse lookup identifies the hostname currently published for a sending address. Use that result before requesting a change, then confirm the hostname's forward A or AAAA record separately. [Check the sending IP's PTR record](/tools/ip-reputation) An IP reputation lookup is a public point-in-time check. It cannot confirm the production SMTP path, repair a PTR record, monitor future DNS changes, or guarantee how a mailbox provider will treat a message. ## Sources and further reading - [RFC 1035: Domain names, implementation and specification](https://www.rfc-editor.org/rfc/rfc1035.txt) - [RFC 3596: DNS extensions to support IP version 6](https://www.rfc-editor.org/rfc/rfc3596.txt) - [RFC 5321: Simple Mail Transfer Protocol](https://www.rfc-editor.org/rfc/rfc5321) - [RFC 8601: Message header field for indicating message authentication status](https://www.rfc-editor.org/rfc/rfc8601) - [Google Email sender guidelines](https://support.google.com/a/answer/81126) - [Microsoft guidance for a missing PTR record](https://learn.microsoft.com/en-us/connectivity-analyzer/ip-address-does-not-have-ptr-record-dns) ## Frequently asked questions ### Can I add a PTR record in my own DNS? No, you cannot add it yourself in most cases, because the reverse zone belongs to whoever owns the IP address. Microsoft's missing-PTR guidance says reverse zones are typically maintained by the ISP or other IP-address provider. Your own DNS provider can publish the forward A or AAAA record, but the IP owner has to publish or delegate the reverse one. ### Who do I ask to set up reverse DNS for my mail server? Ask the organisation that allocated the sending IP address, such as an ISP, hosting provider, or cloud provider. Give it the public sending IP and the hostname that should become the PTR target. Confirm first that the hostname resolves back to that same IP. ### Does reverse DNS have to match the EHLO or HELO name? Matching is good practice rather than a hard SMTP rule. RFC 5321 says the SMTP client MUST use a primary hostname in EHLO or HELO where possible, and it also says a receiver MUST NOT refuse a message purely because verifying that name against the client IP failed. Individual receivers can still weigh a mismatch as they choose. ### How do I check whether reverse DNS is set up correctly? Check the sending IP's PTR response, then resolve the returned hostname's A or AAAA record and compare it with the original IP. RFC 8601 describes this reverse-then-forward confirmation method. Also inspect a message sent through the real production path. ### When did reverse DNS become a Google sender requirement? Google's Email sender guidelines require valid forward and reverse DNS records for all senders starting February 1, 2024. That is Google's documented requirement date. Other mailbox providers need their own current documentation. ### Do I need separate reverse DNS for IPv6? Yes, IPv6 needs its own reverse DNS. RFC 3596 puts IPv6 reverse mapping in a separate tree under `IP6.ARPA`, so an IPv4 PTR record does nothing for an IPv6 sending address. The hostname it points to also needs an AAAA record that returns that same IPv6 address. --- # Reverse DNS lookup email validation Canonical: https://www.palisade.email/learning/reverse-dns-lookup-email-validation > Reverse DNS lookup email validation checks whether an IP address has a PTR hostname. Learn what PTR results show and what they cannot validate. Reverse DNS lookup email validation starts with an IP address and checks its PTR record. A PTR record can map that IP address to a hostname, which helps identify the host associated with an address. It does not validate that a particular email address, person, or mailbox exists. Treat reverse DNS as one piece of [email infrastructure](/learning/infrastructure), then compare it with evidence from the actual sending path. ## Quick takeaways - Reverse DNS uses a PTR record to map an IP address to a hostname. - A PTR lookup is different from looking up an email address or validating a mailbox. - MX records describe where a domain receives mail, while PTR records answer an IP-to-hostname question. - A public DNS result does not prove which server sent a message or how a receiver handled it. - Use a delivered message header when you need evidence about the actual sending IP. ## What this tool checks A reverse DNS check asks DNS for the PTR record associated with an IP address. [DNS Checker describes a PTR record as a record used in a reverse IP lookup to map an IP address to a domain name](https://dnschecker.org/). That is a narrower test than email validation. A PTR result can identify a hostname associated with an IP address, but it does not show whether an email address accepts mail, whether a mailbox is active, or whether a message from that address was sent through the IP. The [Palisade IP reputation checker](/tools/ip-reputation) returns the reverse DNS (PTR) answer for a public IP address. [Palisade DNS Lookup](/tools/dns-lookup) takes a domain rather than an IP, so it is not a PTR checker; use it for the forward half of the evidence, such as the A or AAAA record of a returned hostname. A public lookup cannot prove the production sending path, message signing, continuous DNS state, or why one receiver rejected one message. ![Reverse DNS result map showing the difference between a PTR hostname, no PTR answer, and mailbox validation](/images/editorial/reverse-dns-lookup-email-validation/reverse-dns-lookup-email-validation-result-map.webp "1200x829") *Source: Palisade.* ## How to run the check ### 1. Get the sending IP from message evidence Start with a message that travelled through the path you are investigating. Open its raw headers and identify the sending IP from the received-message trace or another receiver-provided field. Do not begin with the visible From address. Reverse DNS does not turn an email address into a hostname. If the incident concerns a sender's authentication result, keep a copy of the redacted headers so you can compare the IP, sending domain, and authentication evidence later. The [email header analysis guide](/learning/analyze-email-headers-online) can help separate visible address fields from transport evidence. ### 2. Query the PTR record for that IP Use a public DNS query with the IP address you collected. The following command is illustrative only. Replace `192.0.2.25` with the IP from your own message evidence. ```bash dig +short -x 192.0.2.25 ``` An IPv4 reverse query uses the special reverse-DNS namespace automatically when you use `dig -x`. The returned hostname, if one exists, is the PTR answer for that IP. You can run the same reverse query in the [Palisade IP reputation checker](/tools/ip-reputation), which reads the PTR record for the IP you enter. Keep the input type matched to the question you are asking. A domain lookup in Palisade DNS Lookup can help with MX or TXT records, but an IP-to-hostname question requires the reverse lookup, and that tool does not accept an IP as input. ### 3. Record the result with its context Save the IP address, the PTR response or absence of one, the resolver used, and the time of the query. Then record where the IP came from: a delivered message, a mail-server log, or a provider dashboard. This context matters because an IP can belong to shared infrastructure, an outbound relay, or an intermediate service. A PTR hostname alone does not establish that the hostname is the same as the visible From domain. ### 4. Compare the PTR result with the message path Check whether the PTR hostname is consistent with the transport path you observed. If the delivered message points to a different sending IP than the one you queried, stop and resolve that mismatch before drawing a conclusion. For a routing question, [inspect the receiving domain's MX records](/tools/mx) separately. [MXToolbox explains that an MX test lists MX records for a domain in priority order](https://mxtoolbox.com/MXLookup.aspx). MX records and PTR records answer different DNS questions. ## How to interpret the results ### A PTR hostname is returned A hostname was published for the queried IP address. This identifies the host associated with that reverse-DNS answer at the time of the lookup. It does not validate an email address. It also does not prove that the host sent the message you are investigating. Compare the result to the actual message trace before assigning the IP to a sender or service. If the hostname is unfamiliar, collect more evidence rather than changing DNS. Review the message headers, confirm the IP through the sending platform or server logs, and identify whether a relay altered the path. ### No PTR hostname is returned The lookup did not return a PTR hostname for the IP through the resolver you used. Recheck the IP copied from the message and query again against an authoritative source where you have access. Do not convert this result into a claim that the mailbox is invalid or that all mail from the IP will fail. The PTR definition supports an IP-to-hostname lookup only. It does not establish a mailbox-validation rule or a receiver's acceptance decision. ### The PTR hostname does not match the domain you expected A mismatch can mean the IP belongs to shared infrastructure, a relay, or another host in the path. It can also mean that the domain you expected is not the hostname published for that IP. This is an investigation threshold, not a repair instruction. Confirm the actual sender with delivered-message evidence and the sending service's own records before requesting a DNS change. Do not publish a hostname copied from another account or tenant. ### You only have an email address An email address is insufficient input for a reverse DNS lookup. Reverse DNS begins with an IP address and returns a hostname when a PTR record exists. For a message-specific problem, obtain the raw headers from a delivered message. For a domain configuration question, inspect the relevant DNS record type instead. [DKIM setup for Salesforce](/learning/dkim-keys-salesforce) is an example of a different DNS task: it concerns DKIM key publication and message signing, not PTR records. ## How to act on the result Use the smallest next action that matches the evidence. - If a PTR hostname is returned and it matches the sending IP in the delivered message, keep the result as transport-identification evidence. Continue with the message's authentication results if the issue is DMARC, SPF, or DKIM. - If no PTR hostname is returned, verify the IP and resolver first. Escalate to the party that controls the IP address only after you have evidence that this is the production sending IP. - If the PTR hostname is unexpected, identify whether a relay or shared service sent the message. Ask the service provider or network operator which hostname, if any, they publish for that IP. - If the concern is inbound routing, inspect MX records for the receiving domain. Do not use a PTR result as evidence of where a domain receives mail. - If the concern is message reputation or a listed sending IP, use the actual IP as the starting evidence. A [blocklist check](/learning/blocklist-email) answers a different question from reverse DNS. > Do not change a PTR record based only on a public lookup. The party that controls the IP address also controls the reverse-DNS zone, and a change can affect systems that share that address. ## How to retest Repeat the reverse lookup for the same IP after the network operator confirms a change. Use the same command and record the new answer with the query time. ```bash dig +short -x 192.0.2.25 ``` Then send a new message through the same production path and inspect its headers again. The expected change is a PTR result that reflects the confirmed hostname for the exact sending IP. The delivered message remains separate evidence: it shows whether that IP was actually part of the path you tested. ## Validate the DNS evidence against the sending path After a PTR lookup, compare the hostname to a new delivered message and the sender's own configuration. This is the next useful step when an IT team or MSP needs to distinguish one public DNS answer from an ongoing inventory of sending sources and authentication issues. Palisade is agentic DMARC software that analyzes DMARC aggregate-report data, identifies sending sources and authentication or alignment issues, and creates prioritized remediation tickets. It can propose the next DMARC policy step for human review, but it does not change a DMARC policy or prove that every future message will authenticate. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=infrastructure&utm_content=reverse-dns-lookup-email-validation) A PTR lookup does not validate a mailbox, continuously monitor a sending path, repair DNS, or guarantee receiver acceptance. ## Sources and further reading - [DNS Checker PTR lookup reference](https://dnschecker.org/) - [MXToolbox MX lookup reference](https://mxtoolbox.com/MXLookup.aspx) - [Palisade DNS Lookup](/tools/dns-lookup) ## Frequently asked questions ### Is it possible to reverse lookup an email address? No, not with reverse DNS. Reverse DNS uses a PTR record to map an IP address to a hostname, and nothing in it maps an email address to a person, a mailbox, or a confirmed recipient. ### Can I do a reverse DNS lookup? Yes, anyone can run one. Start with an IP address and query its PTR record. If a PTR record exists, the answer maps that IP address to a hostname or domain name. ### What is the best free reverse email lookup? No reverse DNS tool answers this, because reverse DNS looks up an IP address rather than an email address. Pick the tool that matches the evidence you actually hold: an IP for a PTR check, a domain for its DNS records, or the raw headers when you need to trace a message path. ### What is reverse DNS in email? Reverse DNS in email is a PTR-based lookup that maps an IP address to a hostname. It can help identify a host associated with an observed sending IP, but it does not validate a specific mailbox. ### Does a PTR record prove that an email will be delivered? No, a PTR record proves nothing about delivery, because it only shows a public DNS mapping for an IP address. It says nothing about the production message path, a receiver's filtering, the authentication results on a message, or where future mail lands. ### Are MX and PTR records the same thing? No, they point in opposite directions. MX records name the mail exchangers that accept mail for a domain, listed in priority order. PTR records map an IP address back to a hostname in reverse DNS. --- # Secure email gateway for Office 365: what is confirmed Canonical: https://www.palisade.email/learning/secure-email-gateway-office-365 > Secure email gateway Office 365 information is not confirmed by Microsoft's public homepage. Learn what to verify before selecting email controls. A secure email gateway for Office 365 cannot be identified from Microsoft's public homepage alone. Microsoft says Microsoft 365 includes "advanced security," but that statement does not name a gateway product, define its protections, confirm licensing, or show how mail is routed. Before treating a Microsoft 365 control as a secure email gateway, verify the exact product documentation, entitlement, configuration, and delivered-message evidence for the domain. ## Quick takeaways - Microsoft's public homepage says Microsoft 365 includes "advanced security," without identifying a secure email gateway product or its behavior. - A security product name does not prove that protection is enabled for a specific Office 365 tenant. - A gateway decision needs evidence of the actual mail path, not only a vendor feature list. - Email authentication is an adjacent control, not proof that a gateway is filtering or protecting mail. - A public DNS or security check cannot reveal a receiver's private filtering decision or future message handling. - Use the wider [email-threats learning hub](/learning/threats) to assess controls beyond one product category. ## What a secure email gateway claim needs to establish "Secure email gateway" is often used as a category label, but a useful Office 365 claim needs more than that label. It must establish which Microsoft product or service is in scope, what traffic it evaluates, what protection is included, and how an administrator confirms that the intended mail path uses it. Microsoft's [Microsoft 365 homepage](https://www.microsoft.com/) states: "Microsoft 365 delivers cloud storage, advanced security, and Microsoft Copilot in your favorite apps, all in one plan." That is a broad product statement. It does not document a Microsoft secure email gateway name, mail-flow architecture, protection policy, quarantine behavior, licensing boundary, or connector configuration. That distinction matters when an IT team is selecting controls. A category name cannot answer operational questions such as: - Does the tenant have the relevant feature or entitlement? - Does inbound or outbound production mail pass through the intended control? - Which messages are covered, bypassed, or handled by another system? - What evidence shows that a delivered message followed the expected path? - Which authentication results did the recipient receive? For foundational context, [email security](/learning) covers the broader set of controls that protect organizational email. A gateway category is only one part of that work. ![Decision flow for verifying an Office 365 secure email gateway claim through product documentation, tenant status, message evidence, and domain-level checks](/images/editorial/secure-email-gateway-office-365/secure-email-gateway-office-365-verification-flow.webp "1200x829") *Source: Palisade.* ## When the answer changes The answer changes when current Microsoft documentation establishes the exact product and the tenant's configuration. Until then, do not infer a gateway capability from the phrase "advanced security." Use this decision rule: - If you only have a marketing-level Microsoft 365 statement, treat the secure email gateway question as unresolved. - If you have current Microsoft product and licensing documentation, identify the documented service and its stated scope. - If an administrator can show tenant configuration, confirm that the documented service is enabled for the intended users and domains. - If you have a delivered production message and its full headers, inspect the actual authentication and handling evidence for that path. - If you only have a public DNS result, use it for domain-level checks. Do not use it as proof of gateway processing, tenant configuration, or a recipient's private filtering decision. A green status in any one layer is incomplete evidence. DNS can show published records. A tenant interface can show configuration. A real message can show results for one delivery path. DMARC aggregate reports can later show the sending sources that use a domain over time. Each answers a different question. DKIM is one adjacent authentication control. It helps a receiving system evaluate whether a message has a valid cryptographic signature associated with a domain, but a DKIM result does not establish which gateway processed the message. See [DKIM for Office 365](/resources-post/dkim-for-office-365) for the Office 365-specific topic. > Do not change mail routing or disable an existing mail-security control based on a category label or a public lookup. Confirm the production path and retain an approved rollback plan before making mail-flow changes. ## A worked evidence record for an Office 365 review Record the evidence separately so a product claim does not become a deployment claim. ```text Question: Is a documented secure email gateway active for your Office 365 mail path? Product documentation: - Exact Microsoft product name: [confirm from current Microsoft documentation] - Stated protection scope: [confirm from current Microsoft documentation] - Licensing or entitlement: [confirm from current Microsoft documentation] Tenant evidence: - Tenant or policy status: [administrator-confirmed] - Protected domains or users: [administrator-confirmed] - Intended inbound and outbound path: [administrator-confirmed] Message evidence: - Test sender: alerts@yourdomain.com - Recipient: test-recipient@yourdomain.com - Full delivered headers: [redacted copy retained internally] - Authentication-Results: [inspect the delivered message] - Observed handling: [inbox, junk, quarantine, rejection, or other documented result] Domain evidence: - DMARC record: _dmarc.yourdomain.com - SPF record: yourdomain.com - DKIM selector: selector1._domainkey.yourdomain.com ``` The first three sections establish different facts. Product documentation describes a service. Tenant evidence shows whether administrators configured it. Message evidence shows what happened to one delivered message. Domain evidence shows publicly published authentication records. Do not publish full message headers, private routing details, tokens, or customer addresses when collecting this information. Redact personal data before sharing diagnostic evidence outside the organization. ## What to check next Start with the evidence you actually have. If you have a Microsoft 365 subscription description or homepage statement, locate current Microsoft documentation that names the relevant email-security product and states its coverage. Confirm the licensing and configuration terms in that documentation before choosing a routing design. If you administer the tenant, collect the current status from the relevant Microsoft security and mail-flow controls, then test a message through the same production path used by employees or applications. Keep the delivered message's raw headers for the review. A configuration screen alone does not show that an application used the expected sender identity or route. If your question is about domain-level email security, use Palisade's [email security score tool](/tools/email-security-score) to inspect publicly visible security and authentication signals. Compare the result with the domain's intended DNS configuration and the headers from a real message. For a wider product-category decision, [email security software](/learning/email-security-software) can help separate the question of required controls from the unverified assumption that a particular Office 365 deployment already provides them. ## Verify the Office 365 email-security evidence Use [Palisade's email security guide](/learning) to review the domain-level controls that sit alongside mail filtering, including the evidence that DNS records and delivered messages can provide. A domain-level review does not identify a Microsoft gateway product, prove tenant licensing or policy status, show a third-party route, or guarantee inbox placement. ## Sources and further reading - [Microsoft 365 homepage](https://www.microsoft.com/) - [Palisade email security score tool](/tools/email-security-score) - [Palisade email security guide](/learning) ## Frequently asked questions ### What is Microsoft's secure email gateway? Microsoft does not sell a product called a secure email gateway. Its homepage says Microsoft 365 includes "advanced security," but it never names a secure email gateway, describes a mail-flow architecture, or sets out what gets filtered. Check Microsoft's current product documentation for the specific email-security service and licence your tenant holds. ### What is a secure email gateway? A secure email gateway is a system that mail passes through before it reaches or leaves your mailboxes, so messages can be scanned, filtered, quarantined, or blocked on the way. It is a category of control rather than one product, and different vendors cover different traffic. For an Office 365 review, what matters is which service your tenant actually routes mail through and what that service is licensed to do. ### Does Office 365 have secure email? Microsoft 365 does include email security features, but Microsoft's homepage only says "advanced security" and never lists which ones you get. What is actually running depends on your plan, your licences, and how the tenant is configured. Check Microsoft's current documentation for your plan, then confirm with an administrator what is switched on. ### Can a public DNS check prove that Office 365 email protection is active? No, because a DNS check reads records such as DMARC, SPF, and DKIM and nothing beyond them. It cannot show a tenant's security-policy status, the route production mail takes, a receiver's private filtering decision, or how your next message will be handled. Confirm those with the tenant configuration and a real delivered message. ### Does DKIM prove that a secure email gateway processed a message? No, because DKIM only tells a receiver that a message carries a valid signature tied to a domain. It names no system in the delivery path, so it cannot show which gateway handled the message or whether your intended controls were active at all. Read the full delivered headers if you need to trace the route. --- # SendGrid email warmup: what you can verify first Canonical: https://www.palisade.email/learning/sendgrid-email-warmup > SendGrid email warmup needs current provider guidance. Verify your sending path and email authentication before adopting a ramp schedule for your account. SendGrid email warmup should begin with a verified view of the exact sending path and its authentication, not a copied volume schedule. Twilio identifies the product as the "Twilio SendGrid Email API," but the public pages cited here do not document a current SendGrid warm-up workflow, ramp schedule, or inbox-placement outcome. Treat any uncited schedule as unverified until SendGrid publishes guidance that applies to your account and sending configuration. ## Quick takeaways - A SendGrid warm-up schedule is provider-specific guidance, not a universal DNS setting. - The available SendGrid support landing page points to product guides and API documentation, but does not define a warm-up process. - A sending-volume plan cannot prove that a domain is authenticated or that a message will reach the inbox. - Separate authentication configuration from sending-volume decisions. - Inspect the visible sending domain before treating a deliverability problem as a warm-up problem. - Receiver inbox placement remains a receiver-controlled decision. ## What SendGrid email warmup can mean "SendGrid email warmup" is often used to describe gradually changing sending behavior before increasing mail volume. That phrase alone does not identify the relevant configuration, the appropriate volume, or the result a mailbox provider will make. Twilio describes SendGrid as the [Twilio SendGrid Email API](https://www.twilio.com/). Its [SendGrid support center](https://support.sendgrid.com/) directs customers to product guides and API documentation. Neither cited page publishes a warm-up definition, a daily ramp, a duration, or a threshold that can be safely applied to every SendGrid account. That distinction matters because several different questions can hide behind one search: - Is the visible From domain authenticated for the messages being sent? - Is the mail sent through the intended SendGrid configuration? - Is the question about a shared or a dedicated sending path? - Is a receiver rejecting, filtering, or placing a specific message differently? - Has SendGrid published current guidance for the account type and feature in use? Do not convert a generic warm-up recommendation into a SendGrid operating rule without a current SendGrid document that states it. A schedule copied from another email service can omit conditions that change the advice. For wider context on the factors outside any one sending platform, see [email deliverability](/email-deliverability). For SendGrid domain-authentication work, use [how to set up SPF and DKIM for SendGrid](/learning/how-do-i-set-up-spf-and-dkim-for-sendgrid) rather than assuming that a volume change repairs authentication. ![Decision flow for separating a SendGrid warm-up question from authentication and receiver-specific evidence](/images/editorial/sendgrid-email-warmup/sendgrid-email-warmup-decision-flow.webp "1200x829") *Source: Palisade.* ## When the answer changes The right next action changes with the evidence available. Use this decision rule before changing sending volume. - If you only have a domain name, inspect its published email-security posture first. A public DNS result can identify records that are visible now, but it cannot prove the production sending path or a receiver's private placement decision. - If you have a SendGrid account question about a feature, limit, UI control, or sending-path type, check current [SendGrid product guides and API documentation](https://support.sendgrid.com/). Do not treat an external blog's schedule as provider policy. - If you have a delivered message, preserve the raw headers and compare the visible From domain with the authenticated identifiers. This distinguishes a message-level question from a public DNS question. - If a specific mailbox provider handled a message poorly, inspect that provider's available evidence and the exact delivered message. A general warm-up theory does not establish why that receiver made its decision. - If you operate several domains or sending sources, record the source, visible From domain, authentication result, and owner for each path before making a broader change. A public check and an account-level setting answer different questions. DNS confirms what resolvers can retrieve. A platform status can show what the platform reports. A delivered message shows evidence from one actual path. DMARC aggregate reports can later show sending sources and alignment outcomes after data accumulates. > Do not increase production volume merely to test a hypothesis if the sending domain or message authentication has not been checked. A volume change can make diagnosis harder and can affect legitimate mail. For adjacent ESP configuration topics, the [ESP setup learning hub](/learning/esp-setup) is the appropriate route. It does not replace current SendGrid documentation for account-specific controls. ## A worked evidence object for a SendGrid warm-up question Before asking whether to change volume, create a short evidence record. This does not prescribe a ramp. It makes the question specific enough to validate. ```text Visible From domain: updates.yourdomain.com Sending platform: Twilio SendGrid Email API Message evidence: raw headers from one delivered test message DNS evidence: current public SPF, DKIM, and DMARC lookup results Vendor evidence: current SendGrid documentation URL or account status Receiver evidence: mailbox provider result for the same test message Decision: do not change sending volume until the missing evidence is identified ``` The example separates facts from conclusions: - The visible From domain tells you which domain should be evaluated for DMARC alignment. - Raw headers are message evidence. They can show what happened to the delivered test message, but they do not predict future delivery. - DNS results are public evidence. They do not prove that SendGrid used a particular configuration for the message. - A vendor document or account status can support a SendGrid-specific decision only when it applies to the account and sending path. - A receiver result concerns that receiver and message. It is not a universal deliverability verdict. Do not paste account-generated selectors, CNAME targets, API keys, tokens, or unredacted message headers into a ticket or public document. Keep those details within the team that administers the sending domain. ## What to check before changing sending volume Start with the evidence you actually have. If you have only the domain, run an [email security score check](/tools/email-security-score). Use the result to identify publicly visible email-authentication gaps that merit investigation. Then compare the result with the domain and sending path your team intended to use. If you have a SendGrid configuration question, consult the current SendGrid documentation linked from its support center. Look for guidance that explicitly applies to the account type, feature, and sending path in question. If the documentation does not state the requested rule, do not present that rule as SendGrid policy. If you have a message that reached a mailbox, review its raw headers and the authentication results for that same message. This is the point where a SendGrid configuration question can become an SPF, DKIM, or DMARC alignment question. If your team needs an ongoing view after mail begins flowing, collect DMARC aggregate-report data. Palisade can analyze aggregate reports, identify sending sources and authentication or alignment issues, create prioritized remediation tickets, and propose a next DMARC policy stage for human review. It does not change the DMARC policy or guarantee receiver delivery decisions. ## Check the domain posture before treating this as warm-up A copied ramp cannot show whether the sending domain publishes the expected authentication records. Inspect the domain first, then compare the result with the specific SendGrid path and delivered-message evidence. [Check your email security posture](/tools/email-security-score) A public security check cannot prove that SendGrid sent a particular message, monitor future sending behavior, repair a sender configuration, or guarantee inbox placement. For teams that need to track many sending sources after aggregate reports arrive, [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=email_deliverability&utm_content=sendgrid-email-warmup). Signup and trial do not require a credit card. Palisade helps investigate DMARC-report evidence and prioritize remediation, while a human reviews the evidence and applies any DNS or policy change. ## Sources and further reading - [Twilio SendGrid Email API](https://www.twilio.com/) - [SendGrid support center](https://support.sendgrid.com/) - [Palisade email security score](https://www.palisade.email/tools/email-security-score) - [Palisade guide to SPF and DKIM for SendGrid](/learning/how-do-i-set-up-spf-and-dkim-for-sendgrid) ## Frequently asked questions ### Does SendGrid warm up email automatically? SendGrid's public support center does not describe an automatic warm-up, so plan your own ramp rather than assuming one runs for you. That page points to product guides and API documentation instead. Check the documentation for your account type and sending path before you change volume. ### How long should SendGrid email warmup take? SendGrid does not publish a fixed warm-up duration, so treat any number you find in a blog post as unverified. Look for a stated duration in the current SendGrid documentation that names your account type and sending path. Until you find one, do not present a duration as SendGrid policy. ### Do I need to warm up a SendGrid shared IP? The answer depends on whether your account sends on a shared or a dedicated path, and SendGrid's support center landing page does not state a rule for either. Confirm which path your account actually uses, then check the current SendGrid documentation for that path. Do not apply dedicated-IP advice to a shared path or the reverse. ### Can a public DNS check prove SendGrid deliverability? No, because a public DNS check only shows the records resolvers could retrieve at the moment you ran it. It cannot show which production path sent a message, how a mailbox provider decided to handle it, or where a future message will land. ### Should I change sending volume before checking SPF, DKIM, and DMARC? No, because changing volume does not repair missing or misaligned authentication. Identify the visible From domain first, inspect its public SPF, DKIM, and DMARC records, then review a delivered test message where you can. Make volume decisions after that. --- # Smartlead email warmup Canonical: https://www.palisade.email/learning/smartlead-email-warmup > Smartlead email warmup simulates opens, reads, and replies, but it does not replace checking SPF, DKIM, DMARC, or real delivery results today. Smartlead email warmup is a feature Smartlead describes as part of its built-in sending setup. Smartlead says its warm-up engine simulates opens, reads, and replies through a private, reward-based, limited-access network. That description does not prove that a mailbox will reach the inbox, replace SPF, DKIM, or DMARC checks, or show how a specific Smartlead account is configured. ## Quick takeaways - Smartlead markets built-in setup warm-up alongside DNS and sender rotation. - Smartlead says its warm-up engine simulates opens, reads, and replies. - Smartlead describes the network as private, reward-based, and limited-access. - Warm-up activity is separate from proving that a sending domain has valid SPF, DKIM, and DMARC. - A public authentication check cannot validate Smartlead's mailbox settings or predict inbox placement. - Real delivered messages and ongoing delivery results remain the evidence for a production sending path. ## How Smartlead email warmup works [Smartlead's homepage](https://smartlead.ai) describes "Built-in setup warm-up" as part of its platform. It says that Smartlead handles "DNS, warm-ups and sender rotation automatically" and that its warm-up engine simulates "real opens, reads and replies." The public description establishes the feature's intended category: activity designed to make a mailbox behave more like an active sender. It does not document the current controls, the mailbox prerequisites, the number of warm-up messages, the ramp schedule, or how to turn the feature on or off. Treat those items as account-specific details to confirm in Smartlead's current product documentation or authenticated interface. Smartlead also says users can access a "private, reward-based, limited-access network." That identifies the kind of network Smartlead promotes, but it does not establish a measurable result for any one domain or mailbox. Warm-up is only one part of email deliverability. [Email deliverability](/email-deliverability) also depends on the receiving system's own filtering and local decisions. An open or reply simulated within a warm-up network does not prove how Google, Microsoft, or another receiver will handle a campaign message. ![Decision flow showing that Smartlead warm-up activity should be checked separately from domain authentication and real delivered-message evidence](/images/editorial/smartlead-email-warmup/smartlead-email-warmup-decision-flow.webp "1200x829") *Source: Palisade.* ## When warm-up does not answer the deliverability question The answer changes when the question is about a production message rather than warm-up activity. Use this decision rule: - If you need to know whether Smartlead offers warm-up, its public site says yes. - If you need to know whether a domain publishes SPF, DKIM, and DMARC, inspect the domain's public DNS records. - If you need to know whether a real message authenticated, inspect headers from a delivered message sent through the exact production path. - If you need to know whether recipients placed campaign mail in the inbox, spam folder, or another location, test and observe that recipient environment. Smartlead's public warm-up description does not provide that answer. - If you need to know whether all legitimate senders using a domain align for DMARC, use DMARC aggregate-report data after it accumulates. Smartlead groups warm-ups, SPF/DKIM/DMARC, and sending patterns in its deliverability positioning. It is reasonable to treat authentication as a separate check because the public description does not state that warm-up configures or proves those protocols. SPF authorizes sending infrastructure through DNS. DKIM adds a cryptographic signature to a message. DMARC evaluates whether SPF or DKIM passed with an identifier aligned to the visible From domain. These are distinct protocol checks. For a broader explanation of warm-up limits, see [AI email warmup: what it is and what it cannot prove](/learning/ai-email-warmup). > Do not increase sending volume based only on warm-up activity. First confirm that the production domain authenticates and that business-critical mail is sent through the intended mailbox and return path. ## A worked evidence example A Smartlead warm-up description and a production authentication result answer different questions. ```text Warm-up claim: Smartlead warm-up engine simulates "real opens, reads and replies." Production evidence to collect: Visible From: campaigns@yourdomain.com SPF result: pass or fail DKIM result: pass or fail DMARC result: pass or fail Authentication-Results: copied from a real delivered message ``` The first item shows what Smartlead publicly says the feature does. The remaining items show what to collect from a real message. [RFC 8601 defines the Authentication-Results header field](https://datatracker.ietf.org/doc/html/rfc8601), which can record an authentication service's evaluation of SPF, DKIM, DMARC, and related methods. A useful production check starts with a message that recipients actually received from the same Smartlead mailbox, sending domain, and campaign configuration you intend to use. Review its raw headers, then compare the visible From domain with the domains that SPF and DKIM authenticated. A passing result on one message is still narrow evidence. It does not prove every future message will authenticate, show every sending source using the domain, or guarantee inbox placement. It does provide more relevant evidence than a warm-up claim when the operational question is whether a particular production path authenticated. ## What to check after enabling warm-up Start with the evidence you already have. - If you only have the sending domain, inspect its public authentication posture. Confirm that SPF, DKIM, and DMARC are present and readable before treating warm-up as a deliverability signal. - If you have a delivered Smartlead message, inspect its raw headers. Compare the authentication results with the visible From domain and the actual sending path. - If you have DMARC reports, inventory the sources using the domain and identify authentication or alignment failures before changing DMARC policy. - If you are testing campaign delivery, use a controlled recipient test and document the sending mailbox, time, recipient environment, and observed placement. Do not generalize one test result to all recipients. For a vendor-specific perspective on the same boundary, [Apollo email warmup](/learning/apollo-email-warmup) explains why warm-up activity and recipient placement are separate questions. The [email deliverability hub](/email-deliverability) covers the wider operating work after a sending domain is configured. ## Check the sending domain's visible security posture Before relying on Smartlead email warmup as part of a sending plan, check the sending domain's public SPF, DKIM, and DMARC posture. That check helps identify visible gaps that warm-up activity does not answer. [Check the email security score](/tools/email-security-score) A public security check does not validate Smartlead warm-up settings, prove the production mailbox is using the expected configuration, monitor future changes, or guarantee inbox placement. For ongoing DMARC work, Palisade is agentic DMARC software that analyzes aggregate-report data, identifies authentication and alignment issues, and proposes the next policy step for human review. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=email_deliverability&utm_content=smartlead-email-warmup) ## Sources and further reading - [Smartlead homepage](https://smartlead.ai) - [RFC 8601: Message Header Field for Indicating Message Authentication Status](https://datatracker.ietf.org/doc/html/rfc8601) - [Palisade email security score](/tools/email-security-score) - [Email deliverability](/email-deliverability) ## Frequently asked questions ### Does Smartlead have email warmup? Yes. Smartlead's public homepage promotes built-in setup warm-up and says its warm-up engine simulates opens, reads, and replies. The public description does not document the current account setup steps, message volume, duration, or availability conditions. ### Does Smartlead email warmup guarantee inbox placement? No. Smartlead's public warm-up description does not publish a method or result that guarantees inbox placement. Receiving systems make their own filtering decisions based on factors that can include authentication, reputation, content, and local policy. ### Does warm-up replace SPF, DKIM, and DMARC? No. SPF, DKIM, and DMARC are email-authentication protocols with separate DNS and message-level evidence. Smartlead groups them with warm-ups in its deliverability positioning, but its public description does not state that warm-up proves or replaces authentication. ### What should I check after starting Smartlead warmup? Check the sending domain's public SPF, DKIM, and DMARC records, then inspect raw headers from a real message sent through the intended production path. If the domain uses DMARC, review aggregate reports after data accumulates to identify sources and alignment failures. ### Can a public email security check verify Smartlead's settings? No. A public check can inspect visible DNS-based email-authentication posture. It cannot access Smartlead account settings, confirm warm-up activity, prove the production sending path, or predict a receiver's final placement decision. --- # SMTP and POP3 difference: sending versus retrieving email Canonical: https://www.palisade.email/learning/smtp-and-pop3-difference > SMTP and POP3 difference: SMTP sends and relays email, while POP3 retrieves messages from a server to a client mailbox. SMTP and POP3 do different jobs. SMTP sends or relays a message into the mail transport system, while POP3 lets a mail client retrieve messages that a server holds in a mailbox. They are complementary protocols, not alternatives: a person can send through SMTP and later retrieve received mail through POP3. SMTP is defined by [RFC 5321](https://www.rfc-editor.org/rfc/rfc5321.txt); POP3 is defined by [RFC 1939](https://www.rfc-editor.org/rfc/rfc1939.txt). ## Quick takeaways - SMTP transfers email between a client, relay, and receiving mail server. - POP3 retrieves messages from a server maildrop to a mail client. - POP3 does not define how a client sends mail, and RFC 1939 delegates that job to SMTP. - SMTP is a Standards Track protocol under RFC 5321, published in October 2008. - POP3 is an Internet Standard, STD 53, under RFC 1939, published in May 1996. - Choosing POP3 does not replace SMTP. The separate retrieval choice is POP3 versus IMAP. ## Who is affected? This distinction affects anyone configuring an email client, documenting a mail flow, or investigating why a message was sent successfully but is unavailable in a mailbox application. SMTP applies when a client or server submits, relays, or delivers a message. POP3 applies when a client accesses messages already held for that user on a server. RFC 5321 states that SMTP's objective is "to transfer mail reliably and efficiently." It also says SMTP can transfer mail to another process on the same network or another network through a relay or gateway. That is transport behavior. RFC 1939 says POP3 is intended to let a workstation dynamically access a maildrop on a server host. Usually, the workstation retrieves mail that the server is holding. POP3 is deliberately narrower than a full server-side mailbox management protocol. RFC 1939 says mail is normally downloaded and then deleted, although a client can use `UIDL` and avoid `DELE` for a limited form of retaining messages on the server. A POP3 client may leave messages available for later download, but that does not change POP3 into a sending protocol. For the separate question of POP3 versus IMAP retrieval behavior, see [Difference between IMAP and SMTP](/learning/difference-between-imap-and-smtp). ## What are the requirements? ### SMTP carries messages into the transport system An SMTP client needs a message to transmit and establishes a two-way transmission channel to an SMTP server. SMTP may connect a sending client to a relay host, then relay the message onward toward its destination. ```text SMTP client -> SMTP server or relay -> receiving mail system ``` RFC 5321 calls SMTP a mail transport and delivery protocol, and also describes its role in mail submission. A mail client can therefore use SMTP when a person clicks Send, while mail servers use SMTP to relay the message between domains. SMTP does not define how a user browses messages already stored in a mailbox. That is outside the transport step. If a message is accepted by an SMTP server but fails to arrive or is rejected later in the route, use the evidence in the relevant [email delivery error guidance](/learning/delivery-errors) rather than assuming POP3 caused the problem. ### POP3 retrieves messages from a server maildrop A POP3 session begins after the server greeting. RFC 1939 defines an AUTHORIZATION state, a TRANSACTION state where the client requests actions from the server, and an UPDATE state after the client issues `QUIT`. ```text POP3 client -> POP3 server maildrop -> downloaded mailbox messages AUTHORIZATION -> TRANSACTION -> UPDATE ``` POP3 is for retrieval after mail is already present on the server. It does not relay a new message to another domain and does not replace the SMTP submission path. ![SMTP and POP3 protocol roles showing SMTP sending mail to a server and POP3 retrieving stored mail to a client](/images/editorial/smtp-and-pop3-difference/smtp-and-pop3-difference-protocol-roles.webp "1200x676") *Source: Palisade.* ### POP3 hands sending to SMTP RFC 1939 makes the boundary explicit: "This memo does not specify how a client host enters mail into the transport system". Its example method says that when a user agent wants to enter a message into the transport system, it establishes an SMTP connection to its relay host and sends mail to it. That design means POP3 and SMTP are not competing choices for one action. SMTP handles sending. POP3 handles retrieval. A mail application can support both because a user needs both directions of the mail workflow. IMAP also does not send mail. [RFC 9051](https://www.rfc-editor.org/rfc/rfc9051.txt), the current IMAP4rev2 specification that obsoletes RFC 3501, says IMAP4rev2 lets a client access and manipulate messages on a server but does not specify posting mail. It assigns posting to a mail submission protocol such as the one in RFC 6409. ### Provider settings are implementation-specific A provider's hostnames, ports, encryption requirements, and authentication settings are not universal SMTP or POP3 requirements. Use the provider's current documentation for those values. For example, [Gmail's POP and SMTP settings](https://support.google.com/mail/answer/7104828) document `pop.gmail.com` with SSL on port `995` for incoming POP access. The same page documents `smtp.gmail.com` for outgoing SMTP, with authentication required and port `587` for TLS/STARTTLS. Those settings show both protocols in one provider's service, each used for its own direction. > Do not copy Gmail's server names or ports into another provider's configuration. A wrong submission host, port, or TLS setting can prevent mail from being sent. Google separately states that Gmail will stop checking third-party accounts through its "Check mail from other accounts" POP feature for new users after the first quarter of 2026, with existing users supported until January 2027. That notice concerns Gmail fetching mail from another account. It does not say that POP access to Gmail at `pop.gmail.com` is ending. ## When does the requirement take effect? There is no new shared enforcement date for the SMTP and POP3 protocol roles. They are established Internet standards with different publication dates. RFC 5321, "Simple Mail Transfer Protocol," was published in October 2008 as a Standards Track RFC. It obsoletes RFC 821, RFC 974, RFC 1869, and RFC 2821, and updates RFC 1123. RFC 1939, "Post Office Protocol - Version 3," was published in May 1996 as Standards Track and is STD 53. It obsoletes RFC 1725. RFC 9051, "Internet Message Access Protocol (IMAP) - Version 4rev2," was published in August 2021 as Standards Track and obsoletes RFC 3501. Its role matters only when evaluating retrieval options. It does not alter SMTP's responsibility for mail submission. ## How do I implement the requirement? ### 1. Identify the direction of the task Use SMTP settings when configuring message submission or diagnosing a relay path. Use POP3 settings when configuring a client to retrieve messages held in a mailbox. Write down whether the observed problem is sending, receiving into the server mailbox, or downloading from that mailbox. Those are separate stages. ### 2. Obtain the provider's documented settings Use the current documentation for the specific email provider. Record the incoming POP host and security requirements separately from the outgoing SMTP host, authentication requirement, and submission port. Do not infer the SMTP configuration from the POP3 configuration, or vice versa. The protocols commonly use different endpoints because they do different work. ### 3. Configure transport security for the actual SMTP path SMTP transport protection is separate from the choice between SMTP and POP3. Confirm the provider's documented TLS or STARTTLS requirement, then compare it with the mail client and relay configuration. See [SSL vs TLS: what's the difference for email?](/learning/ssl-vs-tls-whats-the-difference) for the distinction between these security terms. ### 4. Keep retrieval decisions separate If the question is whether a mailbox should be downloaded through POP3 or synchronized through IMAP, do not treat SMTP as one of the competing retrieval options. SMTP remains necessary for sending. Evaluate POP3 and IMAP under their own retrieval requirements. ## How do I validate compliance? Validate each layer independently. - DNS: Inspect the domain's public DNS context, including MX records where relevant. The [DNS lookup tool](/tools/dns-lookup) can inspect published records, but it cannot identify whether a mail client uses POP3 or prove a provider accepted a message. - Vendor: Check the provider's current account or client configuration status against its documented SMTP and POP3 settings. - Message: Send a real test message through the exact production SMTP path. Inspect the delivered message headers and the provider's submission result. A configured outbound server is not proof that the message reached the recipient. - Retrieval: Confirm that the intended POP3 client can retrieve the test message from the intended mailbox. If the client deletes messages after retrieval, confirm that behavior before deploying the setting broadly. - DMARC: If the sending domain uses DMARC, review aggregate-report evidence after messages have accumulated. SMTP acceptance and POP3 retrieval do not prove DMARC alignment. A successful POP3 download proves access to that mailbox at that time. It does not prove future SMTP delivery, receiver inbox placement, or authentication results for every sender using the domain. For envelope identity within the SMTP layer, see [RFC 5321.MailFrom vs RFC 5322.From](/learning/rfc5321-mailfrom-vs-rfc5322-from). ## Check the security controls around the SMTP path SMTP and POP3 describe direction and mailbox access. They do not by themselves prove that the SMTP connection uses the provider's required encryption settings. Review the provider's current transport-security instructions and test a real message through the configured submission route. A public DNS inspection cannot prove the client negotiated TLS, repaired a mail-client setting, or guarantee how a receiver will handle a future message. ## Sources and further reading - [RFC 5321: Simple Mail Transfer Protocol](https://www.rfc-editor.org/rfc/rfc5321.txt) - [RFC 1939: Post Office Protocol - Version 3](https://www.rfc-editor.org/rfc/rfc1939.txt) - [RFC 9051: Internet Message Access Protocol (IMAP) - Version 4rev2](https://www.rfc-editor.org/rfc/rfc9051.txt) - [Gmail POP and SMTP settings](https://support.google.com/mail/answer/7104828) - [Google notice on checking third-party accounts through POP](https://support.google.com/mail/answer/16604719) ## Frequently asked questions ### Are POP3 and SMTP the same? No, they do opposite jobs. SMTP moves mail into and through the mail transport system, while POP3 fetches mail already sitting in a server maildrop. RFC 1939 does not define sending through POP3 at all, and describes using an SMTP connection to put mail into the transport system. ### Does anyone still use POP3? Yes, POP3 is still in service. It remains an Internet Standard, STD 53, and Gmail currently documents POP access through `pop.gmail.com` on port `995` with SSL. How widely it is used today is a separate question that neither source answers. ### Should I use POP IMAP or SMTP? The real choice is between POP3 and IMAP, because SMTP does a different job: it sends mail rather than retrieving it. You will end up using SMTP either way for outgoing messages. Pick between POP3 and IMAP based on how you want retrieval to behave and whether you need mail kept on the server. ### Does Gmail use SMTP or POP? Gmail uses both, for different directions of the same workflow. It documents SMTP for outgoing mail through `smtp.gmail.com`, and POP for incoming retrieval through `pop.gmail.com`. ### Does POP3 always delete mail from the server? No, deleting is the normal behavior rather than a fixed rule. RFC 1939 says mail is usually downloaded and then deleted, but a client can skip the `DELE` command and use `UIDL` to keep a limited copy on the server. Even then, POP3 lacks IMAP features such as server folders and polling an open connection for new mail. --- # SMTP header analyzer Canonical: https://www.palisade.email/learning/smtp-header-analyzer > SMTP header analyzer workflow: paste raw email headers, interpret delivery, SPF, DKIM, and DMARC evidence, then retest the right layer today. An SMTP header analyzer helps you turn a raw delivered message header into evidence about its delivery path, authentication results, and visible sender identities. Paste the complete header into Palisade's Email Header Analyzer, then separate what the header records from what still needs DNS, sender configuration, receiver, or DMARC-report evidence. A header can narrow an investigation. It cannot prove why a receiver delayed, rejected, or placed one message. ## Quick takeaways - Palisade's Email Header Analyzer parses pasted raw email headers in the browser. - The tool reads `Received`, `Authentication-Results`, SPF, DKIM, DMARC, From, Return-Path, Message-ID, Reply-To, Date, and X-Mailer fields. - Hop 1 in the delivery-path view is the origin server, represented by the bottom `Received:` header. - Authentication verdicts and From-to-Return-Path alignment are separate signals. - A negative hop delay can mean two mail servers have different clocks, not that mail travelled backward. - Header evidence must be trusted only within the infrastructure boundary that added it. ## What this tool checks The [Palisade Email Header Analyzer](/tools/email-header-analyzer) accepts raw pasted RFC 5322 email headers. Parsing happens in your browser, so the pasted header is not uploaded by the tool. The parser unfolds continuation lines, stops at the first blank line, and therefore ignores any message body after the header section. The analyzer reads the `Received` chain and extracts available sending and receiving servers, protocol, bracketed IP literal, timestamp, and time between hops. It also displays SPF, DKIM, and DMARC values found in `Authentication-Results`, along with identity fields such as From and Return-Path. [RFC 5322 defines `Received:` and `Return-Path:` as trace fields](https://www.rfc-editor.org/rfc/rfc5322.html), while [RFC 8601 defines the `Authentication-Results` header field](https://www.rfc-editor.org/rfc/rfc8601.html). Those standards explain the shape of the evidence. They do not make every header equally trustworthy. Use this tool with a complete raw header from the delivered message you are investigating. If you need help locating the fields first, read [what an email header contains](/learning/what-is-an-email-header). The analyzer cannot inspect the sending application, private DKIM key, mailbox-provider dashboard, mail logs, current DNS answer, or aggregate DMARC reports. It also cannot prove a production path remains unchanged after this one message. A parsed header is evidence from one message at one point in time. ![Interpretation map for SMTP header analysis](/images/editorial/smtp-header-analyzer/smtp-header-analyzer-result-map.webp "1200x829") *Source: Palisade.* ## How to run the check ### 1. Get the raw header from the delivered message Open the original delivered message in the recipient mailbox and use its option to view the original or raw message source. Copy the header block, including all `Received:` and `Authentication-Results:` lines. Do not paste customer content, attachments, credentials, private keys, or account tokens into an investigation ticket. Headers can contain recipient addresses, internal hostnames, IP addresses, and message identifiers. Redact information before sharing it outside the people authorized to investigate the message. ### 2. Paste only the header block Open the [Email Header Analyzer](/tools/email-header-analyzer) and paste the raw header into its text area. A complete paste begins with header fields such as `Received:`, `From:`, or `Delivered-To:`. If the input is empty or does not contain recognizable fields, the tool returns: ```text No email headers found. Paste the raw headers — they start with lines like “Received:”, “From:”, or “Delivered-To:”. ``` The blank line between headers and body is useful. The parser stops there, so you do not need to include the message content. ### 3. Preserve the message path for comparison Record the sending application, visible From address, recipient mailbox, and approximate send time separately. These facts let you compare the parsed header with the exact path you intended to test. For a current public DNS check after the header points to a hostname or routing question, query the relevant domain separately: ```bash dig +short MX yourdomain.com ``` This is a public DNS observation, not a test of the delivered message. Use [Palisade's DNS lookup](/tools/dns-lookup) when you need to inspect current public records alongside the historic header evidence. ## How to interpret the results ### Delivery path (Received chain) The tool's “Delivery path (Received chain)” section renumbers hops so that hop 1 is the origin server, which is the bottom `Received:` header. This follows the practical direction of message travel: each receiving system adds its trace field above the prior entries. RFC 5322 specifies that a `Received:` field contains tokens followed by a semicolon and date-time value. The analyzer uses the timestamp after the last semicolon when it is present. Treat each hop as a claim recorded by the server that received the message. A hop can show that a message passed through a named system, but it does not independently prove the identity or configuration of every system below a trust boundary. > Do not treat a long interval between two `Received:` timestamps as proof of a delivery fault. The tool cannot calculate a hop delay when either timestamp is absent, and a negative value means the servers' clocks disagree. If the analyzer reports that the delivery path cannot be reconstructed, the pasted header has no `Received:` fields. Return to the original-message view and copy the complete header before diagnosing routing. ### SPF, DKIM, and DMARC verdicts The analyzer displays verdict rows using the values `pass`, `fail`, `softfail`, `neutral`, `none`, `temperror`, `permerror`, `policy`, `bestguesspass`, `unknown`, or “not found”. For SPF and DKIM, [RFC 8601 defines result values including `pass`, `fail`, `neutral`, `temperror`, and `permerror`](https://www.rfc-editor.org/rfc/rfc8601.html). The authentication service that added the header is identified by the `authserv-id`, so read the result as that service's assessment, not as a universal verdict for every receiver. A `pass` means the reporting authentication service recorded a successful result for that method. A `fail`, `softfail`, `temperror`, or `permerror` needs message-path and sender-side follow-up. `temperror` points to a temporary evaluation problem, while `permerror` indicates a permanent evaluation problem according to the method result. “Not found” means the tool did not find that result in the pasted headers. It does not prove the method was never evaluated elsewhere. DMARC may appear in `Authentication-Results`, but RFC 8601 does not define a DMARC-specific result-value subsection. Keep the recorded DMARC result tied to the service that wrote it. ### From vs Return-Path alignment The “From vs Return-Path alignment” section compares the visible From domain with the Return-Path domain on its own scale: `exact`, `relaxed`, `misaligned`, or `unknown`. This comparison helps explain the SPF side of DMARC because the tool states that DMARC only counts an SPF pass when the Return-Path domain aligns with the visible From domain. It does not replace a full DMARC evaluation. A message can still authenticate through aligned DKIM, and a header view does not show every organizational-domain or policy decision a receiver used. For the distinction between the SMTP envelope sender and visible author address, use [RFC 5321.MailFrom versus RFC 5322.From](/learning/rfc5321-mailfrom-vs-rfc5322-from). ### Missing identity fields If the tool cannot find identity fields, it reports that none of From, Message-ID, or Reply-To were present. That is a signal to obtain the full original header, not a finding that a sending service is broken. RFC 5322 defines these fields separately, and different fields answer different questions about the message. ## How to act on the result Start with the narrowest evidence-backed action. - If the `Received` chain is missing, collect the complete original header again. Do not infer a routing failure from a partial export. - If a hop points to an unexpected system, compare it with the known sending application, gateway, and recipient path. Escalate to that system's mail logs or support record if you need to explain a delay. - If SPF, DKIM, or DMARC shows a failure, inspect the exact domains shown beside the verdict. Then compare sender configuration and a newly delivered message through the same production path. The [email authentication failure guide](/learning/email-authentication-failure) helps separate DNS, sender, message, and DMARC-report evidence. - If the header suggests a current routing or host-configuration question, inspect the relevant DNS record separately. A DNS result today does not change or prove what a historical message used. - If transport policy is the concern, distinguish header trace evidence from the TLS and policy controls described in [email transport security](/learning/infrastructure). Authentication headers have a trust boundary. RFC 8601 warns that the field often has no integrity mechanism of its own. Anchor your conclusion on the headers added by infrastructure you control or trust. Header lines below that boundary can be forged before the message enters it. ## How to retest Send a fresh test message through the same application, sender identity, gateway, recipient mailbox, and route that produced the original evidence. Paste its raw header into the Email Header Analyzer and compare it with the prior run. Expect only the corrected signal to change. For example, a sender-side authentication correction should change the relevant receiver-recorded authentication result in the new header. A DNS correction should also be checked against the authoritative DNS answer and a public resolver. When DMARC data accumulates, use aggregate reports to confirm whether the production sender population matches the single-message test. ## Check the DNS evidence behind an unexpected route If the header identifies a domain or MX-routing question, inspect its current public DNS records before escalating the routing path. Compare the lookup with the message's timestamp and `Received:` chain rather than treating either one as conclusive. A DNS lookup cannot prove which server handled a past message, explain one receiver's private delivery decision, or monitor later changes. For teams that need to move beyond isolated headers, Palisade is agentic DMARC software that analyzes aggregate-report data, identifies sending sources and authentication or alignment issues, and creates prioritized remediation tickets. It can propose the next DMARC policy step, while a human reviews the evidence and applies the change. It does not repair a single message's route or control a receiver's delivery decision. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=infrastructure_transport&utm_content=smtp-header-analyzer) ## Sources and further reading - [Palisade Email Header Analyzer](/tools/email-header-analyzer) - [RFC 5322: Internet Message Format](https://www.rfc-editor.org/rfc/rfc5322.html) - [RFC 8601: Message Header Field for Indicating Message Authentication Status](https://www.rfc-editor.org/rfc/rfc8601.html) - [Palisade DNS lookup](/tools/dns-lookup) ## Frequently asked questions ### Does an SMTP header analyzer show the full delivery path? An SMTP header analyzer shows the full path only when the header you paste still has all its `Received:` fields. The analyzer rebuilds the chain from those lines and treats the bottom one as the origin hop. Missing fields, missing timestamps, and untrusted upstream lines all cut into what the path can prove. ### Can a negative Received-hop delay mean mail travelled backward? No, a negative delay just means the two servers' clocks disagree. It is not evidence that the message travelled backward, and the interval it produces does not identify what caused a delay. ### Does an SPF pass mean DMARC passes? No, an SPF pass is not enough on its own, because DMARC needs an authenticated identifier that aligns with the visible From domain. The analyzer compares the Return-Path and From domains to show you the SPF alignment question. The full DMARC answer also depends on the receiver's own evaluation and the rest of the authentication evidence. ### Is Authentication-Results always trustworthy? No, you cannot trust every line of it. RFC 8601 explains that Authentication-Results usually carries no integrity mechanism of its own, so anyone upstream can add a line. Trust only the results added by infrastructure you control or already trust, and ignore lines that could have been inserted before the message crossed that boundary. ### Can a DNS lookup explain a historical email route? No, a DNS lookup only shows today's public answer. Compare it with the dated message header by all means, but never treat the current DNS state as proof of the route an older message actually took. --- # SPF check failure: how to interpret and fix the result Canonical: https://www.palisade.email/learning/spf-check-failure > SPF check failure: interpret Palisade SPF record results, repair duplicate or over-limit records, and retest the published DNS record after DNS changes. An SPF check failure can mean two different things: a public SPF record has a structural problem, or a receiving server evaluated one message and returned the SPF `fail` result. Start with the [Palisade SPF checker](/tools/spf) to inspect the published record, then use a delivered message and DMARC evidence to determine whether the production sending path also fails. ## Quick takeaways - Palisade's SPF checker evaluates the public SPF record, not a message sent from a particular IP address. - The checker uses `pass`, `warn`, and `fail` for record health, which are different from SPF evaluation results defined in RFC 7208. - More than 10 SPF DNS lookups makes an SPF record invalid during SPF evaluation. - Multiple `v=spf1` TXT records for one domain cause an SPF failure. - A passing SPF result does not prove SPF alignment for DMARC. - A public DNS check cannot prove continuous state, message signing, a receiver's private decision, or future inbox placement. ## What this tool checks The [Palisade SPF checker](/tools/spf) accepts a domain and inspects its public Authorized Senders List Record (SPF). It normalizes a domain or email-style input, retrieves the published record, reports its status, shows a DNS lookup count, and can expose the nested include structure and detected senders. SPF authorizes domains or IP addresses to send mail for an envelope sender domain. [RFC 7208 defines SPF and its receiver-side evaluation results](https://www.rfc-editor.org/rfc/rfc7208.html), including `pass`, `fail`, `softfail`, `temperror`, and `permerror`. Those results apply when a receiver evaluates a particular message. They are not the same as Palisade's record-health labels. The checker can inspect public DNS. It cannot see the IP address that sent a message, the envelope `MAIL FROM` value used in production, the receiving server's complete evaluation, or why one recipient rejected a message. Use the broader [SPF learning hub](/learning/spf) when you need the protocol context behind the record. ## How to run the check ### 1. Identify the domain you need to inspect Use the domain that appears in the sender configuration or the envelope sender from a delivered message. Do not submit a recipient domain or assume that the visible `From` domain is the SPF identity. If you have a failed message, preserve its bounce details and raw headers. A domain lookup is useful evidence, but it does not replace the receiver's message-specific result. ### 2. Run the public SPF lookup Open the Palisade SPF checker and enter the domain. The checker presents the SPF record, its status, the DNS-lookup count, and any warnings tied to the published record. You can independently retrieve the public TXT answer with this repeatable lookup: ```bash dig +short TXT yourdomain.com ``` If the returned SPF policy is split across more than one TXT record beginning with `v=spf1`, do not merge the values by hand. That is a configuration error that needs correction at the authoritative DNS provider. ![Palisade SPF checker product overview](/images/editorial/spf-check-failure/spf-check-failure-shot-1.png "1600x900") *Source: [Palisade SPF checker product overview](https://www.palisade.email/images/cms/69277859338dda97b4f2ad4d_image-19.png), checked 2026-08-13.* ### 3. Record the exact result before changing DNS Save the domain, returned SPF record, status, lookup count, and listed warning. If the tool expands the include tree, identify the include or redirect path that contributes lookups before changing a record. > Do not replace an SPF record with values copied from another account or tenant. Sending services generate account-specific authorization values, and an unrelated record can break legitimate mail. ## How to interpret the results ### SPF record is missing This headline means the checker did not find a usable SPF policy for the queried domain. Confirm that the domain is the actual envelope sender domain before publishing a record. A missing record in public DNS does not prove every message will receive RFC 7208 `none`, because the receiver evaluates the message and domain it actually receives. ### Multiple SPF records found Palisade reports this as a failure because an SPF evaluator encountering multiple records that begin with `v=spf1` returns `permerror`. RFC 7208 requires a domain to publish one SPF record for evaluation purposes. Consolidate the authorized mechanisms into one record, then remove the duplicate SPF-version TXT record. ### SPF record performs more than 10 DNS lookups The checker displays a `DNS lookups` meter. [RFC 7208 section 4.6.4 requires SPF implementations to limit relevant DNS-triggering terms to 10](https://www.rfc-editor.org/rfc/rfc7208.html#section-4.6.4). The `include`, `a`, `mx`, `ptr`, and `exists` mechanisms, plus the `redirect` modifier, consume that budget. `ip4`, `ip6`, and `all` do not. Palisade flags more than 10 lookups as invalid. Inspect the include tree and remove obsolete senders, consolidate services where the sending provider supports it, or replace broad nested includes with the provider's current approved mechanism. Do not delete an include until you know which production source uses it. ![SPF record interpretation matrix for common Palisade checker states](/images/editorial/spf-check-failure/spf-check-failure-result-map.webp "1200x829") *Source: Palisade.* ### SPF record lookup failed This result means an endpoint referenced by the SPF record could not be resolved as expected. Check the exact hostname in the tool's detail view, then verify that the referenced service still publishes the required SPF record. A failed nested lookup may be a DNS publishing issue or an obsolete sender reference. The public check does not identify which application last used that sender. ### SPF record uses a PTR mechanism or a self-referring loop Palisade identifies the `ptr` mechanism as deprecated and marks a self-referring loop as invalid. RFC 7208 limits DNS evaluation to prevent unreasonable lookup load, and a loop prevents a clean evaluation path. Remove the `ptr` mechanism or break the loop with the sender's current published authorization method. ### SPF record is too rigid Palisade can warn on a record ending in `-all` and recommend `~all`. That is Palisade's record-health recommendation, not an RFC 7208 requirement. RFC 7208 defines distinct semantics for `fail` and `softfail`; it does not require one ending for every domain. Before changing the qualifier, confirm every legitimate sender and consider the domain's DMARC policy and mail flow. ## How to act on the result Repair the smallest confirmed problem first. - For duplicate SPF records, inventory every current `v=spf1` TXT record and consolidate valid mechanisms into one record. - For an over-limit record, use the checker detail to locate nested includes, then remove only retired sources or adopt the sending provider's documented consolidation method. - For a failed nested lookup, verify the exact referenced hostname at the authoritative DNS provider and confirm whether the sender is still in use. - For a warning about the final `all` mechanism, treat it as a policy decision. Test the real production mail path before changing it. - For a message-specific failure, inspect the delivered message's envelope sender and receiver-added authentication result. [Email authentication requires separate DNS, vendor, message, and DMARC evidence](/learning). An SPF record may be valid while DMARC still fails. DMARC compares the visible `From` domain with an authenticated identifier. [RFC 9989 defines SPF alignment as alignment between the author domain and the SPF-authenticated envelope sender domain](https://www.rfc-editor.org/rfc/rfc9989.html#section-4.4.2). Use [DMARC alignment checks in a delivered message](/learning/check-dmarc-alignment) when the SPF record looks healthy but DMARC reports a failure. ## How to retest Repeat the same Palisade SPF check after the authoritative DNS change is published. Confirm that the returned record no longer has the duplicate, failed endpoint, loop, or excessive lookup path you changed. Then send a new message through the same application, sender identity, gateway, and recipient path. Check the receiver's authentication result for that new message. Once aggregate data accumulates, review DMARC reports or Palisade monitoring to identify other sources that use the domain. ## Track SPF issues beyond one public lookup A corrected public SPF record does not show which production sending sources later fail authentication or alignment. Palisade is agentic DMARC software that analyzes DMARC aggregate-report data, identifies sources and alignment issues, and creates prioritized remediation tickets. It proposes the next policy step, while a human reviews the evidence and applies any change. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=email_authentication&utm_content=spf-check-failure) Palisade does not replace a message-specific SPF evaluation, change your DMARC policy automatically, or guarantee delivery or inbox placement. ## Sources and further reading - [RFC 7208: Sender Policy Framework](https://www.rfc-editor.org/rfc/rfc7208.html) - [RFC 7208 section 4.6.4: DNS lookup limits](https://www.rfc-editor.org/rfc/rfc7208.html#section-4.6.4) - [RFC 9989: DMARC](https://www.rfc-editor.org/rfc/rfc9989.html) - [Palisade SPF checker](/tools/spf) - [Palisade SPF learning hub](/learning/spf) ## Frequently asked questions ### What does SPF check failed mean? An SPF check failure can mean the published record has a structural issue, such as multiple SPF records or more than 10 DNS lookups. It can also mean a receiver evaluated one message and returned the RFC 7208 `fail` result. Check which kind of result you have before changing DNS. ### How to fix SPF failure? Fix the exact problem the check reports, and only that one. Consolidate duplicate `v=spf1` records, shorten a lookup path that runs over the limit, repair an included hostname that fails to resolve, or remove a loop. Then retest the same domain and send a fresh message through the same production path. ### How to fix 550 SPF check failed? Start with the complete bounce message, because the text after the `550` code is what tells you which check the receiver ran and why it refused. Keep the full error and the message headers, work out which provider the recipient uses, and follow that provider's documented SMTP guidance. Changing your public SPF record alone will not necessarily clear it. ### Why does SPF alignment fail? SPF alignment fails when the domain authenticated by SPF for the envelope `MAIL FROM` identity does not align with the visible `From` header domain under the domain's DMARC alignment mode. SPF can pass for its own envelope sender while the SPF branch of DMARC fails. ### Does a passing SPF checker result prove email delivery? No, a passing check only means your published record cleared the checker's record-level assessment. It does not show that your application actually sent through that record, that a receiver scored a specific message as SPF `pass`, or that the message reached an inbox. --- # SPF record format: version, mechanisms, and qualifiers Canonical: https://www.palisade.email/learning/spf-record-syntax-explained-mechanisms-qualifiers > SPF record format starts with v=spf1 in one DNS TXT record. Learn how mechanisms, qualifiers, modifiers, and the final all term are evaluated. SPF record format is one DNS TXT policy that starts with `v=spf1`, continues with space-separated mechanisms and modifiers, and normally ends with an `all` mechanism. A qualifier immediately before a mechanism sets the result when that mechanism matches. [RFC 7208](https://www.rfc-editor.org/rfc/rfc7208.html) requires receivers to evaluate the terms in order against the SMTP MAIL FROM or HELO identity, not the visible From address. ## Quick takeaways - An SPF record begins with the version token `v=spf1`. - Mechanisms are evaluated left to right until one produces a match. - A missing qualifier means `+`, which produces an SPF Pass when the mechanism matches. - `include` evaluates another domain's SPF policy as part of the current record, while `redirect` delegates evaluation only when no mechanism matched. - SPF evaluation has a limit of ten DNS-querying terms, including relevant `include` and `redirect` terms. - SPF authorizes the SMTP MAIL FROM or HELO identity, which can differ from the address a recipient sees in the From header. ## Who is affected? This syntax applies to domain owners who publish SPF records and to receivers that evaluate SMTP senders under [RFC 7208](https://www.rfc-editor.org/rfc/rfc7208.html), an IETF Standards Track RFC published in April 2014 that obsoletes RFC 4408. It matters whenever a domain appears in the SMTP `MAIL FROM` command or in the sending server's `HELO` or `EHLO` command. The relevant record is published at the exact SPF identity being evaluated. For most outbound mail, that is the domain in the SMTP MAIL FROM address. A receiver can also evaluate the HELO identity. RFC 7208 recommends checking HELO separately and requires a receiver to check MAIL FROM when the HELO check was not performed or did not reach a definitive policy result. SPF does not authenticate the visible From address directly. That distinction matters for [DMARC alignment](https://www.rfc-editor.org/rfc/rfc9989.html), which compares authenticated identifiers with the visible From domain. ## What are the requirements? ### The record starts with an SPF version and uses one TXT record RFC 7208 defines SPF version 1 records as DNS TXT records beginning with `v=spf1`. The rest of the record contains terms separated by spaces. A domain must not publish multiple SPF records that claim to be SPF version 1 records. A receiver that finds multiple records returns Permerror. ```text v=spf1 ip4:192.0.2.0/24 include:spf.sender.example ~all ``` This is illustrative only. Replace the example IP range and included domain with values generated or documented for your own authorized senders. Do not copy another organization's SPF record. ![SPF record anatomy showing the version token, mechanisms, qualifier, include term, and all mechanism](/images/editorial/spf-record-syntax-explained-mechanisms-qualifiers/spf-record-syntax-explained-mechanisms-qualifiers-record-anatomy.webp "1200x600") *Source: Palisade.* This article focuses on the grammar and evaluation behavior of the record itself. ### Mechanisms test the connecting sender An SPF mechanism tests the SMTP client IP address or evaluates another SPF policy. RFC 7208 defines these mechanisms: - `all` matches every sender. It normally appears at the end because terms after `all` cannot be reached. - [`include:<domain>`](/learning/glossary/spf-include) evaluates the named domain's SPF record. - `a` tests addresses returned for a domain's A or AAAA records. - `mx` tests addresses associated with a domain's MX hosts. See [what the SPF MX mechanism does](/learning/glossary/spf-mx-mechanism) for its narrower behavior. - `ip4:<address-or-network>` and `ip6:<address-or-network>` test a literal IPv4 or IPv6 address range. - `exists:<domain-spec>` performs a DNS lookup whose result determines whether the mechanism matches. - `ptr` uses reverse-DNS processing. RFC 7208 says it is not recommended and publishers should not use it. Mechanisms are evaluated in order. The first mechanism that matches determines the result through its qualifier. This makes order operationally significant: a broad `ip4` range placed before a narrow exception can match first. ### Qualifiers set the result of a match A qualifier is one character immediately before a mechanism. If no qualifier appears, the default is `+`. ```text +ip4:192.0.2.10 -ip4:198.51.100.10 ~all ?all ``` This is illustrative only. These addresses are documentation ranges, not sending infrastructure. RFC 7208 defines four qualifiers: - `+` produces Pass when the mechanism matches. - `-` produces Fail when the mechanism matches. - `~` produces Softfail when the mechanism matches. - `?` produces Neutral when the mechanism matches. The qualifier changes the SPF evaluation result. It does not independently instruct every receiver to reject, accept, or place a message in the inbox. RFC 7208 leaves handling of SPF results to receiver policy. The `all` mechanism is often used as the final term because it always matches. [The SPF `all` mechanism guide](/learning/spf-all-mechanism) explains why `-all`, `~all`, and `?all` communicate different policy results. ### Include and redirect have different jobs `include:<domain>` is a mechanism inside the current record. The included domain is evaluated using the original SMTP client IP address. If that evaluation returns Pass, the `include` mechanism matches and its qualifier controls the result. If the included policy returns Fail, Softfail, or Neutral, `include` does not match and evaluation continues. Temperror and Permerror are returned as errors. `redirect=<domain>` is a modifier, not a mechanism. It is used only when no mechanism matched. It delegates the final evaluation to the named domain's SPF record. A record cannot contain more than one `redirect` modifier, and a `redirect` is ignored when a mechanism already matched. ```text v=spf1 include:spf.sender.example ~all v=spf1 ip4:192.0.2.10 redirect=spf.policy.example ``` These examples are illustrative only. An `include` lets the current record continue evaluating after a non-Pass result from the included policy. A `redirect` hands off only after the current record has no match. Do not replace one with the other without tracing the expected result for each authorized sender. The `exp` modifier is also defined by RFC 7208. It supplies an explanation string for an SPF Fail result. It does not authorize a sender and it does not change the result. ## How a receiver evaluates the format Consider this illustrative record: ```text v=spf1 ip4:192.0.2.0/24 include:spf.sender.example ~all ``` The receiver first recognizes `v=spf1` as the version. It then tests whether the connecting IP falls within `192.0.2.0/24`. If that does not match, it evaluates the included policy. If neither authorization matches, the final `~all` produces SPF SoftFail. Evaluation stops as soon as a mechanism matches. The address range and included domain are examples, not production values. Use the mechanism supplied for each approved sender. If you find two complete SPF policies at one owner name, follow the [multiple SPF records repair guide](/learning/how-many-spf-records-per-domain) instead of treating them as one long record. ### DNS-querying terms have a ten-term limit RFC 7208 requires SPF evaluators to limit processing to ten DNS-querying terms during an SPF check. The applicable mechanisms are `include`, `a`, `mx`, `ptr`, and `exists`, plus the `redirect` modifier. Each time one of these terms causes DNS queries, it counts toward the evaluation budget. Literal `ip4`, `ip6`, and `all` terms do not perform DNS lookups. However, an apparently short record can still exceed the limit when an `include` expands into more DNS-querying terms. > Treat the ten-query limit as an evaluation limit, not a count of visible `include` tokens. Adding a sender's include can break SPF for every source that reaches that part of the record. ![SPF evaluation flow showing ordered mechanisms, include expansion, redirect fallback, and the ten-query limit](/images/editorial/spf-record-syntax-explained-mechanisms-qualifiers/spf-record-syntax-explained-mechanisms-qualifiers-evaluation-flow.webp "1200x676") *Source: Palisade.* ## When this does not apply Do not merge SPF examples into the visible From domain merely because a service sends messages that display that domain. SPF evaluates the SMTP MAIL FROM or HELO identity. If the service uses its own envelope domain, the SPF policy at your visible From domain may not participate in that message's SPF result at all. Keep policies separate when approved senders use different envelope subdomains. A policy for `bounce.example.com` belongs at that identity; it does not have to be folded into the record at `example.com`. Confirm the actual domain shown as `smtp.mailfrom` or `smtp.helo` before deciding which DNS owner needs a record. An SPF sample cannot replace sender inventory or delivered-message validation. It does not tell you whether a platform signs with aligned DKIM, whether DMARC passes, or whether a receiver will accept the message. If the proposed include would take an evaluation path over ten DNS-querying terms, adding it to the combined record is not a safe repair. Trace the path and choose a supported authorization design before publishing. ## How do I implement the requirement? ### 1. Identify the SMTP identities your sources use Inventory each legitimate sending service and determine its actual MAIL FROM domain and HELO identity. Do not infer the SPF identity from the visible From address. If an ESP sends with a provider-owned MAIL FROM domain, its SPF result may apply to that provider domain rather than yours. Check the service's documented sending-domain configuration before adding an SPF term. ### 2. Publish one `v=spf1` TXT record at the right domain Publish one SPF version 1 TXT record at each domain that needs a policy. Confirm the record exists at the precise MAIL FROM or HELO domain used by the sender. Keep the record as one logical SPF policy even if DNS tooling displays long TXT data in multiple quoted strings. Multiple strings within one TXT record are permitted. Multiple SPF version 1 records are not. ### 3. Put specific authorization before the final policy Place literal IP ranges and service-provided include terms before `all`. Use only mechanisms that match a known sending path. Start with terms that authorize real sources. Then select the final `all` qualifier that reflects the policy you can support. `-all` makes a definitive authorization statement, which suits a domain that sends no mail; a domain that does send should end in `~all`. [SPF hard fail versus softfail](/learning/spf-hardfail-vs-softfail) covers that choice. ### 4. Trace include and redirect paths Follow every include path and count DNS-querying terms across the possible evaluation path. Check the service's current documentation before changing an include value. Use `redirect` only when the intent is to use another domain's SPF policy as the fallback after no local mechanism matches. It is not a general replacement for an include. ### 5. Recheck changes before publishing a restrictive policy Compare the proposed record with the sending sources that use the domain. Send test messages through each production path after DNS propagation. A DNS syntax check is useful, but it cannot reveal a sender that was omitted from the inventory or prove how a specific receiver will apply its local policy. ## How do I validate compliance? First, inspect authoritative DNS and at least one public resolver for one SPF TXT record that begins with `v=spf1`. Confirm that it is published at the exact SMTP identity, not only at the organizational domain. Next, trace every applicable evaluation path and count DNS-querying terms. The [Palisade SPF checker](/tools/spf) can inspect a published SPF record and help identify syntax and lookup-budget issues. A public lookup cannot prove the production sending path, continuous DNS state, a receiver's private decision, or future message placement. Then send a real message from each authorized production source and inspect its delivered headers. RFC 8601 defines how a receiver can record SPF results in `Authentication-Results`, including `smtp.mailfrom` and `smtp.helo` properties. Confirm that the property identifies the expected SMTP domain and that the evaluated result matches the intended sender. Finally, review DMARC aggregate reports after data accumulates. SPF Pass alone does not establish DMARC alignment. Aggregate-report evidence can show whether the SPF-authenticated domain aligns with the visible From domain for real traffic. ## Check the SPF record before you change its policy Use the [SPF checker](/tools/spf) to inspect the record published for the domain that appears in the SMTP MAIL FROM or HELO identity. Compare its syntax and lookup path with a delivered message's `Authentication-Results` header before adding an include or changing the final `all` policy. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=email_authentication&utm_content=spf-record-syntax-explained-mechanisms-qualifiers) For an IT team or MSP, [Palisade's DMARC Agent](https://docs.palisade.email/) investigates sources observed in aggregate DMARC reports, drafts SPF fixes, and proposes each policy step. You approve before anything ships. When you approve a DNS change, [Smart DNS Deployment](/features/dns-deployment) writes the record into your own zone at your own provider. The agent does not discover every sender, prove every future message will authenticate, or guarantee a receiver delivery decision. ## Sources and further reading - [RFC 7208: Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1](https://www.rfc-editor.org/rfc/rfc7208.html) - [RFC 8601: Message Header Field for Indicating Message Authentication Status](https://www.rfc-editor.org/rfc/rfc8601.html) - [RFC 9989: Domain-based Message Authentication, Reporting, and Conformance](https://www.rfc-editor.org/rfc/rfc9989.html) ## Frequently asked questions ### What is the correct first term in an SPF record? Only `v=spf1` is the correct first term. It identifies the TXT value as an SPF version 1 record under RFC 7208. ### Does SPF check the visible From address? No. SPF evaluates the SMTP MAIL FROM identity or the SMTP HELO identity. The visible From address is relevant to DMARC alignment, not the SPF identity by itself. ### What does `-all` mean in an SPF record? No sender that reaches the final `-all` mechanism is authorized; it returns an SPF Fail result. It is appropriate on a domain that sends no mail. On a domain that does send, `~all` is the ending to publish, because an enforcing DMARC policy already treats both results as a non-pass while hard fail additionally risks losing forwarded mail. ### Is `include` the same as `redirect` in SPF? No. `include` is a mechanism that matches only when the included policy returns Pass. `redirect` is a modifier that delegates evaluation only if no mechanism in the current record matched. ### How many DNS lookups can an SPF record use? Only ten DNS-querying terms may be used during an SPF evaluation under RFC 7208. The limit includes applicable `include`, `a`, `mx`, `ptr`, `exists`, and `redirect` terms across the evaluation path. ### Does a passing SPF result guarantee delivery? No. SPF Pass means the evaluated SMTP client was authorized for the checked SPF identity. Each receiver applies its own delivery policy and can consider other authentication, reputation, and message signals. --- # The goals of email spoofing include luring the user into Canonical: https://www.palisade.email/learning/the-goals-of-email-spoofing-include-luring-the-user-into > The goals of email spoofing include luring users into sharing credentials, financial details, or visiting malicious sites through a trusted-looking. The goals of email spoofing include luring the user into sharing sensitive information, visiting a malicious site, or taking an action that benefits an attacker. Spoofing makes a message appear to use a trusted sender's domain. [RFC 9989 describes spoofed messages impersonating a business domain to entice recipients into providing usernames, passwords, and financial account information](https://www.rfc-editor.org/rfc/rfc9989#section-2.2). ## Quick takeaways - Email spoofing is unauthorized use of an email's visible author domain to make a message appear trustworthy. - Spoofed messages commonly support phishing attempts for credentials or financial information. - Phishing can also lure a recipient to a malicious website or deliver malware. - A familiar display name or From address is not proof that a message came from that person or organization. - DMARC helps combat specific forms of exact-domain spoofing, but it does not stop lookalike domains or display-name abuse. - A suspicious message needs message-header and reporting evidence, not a visual check of the sender name alone. ## How email spoofing supports a phishing goal The visible `From:` field identifies the message author under the [Internet Message Format standard](https://www.rfc-editor.org/rfc/rfc5322#section-3.6.2). On its own, that field is not an authenticated identity. [RFC 5321 explains that SMTP messages can be created to trick a recipient into believing they came from somewhere else](https://www.rfc-editor.org/rfc/rfc5321#section-7.1). That gap gives the attacker an opening. They can make a payment request, account alert, or password-reset message look like it came from a known business. RFC 9989 calls the unauthorized use of the Author Domain "spoofing" and says these messages are commonly called phishing when they try to entice recipients to disclose sensitive information. [US government phishing guidance](https://www.cisa.gov/sites/default/files/2023-10/Phishing%20Guidance%20-%20Stopping%20the%20Attack%20Cycle%20at%20Phase%20One_508c.pdf) identifies two documented goals: - Obtaining login credentials for initial network access. - Deploying malware for later activity, including disrupting systems, escalating privileges, or maintaining access. Spoofing and phishing are related, but they are not interchangeable terms. Spoofing is the impersonation technique. Phishing is the social-engineering message or campaign that uses trust to induce a harmful action. For a broader explanation of the technique, see [what email spoofing is and how it can be prevented](/learning/what-is-email-spoofing-and-how-can-you-prevent-it). ## When the answer changes A message does not need to spoof an exact domain to be harmful. An attacker may use a visually similar domain, a misleading display name, or a compromised legitimate account. The useful decision rule is: - If the visible From domain exactly matches the domain being impersonated, DMARC can help receivers identify and handle messages that fail the required authentication and alignment checks. - If the domain only looks similar, such as a spelling variation, DMARC for the real domain does not directly solve that impersonation attempt. - If the display name is misleading but the actual email address uses another domain, inspect the full address and the message headers rather than relying on the display name. [RFC 9989 explicitly limits DMARC to specific forms of exact-domain spoofing](https://www.rfc-editor.org/rfc/rfc9989#section-2.2). It does not address visually similar domains or abuse of the human-readable display name. That boundary matters when deciding whether a suspicious message is an authentication problem, a domain-registration problem, or a user-reporting incident. ![Decision flow showing how to distinguish exact-domain spoofing from lookalike-domain and display-name impersonation](/images/editorial/the-goals-of-email-spoofing-include-luring-the-user-into/the-goals-of-email-spoofing-include-luring-the-user-into-decision-flow.webp "1200x676") *Source: Palisade.* ## Worked example: a trusted-looking payment request The FBI has documented a business email compromise pattern in which a company receives an invoice-payment request directing funds to an alternate fraudulent account. In that scenario, [the email request is spoofed to appear similar to a legitimate request from a known supplier](https://www.ic3.gov/PSA/2017/PSA170504). A recipient may see a familiar name, subject line, or visible address and assume the request is valid. The request's goal is not merely to impersonate the supplier. It is to persuade the recipient to send money to the attacker's account. The following is an illustrative header shape, not a header from a real incident: ```text From: Accounts Payable <billing@yourcompany.com> To: finance@recipient.example Subject: Updated bank details for invoice 1042 Authentication-Results: mx.recipient.example; dmarc=fail header.from=yourcompany.com ``` [Authentication-Results fields are standardized by RFC 8601](https://www.rfc-editor.org/rfc/rfc8601). In this example, the visible From domain is `yourcompany.com`, while the receiving system records a DMARC failure for that domain. That result is evidence worth investigating, but it does not by itself identify the attacker, prove the message was malicious, or explain every receiver's handling decision. A payment request that changes bank details should be verified through a previously known contact method. Do not use the phone number, reply address, or link in the suspicious message as the verification channel. ## What to check after receiving a suspicious message Start with the evidence available to you. - If you only have the visible sender and domain, compare the full address with the legitimate organization's known address. Look for lookalike domains and unexpected subdomains. - If you have the original message, preserve it and inspect its full headers. The visible From field alone cannot establish origin. - If you administer the impersonated domain, review whether its sending services authenticate with aligned SPF or DKIM and whether its DMARC policy is appropriate. The [Palisade Email Security Score tool](/tools/email-security-score) can be a starting point for a public domain check, but a public check cannot prove the path used by a specific delivered message. - If the message requests a payment, credentials, or a login action, report it through your organization's incident process and use a trusted channel to verify the request. CISA guidance recommends SPF, DKIM, and DMARC to help prevent spoofing and validate email. It specifically recommends `p=reject` for sent email as protection against others impersonating a domain, while the receiving system still makes the final handling decision. [CISA's Binding Operational Directive 18-01 applies this requirement to US federal executive-branch agencies](https://www.cisa.gov/news-events/directives/bod-18-01-enhance-email-and-web-security), not to every private organization. For organizations working through wider threat controls, the [email security guide](/learning) and the [email threats learning hub](/learning/threats) provide the next context. ## Review the controls behind the spoofing risk If your domain could be impersonated, review its authentication posture and compare public DNS results with real message headers and DMARC reporting. [Read the email security guide](/learning) An article or public-domain check cannot determine whether one suspicious message was fraudulent, repair an affected mailbox, or stop attacks using lookalike domains. ## Sources and further reading - [RFC 9989: Domain-based Message Authentication, Reporting, and Conformance](https://www.rfc-editor.org/rfc/rfc9989) - [RFC 5321: Simple Mail Transfer Protocol, mail security and spoofing](https://www.rfc-editor.org/rfc/rfc5321#section-7.1) - [CISA, NSA, FBI, and MS-ISAC phishing guidance](https://www.cisa.gov/sites/default/files/2023-10/Phishing%20Guidance%20-%20Stopping%20the%20Attack%20Cycle%20at%20Phase%20One_508c.pdf) - [FBI IC3 business email compromise public service announcement](https://www.ic3.gov/PSA/2017/PSA170504) ## Frequently asked questions ### What is the goal of email spoofing, including luring the user into? The goal can be to lure the user into providing sensitive information, such as usernames, passwords, or financial account information. [RFC 9989 describes this use of impersonated business domains](https://www.rfc-editor.org/rfc/rfc9989#section-2.2). Government phishing guidance also identifies credential theft and malware deployment as documented goals. ### What type of email typically lures users to sites or asks for sensitive information? Phishing email typically lures users to malicious sites or deceives them into providing login credentials. [CISA, NSA, FBI, and MS-ISAC define phishing as a form of social engineering](https://www.cisa.gov/sites/default/files/2023-10/Phishing%20Guidance%20-%20Stopping%20the%20Attack%20Cycle%20at%20Phase%20One_508c.pdf) that commonly uses email for that purpose. ### Is sending emails to lure people into revealing personal information a technique known as phishing? Yes. Phishing is social engineering that lures victims into visiting a malicious site or disclosing credentials. Spoofing may support phishing by making the message appear to come from a trusted domain, but spoofing is the impersonation technique rather than the full social-engineering objective. ### What is an example of a spoofing email? An example is an invoice-payment request that appears similar to a legitimate supplier request but directs funds to an alternate fraudulent account. [The FBI has documented this as a business email compromise scenario](https://www.ic3.gov/PSA/2017/PSA170504). Verify changed payment instructions using an independently known contact method. ### Does DMARC stop every spoofed email? No. DMARC can combat specific forms of exact-domain spoofing when messages fail its authentication and alignment checks. [RFC 9989 states that DMARC does not address visually similar domains or display-name abuse](https://www.rfc-editor.org/rfc/rfc9989#section-2.2). --- # ThreatDown browser phishing protection Canonical: https://www.palisade.email/learning/threatdown-browser-phishing-protection > ThreatDown browser phishing protection is listed in its pre-delivery layer. See how it differs from email security and DNS filtering for domain owners. ThreatDown browser phishing protection is listed as "Browser Protection" within ThreatDown's pre-delivery protection layer. ThreatDown separately lists Email Security and DNS Filtering in its prevention layer. That distinction matters: the public platform page supports treating browser protection as one part of a layered defense, but it does not establish a specific phishing-page detection method, browser requirement, configuration path, or blocking action. ## Quick takeaways - [ThreatDown lists Browser Protection](https://threatdown.com) in its pre-delivery protection layer. - ThreatDown lists Email Security and DNS Filtering separately in its prevention layer. - Browser-related protection and email-security controls address different points in a phishing event. - A product-layer label does not prove how a particular phishing URL, browser session, or endpoint will be handled. - Confirming an email domain's public security posture requires separate evidence from the browser or endpoint. - For broader context on attacks that impersonate people and brands, visit the [Palisade threats hub](/learning/threats). ## How ThreatDown places browser protection in its security model [ThreatDown's platform page](https://threatdown.com) describes a platform that includes endpoint detection and response, identity threat detection and response, vulnerability and patch management, and email security. It says these capabilities are backed by 24/7 MDR in a single lightweight agent and managed from a single console. The same page organizes protection into named layers. Its prevention layer includes the following published items: - Email Security - DNS Filtering - Vulnerability Assessment - Application Block - Patch Management - Firewall Management ThreatDown's pre-delivery layer separately includes: - Web Protection - Application Behavior - Browser Protection - Exploit Mitigation - Protocol Hardening - Device Protection - Application Hardening This placement supports a narrow but useful interpretation. ThreatDown treats Browser Protection as distinct from its listed Email Security and DNS Filtering controls. It should therefore be assessed as a separate layer, rather than assumed to be another name for email filtering or DNS-based filtering. That is relevant to phishing because a phishing attempt can cross several stages. A message might reach an inbox, persuade a recipient to open a link, and then lead to a web destination. Controls that act at email delivery, DNS resolution, browser use, and endpoint execution can have different evidence, owners, and limits. For a broader explanation of phishing itself, see [anti-phishing software for business](/learning/anti-phishing-software). ![Decision flow separating ThreatDown's stated email-security, DNS-filtering, and browser-protection layers](/images/editorial/threatdown-browser-phishing-protection/threatdown-browser-phishing-protection-layer-decision.webp "1200x829") *Source: Palisade.* ## When the answer changes The answer changes when the question is about a specific action rather than ThreatDown's published product model. Use this decision rule: - If the question is whether ThreatDown publicly places Browser Protection in a browser-related pre-delivery layer, the answer is yes, based on [ThreatDown's platform page](https://threatdown.com). - If the question is whether ThreatDown Browser Protection blocks, warns on, detects, or remediates a particular phishing page, the public platform page alone does not answer it. - If the question is whether an email was filtered before delivery, look for evidence from the email-security layer, such as the relevant mail system's message logs, policy result, or delivered-message headers. - If the question is whether DNS filtering affected access to a destination, use DNS-filtering evidence from the applicable product and the actual endpoint path. - If the question is whether a user could open a specific URL in a browser, use product documentation or evidence from the affected environment. A general product-layer description is not proof of that event. This distinction prevents a common scope error. A security product can list several controls in one platform without every control examining the same signal or making the same decision. The platform page does not document which browsers or operating systems Browser Protection supports, how it makes a decision, or what action follows a detection. Do not treat a public web check as proof of endpoint behavior. A [URL reputation](/tools/url-reputation) result can help assess a URL at one point in time, but it does not prove that a particular endpoint policy inspected it, that a browser was protected, or that a user could not reach it. ## Worked example: separating the evidence by layer Consider an employee who receives a message that asks them to sign in to a web service. The message contains a link to `https://signin.yourdomain.com.example`. The following evidence object keeps the questions separate: ```text Event: A recipient received a message containing a sign-in link. Email-layer evidence: - Delivered message headers - Mail gateway or email-security policy result - Authentication results for the message DNS-layer evidence: - Resolver or DNS-filtering event for the destination - The endpoint and time of the lookup Browser or endpoint-layer evidence: - Product documentation for the applicable control - A policy result, alert, or event from the affected environment Conclusion: A result at one layer does not prove the result at another layer. ``` The message headers can show whether a delivered message authenticated and which systems handled it. [RFC 8601 defines the `Authentication-Results` header field](https://datatracker.ietf.org/doc/html/rfc8601), which reports authentication assessments made by a receiving system. Those results are evidence about message authentication, not evidence that a browser control later permitted or blocked a web page. Likewise, an email-security decision can show what happened while the message was processed, but it does not describe an endpoint's browser-related protection. A browser or endpoint event needs evidence from that environment. The separate labels on ThreatDown's platform page are the reason to avoid combining those conclusions. ## Practical next step: inspect the layer you can observe Start with the evidence you have. If you have a suspicious email, preserve the delivered message and inspect its full headers. Compare the visible From domain, return path, links, and `Authentication-Results` fields. If the message used your organization's domain, review the sending path and authentication evidence before drawing conclusions about a browser control. If your task is to assess the domain's public email-security posture, use Palisade's [Email Security Score tool](/tools/email-security-score). It can support a public DNS and domain posture review. It is not a ThreatDown diagnostic, does not inspect a ThreatDown policy, and cannot prove what happened in an employee's browser session. If you are evaluating a phishing defense program, keep a record of the layer, observed event, timestamp, affected endpoint, and evidence source. This makes it possible to distinguish a mail-delivery issue from a DNS-resolution issue or a browser and endpoint issue. For email-focused controls and terminology, see [Palisade's email security guide](/learning). > Do not disable an email, DNS, or endpoint protection policy based only on a general product description. Confirm the affected control and its event evidence first. ## Review email-security exposure separately ThreatDown's public page places Email Security, DNS Filtering, and Browser Protection in different named layers. If the open question is whether your domains have a public email-authentication gap, assess that email layer directly rather than inferring it from a browser-protection label. [Explore email security guidance](/learning) An email-security review cannot prove that ThreatDown Browser Protection detected or blocked a URL, inspect a private endpoint policy, or predict a receiver's handling of future messages. ## Sources and further reading - [ThreatDown platform and protection layers](https://threatdown.com) - [RFC 8601: Message Authentication Status header field](https://datatracker.ietf.org/doc/html/rfc8601) - [Palisade email security guidance](/learning) - [Palisade Email Security Score tool](/tools/email-security-score) ## Frequently asked questions ### Is ThreatDown Browser Protection the same as ThreatDown Email Security? No. ThreatDown's public platform page lists Browser Protection in its pre-delivery layer and Email Security in its prevention layer. The page presents them as separately named capabilities. ### Does ThreatDown's public page confirm that Browser Protection blocks phishing sites? No. The page confirms that ThreatDown lists Browser Protection in its pre-delivery layer, but it does not document a specific phishing-page detection or blocking behavior. ### Can a message header prove what happened in a browser? No. A delivered message header can provide evidence about message handling and authentication. It does not prove that a browser-related or endpoint control inspected, allowed, warned on, or blocked a later web destination. ### Can a public email-security check validate ThreatDown Browser Protection? No. A public email-security check can assess public domain and DNS signals. It does not inspect ThreatDown configuration, endpoint events, browser activity, or private policy decisions. ### Does browser protection replace email authentication? No. Browser-related protection and email authentication apply to different evidence and stages. Email authentication helps receivers assess authorized use of a visible From domain, while browser-related protection is a separately described layer in ThreatDown's model. --- # TLS-RPT check: verify your published reporting record Canonical: https://www.palisade.email/learning/tls-rpt-check > TLS-RPT check: verify the published TLS reporting TXT record, read its rua value, and understand what a passing result does not prove for your domain. A TLS-RPT check looks for a DNS TXT record at `_smtp._tls.yourdomain.com` and confirms whether it declares `v=TLSRPTv1`. Any domain can publish this optional reporting policy. A passing DNS result shows that the record is visible and can expose its reporting destination, but it does not prove that reporting systems can deliver a report or that a report will arrive. ## Quick takeaways - TLS-RPT is defined by [RFC 8460](https://www.rfc-editor.org/rfc/rfc8460.html), a final IETF RFC for reporting SMTP TLS connection failures. - The TLS-RPT record belongs at `_smtp._tls.<domain>` as a DNS TXT record. - A valid record begins with `v=TLSRPTv1` and uses the `rua` tag to name one or more report destinations. - RFC 8460 permits `mailto` and `https` report URIs. - TLS-RPT is optional and does not require an MTA-STS policy. - A published record check cannot prove that a receiver generated, signed, delivered, or that you received a report. ## Who is affected? TLS-RPT applies to domain owners who want reports about failures to establish TLS for SMTP delivery to their domains. It is intended as a companion to MTA-STS, but [RFC 8460](https://www.rfc-editor.org/rfc/rfc8460.html) does not make MTA-STS a prerequisite. A reporting receiver can use the `no-policy-found` policy type when it found neither a DANE nor MTA-STS policy. The domain owner publishes the TLS-RPT DNS record and operates, or delegates, the destination named by `rua`. Sending systems decide whether to generate reports. The standard does not require every SMTP sender or mailbox provider to send them. This makes TLS-RPT useful for transport visibility, not as a guarantee of encrypted delivery. Read [what MTA-STS is](/learning/what-is-mta-sts) separately when you need to understand the policy that tells sending servers how to handle a TLS failure. TLS-RPT is part of the broader [email infrastructure and transport](/learning/infrastructure) work for a domain. It does not replace message authentication such as SPF, DKIM, or DMARC. ## What are the requirements? ### The record is published at the TLS-RPT policy name RFC 8460 defines a TLS-RPT policy record as a DNS TXT record at `_smtp._tls.<domain>`. The record starts with the version tag `v=TLSRPTv1`. ```text _smtp._tls.yourdomain.com. IN TXT "v=TLSRPTv1; rua=mailto:reports@yourdomain.com" ``` This is an illustrative structure only. Publish the record under your own domain and use a report destination your team controls. A TLS-RPT check should query the exact `_smtp._tls` host, not the root domain's TXT records. A generic DNS lookup can display the raw TXT value, but the [DNS lookup tool](/tools/dns-lookup) does not identify the TLS-RPT owner name or interpret the policy tags for you. ### The `rua` tag names report destinations RFC 8460 requires a `rua` tag when the domain requests aggregate TLS reports. The tag contains one or more reporting URIs, separated by commas. Only `mailto` and `https` URI schemes are permitted by the standard. ```text v=TLSRPTv1; rua=mailto:reports@yourdomain.com,https://reports.yourdomain.com/v1/tlsrpt ``` For a `mailto` destination, RFC 8460 states: "Reports sent via SMTP MUST contain a valid DomainKeys Identified Mail (DKIM) signature by the reporting domain. Reports lacking such a signature MUST be ignored by the recipient." The RFC also says that the receiving domain's DKIM record `SHOULD` declare the `s=tlsrpt` service type. This is a report-delivery condition, not something a basic published-record check can establish. ### The record must identify TLS-RPT version 1 A TLS-RPT checker can identify a record when it finds `v=TLSRPTv1`. This verifies the policy version marker and lets the checker extract a `rua` value if one is present. It does not validate every operational property of the destination. For example, a record check does not prove that an `https` endpoint accepts reports, that a `mailto` destination can receive them, or that the receiving side will accept the reporting domain's DKIM signature. ![TLS-RPT publication checklist showing the DNS owner name, version tag, rua destination, and report-delivery limits](/images/editorial/tls-rpt-check/tls-rpt-check-checklist.webp "1200x582") *Source: Palisade.* ## When does the requirement take effect? There is no mailbox-provider TLS-RPT publication deadline or sender-volume threshold established by the sources for this article. TLS-RPT is an optional, receiver-driven protocol defined in final [RFC 8460](https://www.rfc-editor.org/rfc/rfc8460.html). RFC 8460 was published in September 2018. It replaced the earlier Internet-Draft work on SMTP TLS reporting with a final RFC. Its reporting cadence is guidance rather than a delivery deadline: a report `SHOULD` cover a full day from `00:00-24:00 UTC` and should arrive after a delay, perhaps several hours. Expect a newly published record to appear in DNS according to its TTL, then allow at least a reporting day and delivery delay before treating an empty inbox as meaningful. Even then, a lack of reports does not prove that every sender attempted delivery or that every reporting system supports TLS-RPT. ## How do I implement the requirement? ### 1. Choose a report destination Decide whether reports should go to a mailbox through `mailto` or to an HTTPS endpoint. The destination needs to be owned and monitored by the team responsible for mail transport. For `mailto`, account for the DKIM requirement in RFC 8460. The report recipient must be able to accept mail signed by the reporting domain. Do not point `rua` at an address that cannot process XML report attachments or that is outside your team's control. ### 2. Publish the TLS-RPT TXT record Create the record at `_smtp._tls.yourdomain.com`, with `v=TLSRPTv1` first and a `rua` value containing the destination URI or URIs. ```text _smtp._tls.yourdomain.com. IN TXT "v=TLSRPTv1; rua=https://reports.yourdomain.com/v1/tlsrpt" ``` This is illustrative only. Use the hostname and endpoint generated for your own reporting service. Do not copy another organization's reporting address. DNS publication alone does not configure MTA-STS. If your objective includes enforcement instructions for sending servers, configure and validate that policy separately. ### 3. Check the published record Use the [MTA-STS and TLS-RPT checker](/tools/mta-sts) with the sending domain. The checker looks up `_smtp._tls.<domain>`, displays the TXT record on its TLS-RPT row, and extracts the reporting URI on its `Reports to (rua)` row. A result marked `Not configured` means the checker did not find a `v=TLSRPTv1` record for that domain. Because TLS-RPT is optional, this is not by itself evidence that SMTP transport is broken. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=email_authentication&utm_content=tls-rpt-check) ### 4. Preserve the raw DNS evidence Keep the exact record value with the domain, query time, resolver, and DNS TTL in your change record. Querying an authoritative source and at least one public resolver helps separate a publishing problem from resolver propagation. If the record contains a `mailto` URI, also document which domain signs reports and where its DKIM `s=tlsrpt` service declaration is published. This is outside the basic DNS result, but it is necessary evidence for report acceptance. ## How do I validate compliance? Validate TLS-RPT at separate layers: - DNS: Query `_smtp._tls.yourdomain.com` through the authoritative DNS service and a public resolver. Confirm the TXT value begins with `v=TLSRPTv1` and inspect the complete `rua` value. - Record interpretation: Run the [MTA-STS and TLS-RPT checker](/tools/mta-sts) to confirm it finds the record and extracts the intended destination. - Report delivery: For `mailto`, inspect a received report's DKIM signature and the recipient domain's applicable `s=tlsrpt` declaration. For HTTPS, inspect endpoint logs for a received report. - Reporting behavior: Wait for the reporting interval described in RFC 8460 and compare received reports with known SMTP delivery activity. A green record result is DNS evidence only. It does not validate a URI scheme, prove the `mailto` DKIM prerequisite, test an HTTPS endpoint, or prove that any sender will generate a report. It also cannot show whether an individual SMTP connection used TLS successfully. If reports start arriving, use [Google MTA-STS TLS reports](/learning/google-mta-sts-tls-reports) for the adjacent task of understanding report delivery and related MTA-STS evidence. ## Check the published TLS-RPT record before relying on reports A published TLS-RPT record is the first evidence to collect when reports are missing or a new destination has been configured. Check the domain's `_smtp._tls` record and compare the displayed `rua` with the destination you intended to publish. [Check the TLS-RPT record](/tools/mta-sts) The check confirms that a public DNS lookup found `v=TLSRPTv1` and can extract `rua`. It does not prove report delivery, validate the destination service, monitor future DNS changes, or guarantee that a reporting sender will send data. ## Sources and further reading - [RFC 8460: SMTP TLS Reporting](https://www.rfc-editor.org/rfc/rfc8460.html) - [RFC 8460 text version](https://www.rfc-editor.org/rfc/rfc8460.txt) - [MTA-STS and TLS-RPT checker](/tools/mta-sts) - [What is MTA-STS?](/learning/what-is-mta-sts) ## Frequently asked questions ### How do I check whether my TLS-RPT record is published? Use the [MTA-STS and TLS-RPT checker](/tools/mta-sts) with your bare domain. It looks up `_smtp._tls.<domain>`, shows the TLS-RPT TXT record, and extracts the `rua` report destination when it finds `v=TLSRPTv1`. ### What does "Not configured" mean in a TLS-RPT check? It means the checker did not find a TLS-RPT record beginning with `v=TLSRPTv1` for the domain. TLS-RPT is optional under [RFC 8460](https://www.rfc-editor.org/rfc/rfc8460.html), so the result does not by itself mean that mail delivery or TLS is failing. ### Does a passing TLS-RPT check mean I will receive reports? No. A passing check confirms the published DNS record, not report delivery. For `mailto` destinations, RFC 8460 requires reports sent through SMTP to carry a valid DKIM signature by the reporting domain, and recipients must ignore reports without one. ### How long until TLS-RPT reports start arriving? RFC 8460 says a report `SHOULD` cover a full UTC day and should arrive after a delay, perhaps several hours. Allow for DNS propagation, a reporting day, and delivery delay. A report may still not arrive if no reporting sender generates one. ### Do I need MTA-STS before TLS-RPT works? No. RFC 8460 defines a `no-policy-found` result for cases where neither DANE nor MTA-STS policy was found. TLS-RPT is intended to complement MTA-STS, but it can report transport outcomes without an MTA-STS policy. ### What should a TLS-RPT `rua` value look like? A `rua` value contains one or more comma-separated `mailto` or `https` URIs, as specified by [RFC 8460](https://www.rfc-editor.org/rfc/rfc8460.html). For example: `rua=mailto:reports@yourdomain.com` or `rua=https://reports.yourdomain.com/v1/tlsrpt`. --- # TLS-RPT for Office 365: setup and verification Canonical: https://www.palisade.email/learning/tls-rpt-office-365 > TLS RPT Office 365 setup uses a DNS TXT record to receive Exchange Online TLS reports. Learn the record, limits, checks, and report verification. TLS-RPT for Office 365 is configured in your domain's DNS, not in the Exchange admin center. Publish a TLS-RPT TXT record at `_smtp._tls.yourdomain.com` with a reporting URI, then inspect the record and the reports it receives. Microsoft documents that Exchange Online sends TLS-RPT reports in JSON format, while TLS enforcement in Exchange Online is a separate connector configuration. ## Quick takeaways - TLS-RPT is an IETF Standards Track reporting mechanism defined by [RFC 8460](https://datatracker.ietf.org/doc/html/rfc8460). - A TLS-RPT record is a DNS TXT record under `_smtp._tls`, with `v=TLSRPTv1` and at least one `rua` reporting URI. - Microsoft documents that Exchange Online sends TLS-RPT reports in JSON format. - TLS-RPT does not force TLS for Office 365 mail flow or change an Exchange Online connector. - Exchange Online uses opportunistic TLS by default for external mail and may send mail without encryption when the receiving organization does not support TLS. - Microsoft has deprecated TLS 1.0 and TLS 1.1 in Office 365 and Office 365 GCC. Microsoft documents TLS 1.2 for connections between Exchange Online servers in its data centers. ## Who is affected? TLS-RPT applies to the administrator of a destination domain that wants feedback when sending mail systems encounter Transport Layer Security failures while delivering to that domain. The administrator publishes the record in DNS and operates, or designates, the reporting endpoint. For an Office 365 tenant, this distinction matters. [Microsoft's Exchange Online SMTP DANE documentation](https://learn.microsoft.com/en-us/exchange/security-and-compliance/how-dane-secures-email) says Exchange Online sends TLS-RPT reports in JSON format. Exchange Online can therefore be a report sender when another domain publishes a TLS-RPT record. The Office 365 administrator does not enable TLS-RPT with a tenant switch. Microsoft documents adding a TXT record in the domain's own DNS to receive reports. Microsoft does not document a tenant-side TLS-RPT dashboard, cmdlet, or Exchange admin center setting. TLS-RPT is also separate from [DKIM for Office 365](/resources-post/dkim-for-office-365). DKIM authenticates parts of an email message. TLS-RPT describes delivery attempts involving TLS policy mechanisms, including DANE and MTA-STS. Neither control enables the other. ## What are the requirements? RFC 8460, "SMTP TLS Reporting," is the controlling standard. It is an IETF Standards Track RFC published in September 2018, not a draft. It defines a DNS discovery record and a JSON report format for TLS policy failures. ### The domain publishes a TLS-RPT DNS record RFC 8460 section 3 requires a TLS-RPT record under the `_smtp._tls` branch for the policy domain. The record has a version tag and one or more `rua` tags that identify where reports should go. ```text _smtp._tls.yourdomain.com. IN TXT "v=TLSRPTv1; rua=mailto:tls-reports@yourdomain.com" ``` The example is illustrative only. Use the reporting mailbox or HTTPS endpoint your organization controls. Do not copy another organization's URI or publish a destination that cannot safely process the reports. RFC 8460 requires the `v=TLSRPTv1` tag to appear first. It also requires at least one `rua` tag. A `rua` value can use `mailto` or `https`, subject to the standard's authorization rules for external report destinations. Microsoft's documented example is its own published record for `microsoft.com`: ```text _smtp._tls.microsoft.com. IN TXT "v=TLSRPTv1;rua=https://tlsrpt.azurewebsites.net/report" ``` That example shows Microsoft's configuration. It is not a record value for another domain. ![TLS-RPT record checklist showing the DNS owner name, required version tag, and report URI](/images/editorial/tls-rpt-office-365/tls-rpt-office-365-record-checklist.webp "1200x582") *Source: Palisade.* For a deeper explanation of the version tag, see [what `v=TLSRPTv1` means in a TLS-RPT record](/learning/glossary/tls-rpt-v-tlsrptv1). ### The reporting URI accepts authorized reports TLS-RPT report delivery has its own authorization boundary. RFC 8460 defines how a report receiver checks whether it is authorized to receive reports for a policy domain when the `rua` destination is outside that domain. An HTTPS endpoint needs to accept the report format described in RFC 8460. A mailbox address needs a process that can receive and interpret the JSON attachments or messages that reporting senders produce. Publishing `rua` does not make a reporting destination operational by itself. Do not treat a valid DNS record as proof that every sender will deliver reports. Report generation depends on a sender attempting delivery, encountering an applicable policy result, and implementing TLS-RPT. ### TLS-RPT reports policy outcomes, not every TLS event RFC 8460 defines result-type values for SMTP TLS policy outcomes. Microsoft reuses several of those values in its documented Exchange Online DANE non-delivery reports: ```text 4/5.7.321 starttls-not-supported 4/5.7.322 certificate-expired 4/5.7.323 tlsa-invalid 4/5.7.324 dnssec-invalid ``` Microsoft documents an exception for DNSSEC failure handling. When a domain signals DNSSEC support but the check fails, Exchange Online does not generate `4/5.7.324 dnssec-invalid`; it generates the generic DNS error `4/5.4.312 DNS query failed`. These codes are useful evidence when diagnosing delivery behavior, but they do not establish that a TLS-RPT record is present or that a report endpoint received a JSON report. ## When does the requirement take effect? RFC 8460 has been a Standards Track RFC since September 2018. It defines an optional protocol mechanism. The standard does not impose an Office 365 sender threshold, an Exchange Online enforcement date, or a requirement that every domain publish a TLS-RPT record. Microsoft's documentation states that Exchange Online sends TLS-RPT reports in JSON format. It does not publish a separate TLS-RPT rollout date or an Office 365 deadline for domain owners to add the DNS record. Do not confuse this with Microsoft's TLS protocol changes. [Microsoft's TLS guidance for Exchange Online](https://learn.microsoft.com/en-us/purview/exchange-online-uses-tls-to-secure-email-connections) says TLS 1.0 and TLS 1.1 are deprecated in Office 365 and Office 365 GCC. That is not a TLS-RPT effective date. Microsoft documents TLS 1.2 for Exchange Online server-to-server connections in its data centers. The cited guidance does not state a TLS 1.3 position, so do not infer one from the TLS-RPT configuration. ## How do I implement the requirement? ### 1. Choose the domain that needs delivery-policy reports Start with the domain receiving mail and identify who owns its authoritative DNS zone. TLS-RPT belongs under that domain's `_smtp._tls` name. If the domain also uses MTA-STS or DANE, keep their records and policies separate. TLS-RPT reports on relevant policy outcomes. It does not publish the MTA-STS policy itself. See [what MTA-STS is](/learning/what-is-mta-sts) for that adjacent control. ### 2. Choose a report destination Choose a `mailto` address or HTTPS endpoint that your team can monitor. Plan how reports will be retained, parsed, and restricted because they can contain delivery-policy details about your domain. If the destination is outside the reporting domain, follow RFC 8460's external reporting authorization rules. Do not assume an external service can receive reports because its address appears in the `rua` value. ### 3. Publish the TXT record in authoritative DNS Create one TXT record at `_smtp._tls.yourdomain.com` with `v=TLSRPTv1` first and at least one `rua` value. Obtain the actual destination value from the mailbox or reporting service that will receive the data. > Do not remove existing MX, SPF, DKIM, DMARC, MTA-STS, or DANE records while adding TLS-RPT. TLS-RPT is an additional TXT record under a different owner name. Allow the DNS change to propagate according to the zone's TTL. Then query the authoritative server and at least one public resolver to confirm that the expected TXT record is visible. ### 4. Keep forced TLS separate from TLS-RPT Exchange Online uses opportunistic TLS by default for external partners. Microsoft states that it tries to negotiate the most secure mutually supported TLS version, but by default can send the message without encryption if the recipient organization does not support TLS. If your requirement is to require TLS for a partner, Microsoft documents this as a forced TLS connector configuration. For full sent and received coverage, Microsoft says Exchange Online needs more than one connector that requires TLS: one for mail sent to user mailboxes and another for mail sent from user mailboxes. A forced TLS connector is an Exchange Online mail-flow control. A TLS-RPT record is DNS-based reporting. Configure and test each one for its own purpose. ## How do I validate compliance? First, query `_smtp._tls.yourdomain.com` through the authoritative DNS server and a public resolver. Confirm the owner name, `v=TLSRPTv1` tag, and intended `rua` value. A raw [DNS lookup](/tools/dns-lookup) can show the TXT response, but it does not by itself explain TLS-RPT tags or prove report authorization. Next, use the [MTA-STS Checker](/tools/mta-sts) to inspect the TLS-RPT record at the correct `_smtp._tls` owner name. Its result is a published-record check. A valid result does not validate the reporting URI scheme, prove that an external report destination is authorized, or confirm that Exchange Online has delivered a report. Then validate the report receiver. Confirm that it accepts the expected RFC 8460 JSON data, retains enough detail for investigation, and protects the report data appropriately. When reports arrive, compare their policy domain, result types, and time range with known delivery activity. Finally, validate actual mail behavior separately. For Exchange Online forced TLS, inspect connector status and test mail through the exact production path. For DANE or MTA-STS issues, retain the relevant Exchange Online NDR and compare its code with Microsoft's documented behavior. A DNS record alone cannot prove the production sending path, a receiver's policy decision, or future delivery. ## Check the TLS-RPT record for your Office 365 domain Use the MTA-STS Checker to inspect the `_smtp._tls` TXT record that tells Exchange Online and other capable senders where to send TLS-RPT data. [Check the TLS-RPT record](/tools/mta-sts) The checker can confirm the published record and parse its reporting URI. It cannot prove that Exchange Online delivered a JSON report, repair a TLS failure, enforce TLS for a partner, or guarantee future message delivery. For ongoing email-authentication monitoring after you verify the record, [create a Palisade account](https://app.palisade.email/signup). ## Sources and further reading - [RFC 8460: SMTP TLS Reporting](https://datatracker.ietf.org/doc/html/rfc8460) - [Microsoft Learn: How DANE secures email in Exchange Online](https://learn.microsoft.com/en-us/exchange/security-and-compliance/how-dane-secures-email) - [Microsoft Learn: How Exchange Online uses TLS to secure email connections](https://learn.microsoft.com/en-us/purview/exchange-online-uses-tls-to-secure-email-connections) - [MTA-STS Checker](/tools/mta-sts) ## Frequently asked questions ### What is TLS-RPT? TLS-RPT is the SMTP TLS Reporting protocol defined by RFC 8460. A domain publishes a DNS TXT record under `_smtp._tls` that identifies where capable senders can send reports about DANE and MTA-STS policy successes and failures. ### What TLS version does Office 365 use? Microsoft states that Exchange Online servers always encrypt connections to other Exchange Online servers in its data centers with TLS 1.2. Microsoft has deprecated TLS 1.0 and TLS 1.1 in Office 365 and Office 365 GCC. The cited Microsoft guidance does not state a TLS 1.3 position. ### How do I set up TLS-RPT with Office 365? Add a TXT record in your own domain's DNS at `_smtp._tls.yourdomain.com` with `v=TLSRPTv1` and a `rua` reporting URI. Microsoft documents that Exchange Online sends TLS-RPT reports in JSON format. There is no documented Exchange admin center setting for publishing your TLS-RPT record. ### How do I enable TLS on Office 365? TLS is already enabled as opportunistic TLS by default for Exchange Online external mail flow. If you need to require TLS for a partner, Microsoft documents forced TLS through Exchange Online connectors. That connector configuration is separate from the TLS-RPT DNS record. ### Does Exchange Online send TLS-RPT reports? Yes. Microsoft's Exchange Online SMTP DANE documentation states that Exchange Online sends TLS-RPT reports in JSON format. A sender can report only when the destination domain publishes the applicable TLS-RPT record and the delivery attempt produces reportable policy information. ### What do Exchange Online DANE bounce codes such as `starttls-not-supported` mean? They identify documented DANE-related delivery failures. Microsoft lists `starttls-not-supported`, `certificate-expired`, `tlsa-invalid`, and `dnssec-invalid`, which align with RFC 8460 result-type vocabulary. Microsoft documents that a DNSSEC check failure can instead produce `4/5.4.312 DNS query failed`. --- # TLS-RPT reporting: how to read SMTP TLS reports Canonical: https://www.palisade.email/learning/tls-rpt-reporting > TLS-RPT reporting explains the JSON reports sent for SMTP TLS failures, their result types, delivery format, cadence, and how to interpret them. TLS-RPT reporting lets a receiving domain learn how other mail systems experienced SMTP TLS connections to its MX servers. [RFC 8460](https://www.rfc-editor.org/rfc/rfc8460.txt) defines the JSON report format, result types, delivery methods, and reporting cadence. TLS-RPT is optional, with no protocol operative date or verified mailbox-provider mandate to publish a TLS-RPT record. ## Quick takeaways - TLS-RPT is defined by RFC 8460, a Standards Track RFC published in September 2018. - A TLS-RPT report can show successful TLS sessions as well as failed sessions. - Reports identify the policy evaluated, session totals, and failure details when available. - The reporting sender SHOULD cover a full UTC day and delivers the report after a delay. - TLS-RPT works with MTA-STS, DANE, or cases where neither policy was found. - A published TLS-RPT record tells senders where to send reports. It does not prove that reports will arrive or that mail delivery is healthy. ## Who is affected? TLS-RPT applies to domains that publish a TLS-RPT DNS record and ask other mail systems to send SMTP TLS reports to the record's `rua` destination. Under [RFC 8460 section 2](https://www.rfc-editor.org/rfc/rfc8460.txt), sending domains compatible with MTA-STS or DANE can report their TLS connection experience to recipient domains. The receiving domain publishes the reporting destination. The sending domain evaluates the recipient's transport security policy and may create a report for that destination. Microsoft documents that [Exchange Online sends TLS-RPT reports in JSON format](https://learn.microsoft.com/en-us/exchange/security-and-compliance/how-dane-secures-email), so a report can come from a major sender without indicating that the sender or recipient has made an error. TLS-RPT is a companion to MTA-STS, not a prerequisite for it. A TLS-RPT report can use `no-policy-found` when neither DANE nor an MTA-STS policy was found. For the transport policy itself, see [what MTA-STS is](/learning/what-is-mta-sts). For the Google-specific reason reports may arrive, see [why Google sends MTA-STS TLS reports](/learning/google-mta-sts-tls-reports). ## What are the requirements? ### A TLS-RPT record supplies a reporting destination RFC 8460 defines a DNS TXT record at `_smtp._tls.<domain>`. Its `rua` tag contains one or more `mailto` or `https` destinations for reports. ```text _smtp._tls.yourdomain.com. IN TXT "v=TLSRPTv1; rua=mailto:tls-reports@yourdomain.com" ``` This is an illustrative record shape only. Publish the reporting address or HTTPS endpoint that your organization controls. The RFC requires the version tag `v=TLSRPTv1`. The `rua` value tells a reporting sender where it may deliver the report. It does not require a sender to generate a report, and it does not establish an MTA-STS policy. See [what `v=TLSRPTv1` means in a TLS-RPT record](/learning/glossary/tls-rpt-v-tlsrptv1) for the record-specific explanation. ![TLS-RPT reporting flow from a published DNS record to a reporting sender and a JSON report destination](/images/editorial/tls-rpt-reporting/tls-rpt-reporting-flow.webp "1200x829") *Source: Palisade.* ### The report uses the RFC 8460 JSON schema RFC 8460 section 4 defines an I-JSON report containing the reporting organization, the covered date range, a report ID, and policy results. Each policy entry includes a policy type, policy domain, MX host information, session totals, and optional failure details. ```json { "organization-name": "Example Mail Sender", "date-range": { "start-datetime": "2026-08-12T00:00:00Z", "end-datetime": "2026-08-13T00:00:00Z" }, "contact-info": "tls-reporting@example.net", "report-id": "example-report-id", "policies": [ { "policy": { "policy-type": "sts", "policy-string": ["version: STSv1", "mode: enforce"], "policy-domain": "yourdomain.com", "mx-host": ["mail.yourdomain.com"] }, "summary": { "total-successful-session-count": 125, "total-failure-session-count": 2 }, "failure-details": [] } ] } ``` The values above are illustrative only. Do not treat the example as a report received for a real domain. Start with `total-successful-session-count` and `total-failure-session-count`. A report with successful sessions is also a heartbeat that TLS negotiation occurred as expected. A nonzero failure count needs investigation, but it does not identify the exact affected message unless the report's failure details contain enough evidence. ### Result types classify the connection failure RFC 8460 section 4.3 defines result types for the failure details in a report. Negotiation failures include `starttls-not-supported`, `certificate-host-mismatch`, `certificate-expired`, `certificate-not-trusted`, and `validation-failure`. DANE-specific result types include `tlsa-invalid`, `dnssec-invalid`, and `dane-required`. MTA-STS-specific types include `sts-policy-fetch-error`, `sts-policy-invalid`, and `sts-webpki-invalid`. The RFC also defines general and transient failures. For `certificate-not-trusted` and `validation-failure`, RFC 8460 directs the reporting sender to provide more detail in `failure-reason-code`. Treat that field as sender-provided diagnostic context. It is useful evidence, but it does not replace checking the certificate, DNS, MX service, and production delivery path. ### Email delivery has a defined wrapper and filename RFC 8460 section 5 permits report delivery by email or HTTPS. A report filename follows this shape: ```text sender!policy-domain!begin-timestamp!end-timestamp[!unique-id].json sender!policy-domain!begin-timestamp!end-timestamp[!unique-id].json.gz ``` The timestamps are seconds since the Unix epoch. The RFC permits gzip compression for `.json.gz` files. For email delivery, the message is `multipart/report` with `report-type="tlsrpt"`. The machine-readable part is `application/tlsrpt+json` or `application/tlsrpt+gzip`. The `TLS-Report-Domain` and `TLS-Report-Submitter` header fields MUST be included, which makes them useful filters in the mailbox receiving reports. ## When does the requirement take effect? RFC 8460, "SMTP TLS Reporting," was published in September 2018 as a Standards Track RFC. It is the controlling specification for TLS-RPT reporting. There is no operative date because TLS-RPT publication is optional. This article does not establish a mailbox-provider enforcement date, because no provider requirement or delivery consequence was verified for publishing a TLS-RPT record. RFC 8460 section 4.1 says a report SHOULD cover a full day, from `00:00-24:00 UTC`. It should arrive after a delay, perhaps several hours. The RFC gives an example of a random delay of up to four hours. Reports therefore commonly describe the preceding UTC day rather than a live connection state. ## How do I implement the requirement? ### 1. Choose a report destination Choose a controlled `mailto` address or HTTPS endpoint that can receive machine-readable TLS-RPT reports. Define who reviews reports and where compressed JSON files are retained. Do not use a shared mailbox without a sorting process. The data can include repeated policy and connection outcomes that need technical review. ### 2. Publish the TLS-RPT TXT record Publish a `v=TLSRPTv1` TXT record at `_smtp._tls.yourdomain.com` with the chosen `rua` destination. Query the authoritative DNS server and at least one public resolver after publishing. DNS visibility proves that the record is reachable. It does not prove that another sender will generate or deliver a report. ### 3. Classify the policy and result type When a report arrives, identify its `policy-type` first. Keep MTA-STS, DANE, and `no-policy-found` findings separate because they describe different transport-policy contexts. Then compare the summary totals with `failure-details`. Prioritize persistent certificate, MX hostname, policy-fetch, or DNSSEC errors before transient connection failures. A failure classification should lead to a same-path test against the affected MX service, not a speculative DNS edit. ### 4. Preserve evidence for the delivery path Keep the original report attachment or HTTPS payload, its date range, reporting organization, and report ID. If the report was delivered by email, retain the message headers that identify the report domain and submitter. Compare report findings with MX configuration, certificate state, MTA-STS policy retrieval where applicable, and logs from the affected mail service. A TLS-RPT report is aggregate evidence. It does not include every message-level detail needed to diagnose a single SMTP transaction. ## How do I validate compliance? Validate the published record at the DNS layer by querying `_smtp._tls.yourdomain.com` through the authoritative server and a public resolver. Confirm that the returned TXT value contains `v=TLSRPTv1` and the intended `rua` destination. Use the [MTA-STS Checker](/tools/mta-sts) to inspect the `_smtp._tls` record and its parsed reporting destination. The checker evaluates the published record, not report contents. Its valid result means a `v=TLSRPTv1` record exists. It cannot prove a reporting sender used the destination, monitor future reports, or show the production SMTP path. At the report layer, inspect a received JSON payload for its UTC date range, policy domain, policy type, session totals, and failure details. At the service layer, compare reported failures with certificate and MX evidence. At the message layer, test a real delivered message from the exact production sending path where an SMTP TLS failure is suspected. If the domain uses DMARC, aggregate reports provide a separate view of message authentication, not transport TLS reporting. ## Check where TLS-RPT reports are configured Before waiting for reports, check the `_smtp._tls` record and confirm that its `rua` destination is the address or endpoint your team expects. [Check the TLS-RPT record with the MTA-STS Checker](/tools/mta-sts) A record check cannot show what a received TLS-RPT report contains, prove a sender generated one, or establish a receiver's future delivery decision. If you need help monitoring TLS-RPT findings across your domains, [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=email_authentication&utm_content=tls-rpt-reporting). ## Sources and further reading - [RFC 8460: SMTP TLS Reporting](https://www.rfc-editor.org/rfc/rfc8460.txt) - [Microsoft Learn: How DANE secures email in Exchange Online](https://learn.microsoft.com/en-us/exchange/security-and-compliance/how-dane-secures-email) - [What is MTA-STS?](/learning/what-is-mta-sts) - [Infrastructure learning hub](/learning/infrastructure) ## Frequently asked questions ### What is in a TLS-RPT report? A TLS-RPT report contains an organization name, date range, contact information, report ID, and a `policies` array. Each policy entry includes policy information, successful and failed TLS session totals, and optional failure details, as defined in RFC 8460. ### How often do TLS-RPT reports arrive? TLS-RPT reports SHOULD cover a full day from `00:00-24:00 UTC`, according to RFC 8460. They arrive after a delay, perhaps several hours, so they are not real-time connection monitoring. ### What do TLS-RPT result types mean? TLS-RPT result types classify why an SMTP TLS connection did not meet the relevant policy or validation condition. Examples include certificate hostname mismatch, expired certificates, MTA-STS policy fetch errors, and DANE DNSSEC failures. Check `failure-reason-code` when the report includes it for sender-provided detail. ### Who sends TLS-RPT reports? A sending domain that implements compatible MTA-STS or DANE reporting behavior may send reports to the recipient domain's published `rua` destination. Microsoft documents that Exchange Online sends TLS-RPT reports in JSON format. ### Do I need MTA-STS to receive TLS-RPT reports? No. RFC 8460 defines `no-policy-found` for cases where neither DANE nor an MTA-STS policy could be found. TLS-RPT is a companion to MTA-STS, but MTA-STS is not a prerequisite for receiving reports. --- # TLS-RPT RFC: SMTP TLS Reporting explained Canonical: https://www.palisade.email/learning/tls-rpt-rfc > TLS-RPT RFC 8460 defines SMTP TLS Reporting, its DNS policy record, report endpoints, report format, and practical validation checks for recipient domains. TLS-RPT is defined by [RFC 8460, SMTP TLS Reporting](https://datatracker.ietf.org/doc/html/rfc8460), an IETF Proposed Standard published in September 2018. It lets a recipient domain publish where compatible sending MTAs should send aggregate data about SMTP TLS and transport-policy failures. It is relevant to domains using MTA-STS or DANE, and it reports observed sessions rather than enforcing TLS on its own. ## Quick takeaways - RFC 8460 is the controlling RFC for SMTP TLS Reporting, commonly called TLS-RPT. - A TLS-RPT policy is a DNS TXT record below `_smtp._tls` for the policy domain. - The record starts with `v=TLSRPTv1` and includes at least one `rua` reporting URI. - TLS-RPT can report successful policy-compliant TLS sessions and defined failure types. - TLS-RPT complements MTA-STS or DANE. It does not require a sending MTA to use either policy. - A published DNS record does not prove that sending MTAs will send reports or that mail will be delivered. ## Who is affected? TLS-RPT applies to recipient domains that want compatible sending MTAs to send aggregate reports about SMTP TLS sessions and transport-policy failures. [RFC 8460](https://datatracker.ietf.org/doc/html/rfc8460) defines the policy domain as the domain against which a TLS-RPT, MTA-STS, or DANE policy is defined. For TLS-RPT and MTA-STS, that is usually the SMTP envelope recipient domain defined by [RFC 5321](https://datatracker.ietf.org/doc/html/rfc5321), though a locally configured smarthost can change the relevant domain. The recipient-domain operator publishes the reporting policy and operates the destination named in `rua`. A sending MTA decides whether it supports TLS-RPT and, when it does, generates the report from its own delivery attempts. RFC 8460 does not make every sending MTA report, and it does not require a mailbox provider to use TLS-RPT. TLS-RPT is separate from the TLS protocol itself. [SMTP STARTTLS is specified in RFC 3207](https://datatracker.ietf.org/doc/html/rfc3207); TLS-RPT defines reporting around SMTP TLS and applicable MTA-STS or DANE policy outcomes. For the broader transport-security context, see [email transport security](/learning/infrastructure). ## What are the requirements? ### The policy is published as a DNS TXT record RFC 8460 distributes a TLS-RPT policy as a TXT record at `_smtp._tls.<policy-domain>`. The record's version tag must be `v=TLSRPTv1`, and the policy requires one or more `rua` values that identify report destinations. The standard permits `mailto` and HTTPS report URIs. ```text _smtp._tls.yourdomain.com. IN TXT "v=TLSRPTv1; rua=mailto:tls-reports@yourdomain.com" _smtp._tls.yourdomain.com. IN TXT "v=TLSRPTv1; rua=https://reports.yourdomain.com/v1/tlsrpt" ``` These are illustrative only. Publish the real reporting address or HTTPS endpoint that your team controls. ![TLS-RPT DNS policy anatomy showing the policy owner name, version tag, and aggregate-report URI](/images/editorial/tls-rpt-rfc/tls-rpt-rfc-record-anatomy.webp "1200x466") *Source: Palisade.* RFC 8460 says parsers MUST accept syntactically valid records with semicolon-separated key and value pairs, and they SHALL ignore unknown fields. It also defines processing rules for multiple or invalid records. Do not use a generic TXT record at the domain apex as a substitute for the `_smtp._tls` owner name. For a focused explanation of the version tag, see [what `v=TLSRPTv1` means](/learning/glossary/tls-rpt-v-tlsrptv1). ### The report describes policy results, not every delivery outcome The report schema is I-JSON. It includes report metadata, the policy applied, and aggregate session counts. RFC 8460 defines a successful session as one where the sending MTA negotiated a policy-compliant TLS connection. It also defines result types for failures such as DNS, STARTTLS, certificate, DANE, and MTA-STS policy problems. A TLS-RPT report is evidence from one reporting sender's observed SMTP sessions. It is not a list of every message sent to your domain, a sender-authentication report, or proof that a particular recipient received a message. ### Report transport has defined constraints RFC 8460 says a report MAY be delivered by email. Email reports use `multipart/report` with `report-type="tlsrpt"` and carry the machine-readable report as `application/tlsrpt+json` or `application/tlsrpt+gzip`. A report sent by SMTP MUST have a valid DKIM signature from the reporting domain, and a recipient MUST ignore an SMTP-delivered report that lacks that signature. The standard also supports HTTPS delivery. The receiving HTTPS server MUST return a successful response, typically HTTP `200` or `201`, for a delivered report. A non-success response can be treated as a delivery failure and retried according to the sender's local policy. These rules describe compliant report exchange. They do not require an operator to expose a public report endpoint if the selected `rua` is a mailbox address, and they do not establish that every sender will deliver reports on the same schedule. ## When does the requirement take effect? RFC 8460 was published in September 2018 as an IETF Standards Track document with Proposed Standard status. It replaced the Internet-Draft `draft-ietf-uta-smtp-tlsrpt`; the final RFC is the controlling specification. There is no universal TLS-RPT enforcement date in RFC 8460. The RFC defines a protocol that domains and sending MTAs may implement. MTA-STS has its own policy behavior: [RFC 8461](https://datatracker.ietf.org/doc/html/rfc8461) says that in `testing` mode, a sending MTA that also implements TLS-RPT sends a policy-application-failure report when the recipient domain also implements TLS-RPT, while mail may still be delivered as if no MTA-STS validation failure occurred. ## How do I implement the requirement? ### 1. Identify the TLS-RPT policy domain Start with the recipient domain that receives SMTP mail. If your delivery design routes mail through a locally configured smarthost, confirm whether that smarthost domain is the policy domain under RFC 8460. Keep this decision separate from the visible `From:` domain. SMTP routing uses the envelope recipient and MX delivery path, while [RFC 5322](https://datatracker.ietf.org/doc/html/rfc5322) defines the Internet Message Format used for message headers and body. ### 2. Choose a report destination your team can operate Select a `mailto` address or HTTPS endpoint that can receive and retain aggregate reports. Limit access because reports can reveal receiving MX hostnames, sending-MTA IP addresses, policy details, and session-failure information. For an email destination, make sure the receiving workflow can process the TLS-RPT report format and DKIM validation. For HTTPS, make sure the endpoint can accept the required report payload and return a successful HTTP response. ### 3. Publish the TXT record at the exact owner name Create the TXT record under `_smtp._tls` for the policy domain, using `v=TLSRPTv1` followed by the reporting URI. Follow the DNS provider's interface carefully, especially where it adds the zone suffix automatically. Use [Palisade's DNS lookup tool](/tools/dns-lookup) to inspect the publicly resolvable record after DNS propagation. A DNS lookup can show the published TXT response. It cannot prove that an MTA uses the record, that an HTTPS receiver accepts reports, or that a production SMTP session used TLS. ### 4. Pair reporting with the policy you want to observe TLS-RPT has the most specific operational value when your domain also uses MTA-STS or DANE. MTA-STS communicates a receiving domain's TLS expectations; TLS-RPT gives compatible senders a defined way to report policy outcomes. Use the [MTA-STS checker](/tools/mta-sts) to inspect the public MTA-STS and TLS-RPT records together, then compare the result with your authoritative DNS configuration. > Do not move an MTA-STS policy to enforcement based only on a TLS-RPT DNS record. DNS publication does not establish that your MX hosts, certificates, and production SMTP routes satisfy the policy. ## How do I validate compliance? Validate the DNS layer first. Query the authoritative DNS provider and at least one public resolver for `_smtp._tls.yourdomain.com` and confirm that the returned TXT value has `v=TLSRPTv1` and the intended `rua` destination. Validate the receiving layer next. For an HTTPS `rua`, confirm that the endpoint accepts a conforming report and returns a successful HTTP response. For a `mailto` destination, confirm that the receiving workflow accepts and validates a DKIM-signed TLS-RPT message. Retain only the report data that operators need for investigation. Then validate the transport-policy layer with evidence from an actual sending MTA that supports TLS-RPT. Check whether its aggregate report identifies the expected policy domain, MX host, policy type, time range, and result counts. A report with successful sessions is evidence about the reporting MTA's observed sessions only. Finally, inspect the linked MTA-STS or DANE configuration and the production SMTP path. A TLS-RPT record does not establish that a sender fetched MTA-STS, performed DANE validation, negotiated TLS on every route, or delivered a message to a mailbox. The [Infrastructure learning hub](/learning/infrastructure) has related guidance for transport and DNS controls. ## Review the transport policy behind TLS-RPT TLS-RPT tells compatible senders where to submit aggregate observations. The next operational question is which transport policy, MX identity, and TLS behavior those observations should be compared against. [Read the email transport security guide](/learning/infrastructure) That guide can help you assess the transport-security design around a TLS-RPT record. It does not prove that a particular sending MTA will publish a report or guarantee delivery for a future SMTP session. ## Sources and further reading - [RFC 8460: SMTP TLS Reporting](https://datatracker.ietf.org/doc/html/rfc8460) - [RFC 8461: SMTP MTA Strict Transport Security](https://datatracker.ietf.org/doc/html/rfc8461) - [RFC 3207: SMTP Service Extension for Secure SMTP over Transport Layer Security](https://datatracker.ietf.org/doc/html/rfc3207) - [RFC 5321: Simple Mail Transfer Protocol](https://datatracker.ietf.org/doc/html/rfc5321) - [RFC 5322: Internet Message Format](https://datatracker.ietf.org/doc/html/rfc5322) ## Frequently asked questions ### What is TLS RPT? TLS-RPT is SMTP TLS Reporting, defined by RFC 8460. A recipient domain publishes a DNS policy that names report destinations, and compatible sending MTAs can send aggregate information about SMTP TLS and applicable MTA-STS or DANE policy outcomes. ### Which RFC defines TLS? No single RFC defines every version and use of TLS. RFC 8460 defines TLS-RPT for SMTP reporting, while RFC 3207 defines the SMTP STARTTLS extension. TLS itself has separate protocol specifications. ### What is RFC 5321 and RFC 5322? RFC 5321 defines SMTP, including the envelope and relay behavior used to transfer email between mail systems. RFC 5322 defines the Internet Message Format, including message headers and body. TLS-RPT policy-domain decisions are normally tied to SMTP routing, not solely to visible RFC 5322 headers. ### How do I configure TLS RPT? Publish a TXT record at `_smtp._tls.<policy-domain>` with `v=TLSRPTv1` and at least one `rua` destination that your team operates. Then verify the record through authoritative and public DNS, test the report receiver, and review reports from compatible sending MTAs. ### Does TLS-RPT enforce SMTP TLS? No. TLS-RPT reports observed TLS and transport-policy outcomes. MTA-STS or DANE defines the relevant transport policy, while the sending MTA determines whether it supports TLS-RPT and sends a report. --- # Unlimited email warmup: what the label actually covers Canonical: https://www.palisade.email/learning/unlimited-email-warmup > Unlimited email warmup usually describes a vendor plan feature, not unlimited sending. Compare the stated inbox, support, test, and daily-email limits. Unlimited email warmup is usually a vendor-plan label, not a promise of unlimited warmup messages or unlimited sending volume. Check what the provider makes unlimited, then find the plan's explicit daily email allowance, mailbox guidance, and support or testing limits. On one published plan, TrulyInbox pairs "Unlimited Accounts" with a limit of "200 warmup emails/day." [Email deliverability](https://www.palisade.email/learning/email-deliverability) also depends on factors that a plan label does not define. ## Quick takeaways - "Unlimited" can describe connected email accounts, support, spam tests, or another plan feature. - An unlimited-account claim does not necessarily mean unlimited warmup emails per day. - TrulyInbox publishes "Unlimited Accounts" alongside "200 warmup emails/day." - EmailWarmup.com uses "unlimited" for deliverability support and free spam tests, which are separate from message volume. - Treat a recommendation to keep warmup enabled as vendor guidance unless a mailbox provider documents the same requirement. - Compare the written limits before relying on an unlimited email warmup claim. ## How an unlimited email warmup plan works "Unlimited email warmup" has no universal definition in the material available from mailbox providers or standards bodies. It is better read as commercial wording that needs a feature-by-feature interpretation. For example, [TrulyInbox's published pricing page](https://trulyinbox.com) states: "Unlimited Accounts Connect unlimited email accounts. No per-inbox pricing, ever." The same page states "200 warmup emails/day." It also says that plan is "Best suited for 3 email inboxes" and describes an allocation of "send 67 warmup emails per mailbox daily." Those statements can coexist. The account-connection feature is unlimited under that plan's wording, while the daily warmup-email volume is finite. Neither statement establishes a general rule for other providers. Other uses of the same word make the distinction clearer. [EmailWarmup.com's product page](https://emailwarmup.com) promotes "unlimited deliverability support" and "Unlimited free email spam tests." Those offers describe support and tests. They do not, by themselves, state unlimited warmup-message volume. A warmup plan is therefore an input to a broader deliverability process, not a complete description of mail performance. For adjacent plan-label questions, see [AI email warmup: what it is and what it cannot prove](https://www.palisade.email/learning/ai-email-warmup). ## When the answer changes The answer changes when the provider defines "unlimited" differently. Read the exact noun next to the word. Use this decision rule: - If the plan says unlimited accounts or inboxes, compare it with any per-day warmup-email allowance and recommended mailbox count. - If the plan says unlimited support, determine what support channel or service period that statement covers. - If the plan says unlimited tests, check whether the plan separately limits connected accounts, warmup messages, or test types. - If the plan recommends an ongoing warmup setting, treat that as the provider's guidance unless a mailbox provider publishes the same requirement. [Warmforge's warmup guidance](https://warmforge.ai) says to warm up a mailbox for at least two weeks before outreach and to keep warmup "always on." That is a statement about Warmforge's product guidance. It is not evidence that Google, Microsoft, Yahoo, or another receiving provider requires a specific warmup duration or continuous warmup. > Do not turn an "unlimited" label into a sending-volume assumption. A plan can have unlimited account connections and a separate finite daily warmup allocation. This distinction also matters when comparing products. A buyer cannot infer matching limits, timing, inbox-placement outcomes, or provider acceptance from a shared use of the word "unlimited." Compare the plan text that is published for the exact service and tier under consideration. ![Decision flow for interpreting an unlimited email warmup plan by checking what feature is unlimited and then locating the stated operating limit](/images/editorial/unlimited-email-warmup/unlimited-email-warmup-decision-flow.webp "1200x829") *Source: Palisade.* ## Worked example: read the limit behind the label A plan description can contain both an unlimited feature and a bounded operating allowance: ```text Plan label: Unlimited Accounts Connected accounts: unlimited Warmup email allowance: 200 warmup emails/day Suggested mailbox use: 3 email inboxes Illustrative per-mailbox allocation: 67 warmup emails daily ``` This is a worked interpretation of the wording published by [TrulyInbox](https://trulyinbox.com), not a universal warmup-plan specification. The useful question is not "Is this unlimited?" in isolation. Ask: - What does the provider explicitly say is unlimited? - Is there a daily warmup-email allowance? - Does the provider suggest a number of mailboxes for that allowance? - Are support, spam tests, and account connections described as separate features? - Does the provider publish a recommendation about when warmup should remain enabled? Write the answers down in the same comparison note. That prevents an unlimited-support or unlimited-account statement from being mistaken for unlimited message volume. The record also helps separate vendor claims from email authentication evidence. A warmup plan description does not show whether the sending domain publishes SPF, DKIM, or DMARC correctly, and it does not show how a specific receiver will place future messages. For a related vendor-specific explanation, see [Apollo email warmup: what it does and what it cannot prove](https://www.palisade.email/learning/apollo-email-warmup). ## Check the next thing based on the evidence you have If you are comparing plans, collect the current plan page and identify every stated limit before selecting a tier. If you already have a sending domain, inspect its authentication posture separately from the warmup provider's marketing language. Use an authentication check when you have a domain name and need a public DNS view. Keep the result separate from any claim about warmup effectiveness, since a public check cannot observe an individual recipient's placement decision or a service's internal warmup activity. ## Check the sending domain's authentication posture Run the sending domain through Palisade's score checker to inspect its public email-authentication posture alongside the plan limits you recorded. [Check the email security score](https://www.palisade.email/tools/email-security-score) A public score cannot verify inbox placement, prove a warmup service's effectiveness, observe continuous sending behavior, or establish a receiver's private reputation decision. If your team needs to identify sending sources and authentication or alignment issues across domains, Palisade autonomously analyzes DMARC aggregate-report data and creates prioritized remediation tickets. A human reviews the evidence and applies any DNS or policy change. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=warmup_sending_practices&utm_content=unlimited-email-warmup) Palisade does not guarantee delivery or inbox placement, and it does not prove that a vendor's warmup plan will produce a particular result. ## Sources and further reading - [TrulyInbox pricing and warmup plan details](https://trulyinbox.com) - [EmailWarmup.com product page](https://emailwarmup.com) - [Warmforge warmup guidance](https://warmforge.ai) - [Palisade email security score](https://www.palisade.email/tools/email-security-score) ## Frequently asked questions ### Does unlimited email warmup mean unlimited sending? No, the word usually covers one part of the plan rather than your whole sending. TrulyInbox, for example, advertises unlimited account connections while also stating "200 warmup emails/day" in the same plan material. Read the provider's stated volume limit instead of assuming "unlimited" applies to everything. ### Are unlimited inbox connections the same as unlimited warmup emails? No, they are two separate plan features. TrulyInbox lists "Unlimited Accounts" alongside a stated daily warmup-email allowance, so how many mailboxes you can connect says nothing about how many warmup messages each one may send. ### Does unlimited deliverability support mean unlimited warmup volume? No, that phrase is about support, not sending volume. EmailWarmup.com uses "unlimited deliverability support" and separately promotes "Unlimited free email spam tests." Neither statement promises an unlimited warmup-message allowance. ### Should email warmup stay enabled permanently? Leaving warmup on permanently is vendor advice rather than a rule. Warmforge recommends leaving its warmup running after the initial period it suggests, and no mailbox provider publishes a requirement to keep warmup on. Treat it as a vendor's operating preference and decide against your own sending pattern. ### Can an email security score prove that warmup is working? No, a public score cannot tell you that. It inspects the authentication posture your domain publishes, which reveals nothing about a warmup service's behavior, where your mail lands, or how a receiver rates your reputation in private. --- # Valimail vs EasyDMARC: how the two compare Canonical: https://www.palisade.email/learning/valimail-vs-easydmarc > Valimail vs EasyDMARC: compare published pricing, cost drivers, operational fit, and the evidence to confirm before choosing a DMARC platform. Choose Valimail or EasyDMARC only after comparing the commercial terms each vendor currently publishes for the scope you need. The useful decision is not a generic feature verdict. It is whether each vendor's current pricing, included limits, contract terms, and operating model fit the domains and senders your team must manage. ## Quick takeaways - A DMARC platform comparison should start with current first-party pricing and plan terms. - A published starting price does not establish the cost for every domain, sender, user, or MSP client. - A plan limit matters only when it maps to the domains and operating work your team owns. - A public DNS check can establish the current DMARC record, but it cannot establish a vendor's commercial terms or future mailbox-provider decisions. - Keep undocumented capabilities, limits, and contract details as open questions until each vendor confirms them. - Use the wider [DMARC vendor comparison hub](/compare) when this is one of several platforms under consideration. ## Who this comparison is for This comparison is for an IT team, security team, or MSP that is evaluating Valimail and EasyDMARC as possible DMARC operating platforms. The buyer may already have a DMARC record, may be collecting aggregate reports, or may be planning a move from monitoring toward enforcement. The decision becomes more specific when you define the operating scope first: - Number of domains that must be managed. - Number of sending services and third-party senders that must be identified and assessed. - Number of people or client organizations that need access to the workflow. - Whether the team needs one internal operating process or a repeatable multi-client process. - Which commercial terms must be known before a purchase decision, including billing period, included limits, renewal terms, and any quote-based scope. Those inputs are not interchangeable. A team with one domain and a small sending inventory has a different purchasing question from an MSP responsible for separate customer domains, delegated access, and recurring remediation work. Before treating a platform result as evidence of readiness, separate the four validation layers. DNS confirms what authoritative servers publish. Vendor status confirms what the vendor has evaluated. A delivered production message confirms the authentication results for that path. DMARC aggregate reports show observed sending activity after reports accumulate. None of those layers alone establishes the full operational workload or the final commercial cost. ## How the options were evaluated The comparison criteria are fixed before selecting an option. The relevant evidence is each vendor's current first-party pricing page and any first-party plan documentation that explains published terms. Pricing, included limits, billing conditions, and capability scope can change, so confirm them directly with the vendor before purchase. The criteria are: - Published commercial evidence: current prices, plan names, included limits, billing terms, and quote-based conditions, if the vendor publishes them. - Cost driver: the unit that changes the price or contract scope, such as domains, users, reporting retention, managed-service requirements, or another documented factor. - Operational fit: the work the buyer needs to perform after onboarding, including sender inventory, remediation review, policy progression, and multi-domain administration. - Evidence boundary: what the published page establishes and what still requires a direct vendor conversation or a test in the buyer's own environment. - Open questions: facts that are not documented on the current page being reviewed. This method does not infer a missing feature from a page that does not mention it. A missing detail is an open question. It also does not turn a public DNS result into proof of a platform's report processing, workflow, support model, or contract scope. ![Decision flow for comparing Valimail and EasyDMARC using published commercial terms, operating scope, and unresolved questions](/images/editorial/valimail-vs-easydmarc/valimail-vs-easydmarc-decision-flow.webp "1200x829") *Source: Palisade.* ## Valimail Valimail should be evaluated against the same commercial and operational criteria as EasyDMARC. Confirm Valimail's current published pricing and plan terms directly on its first-party pricing materials before recording any price, included quantity, billing condition, or capability as part of the decision. - Best fit: Teams whose confirmed Valimail commercial terms and operating workflow match their domain scope and internal approval process. - Relevant evidence: A current Valimail first-party pricing page and any linked first-party plan-detail or contract documentation. - Tradeoff: The buyer cannot safely estimate a final cost or operational fit from an unverified plan name, third-party estimate, old screenshot, or reseller description. Ask the vendor to map its published terms to the environment you will actually operate. For an internal IT team, that may mean the production domains, sending sources, administrator access, and policy-review workflow. For an MSP, it may mean whether the commercial model and administration model support separate customer ownership, delegated access, and recurring client work. The technical evaluation should stay separate from the purchasing evaluation. A DMARC record can be inspected independently, but a record does not show every sender that has used the domain or whether a platform's workflow fits the remediation work ahead. The [Valimail alternative guide](/valimail-alternative) can help frame the questions to carry into a broader vendor evaluation. ## EasyDMARC EasyDMARC should also be evaluated from its current first-party pricing materials and plan documentation. Confirm its published prices, plan names, included limits, billing terms, and any quote-based conditions directly with EasyDMARC before using them in a purchase comparison. - Best fit: Teams whose confirmed EasyDMARC terms and workflow match their domain inventory, sender complexity, and operator model. - Relevant evidence: A current EasyDMARC first-party pricing page and any linked first-party documentation that defines a published limit or included capability. - Tradeoff: A buyer should not assume an unpublished limit, integration, support commitment, MSP condition, or renewal term. Use the same questions for both vendors. If one vendor publishes a limit, record the exact unit and whether your expected usage is below, near, or above it. If a vendor does not publish a needed term, ask for that term in writing and leave the scorecard question open until you receive an answer. An operational comparison also needs production evidence. A platform can help organize DMARC work, but the team should still validate a real delivered message from each important sending path and review aggregate-report data after it accumulates. A green status indicator is not proof that every future message will authenticate or that a receiving provider will place every message in the inbox. For an alternative-oriented evaluation path, see the [EasyDMARC alternative guide](/easydmarc-dmarc-alternative). ## How to choose Choose the option whose current, confirmed commercial terms fit the scope you must manage and whose workflow fits the people responsible for reviewing evidence and applying changes. Do not choose based on a headline price alone. Use this checklist during vendor conversations: - Define the domains that are in scope now and those likely to be added during the contract period. - List the sending sources that need investigation, including ESPs, help desks, CRMs, and transactional services. - Confirm the unit that drives each vendor's price or contract scope. - Confirm which limits apply to your expected operating scope. - Ask how the workflow supports the approval process for DNS and DMARC policy changes. - Record what is documented, what was confirmed directly, and what remains unknown. ```yaml option: Valimail checked_on: 2026-08-13 best_fit: Confirmed commercial terms and workflow fit the buyer's domain scope and operating model. verified_evidence: Confirm current first-party pricing and plan documentation directly with Valimail. open_question: Published price, included limits, billing terms, and capability scope require current first-party confirmation. option: EasyDMARC checked_on: 2026-08-13 best_fit: Confirmed commercial terms and workflow fit the buyer's domain scope and operating model. verified_evidence: Confirm current first-party pricing and plan documentation directly with EasyDMARC. open_question: Published price, included limits, billing terms, and capability scope require current first-party confirmation. ``` The decision record should contain the same fields for each option. That makes differences visible without inventing a feature matrix or treating an undocumented detail as absence. A useful technical baseline comes before a platform rollout. Use the [DMARC checker](/tools/dmarc) to inspect the public DMARC record for a domain you expect to manage. Compare the result with an authoritative DNS response and a real delivered message from the production sending path. A public record check does not prove which platform fits your contract, identify every production sender, monitor later changes, or guarantee future message placement. ## Check the current DMARC record before comparing workflows If the buying decision concerns a domain that is not yet understood, inspect its current public DMARC policy first. The result gives the evaluation team a concrete starting point for vendor conversations: the record currently published for the domain. Use the [DMARC checker](/tools/dmarc) to check the sending domain before requesting a platform demonstration. Then compare the record with a delivered message's `Authentication-Results` header and later with aggregate-report evidence. ```text Illustrative only. Do not publish this example as a production record. _dmarc.yourdomain.com TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com" ``` The example shows record structure only. Your organization must use its own reporting destination and should validate the intended policy against the sending sources that actually use the domain. Palisade is agentic DMARC software for teams that want an AI agent to analyze aggregate-report data, identify sending sources and authentication or alignment issues, create prioritized remediation tickets, and propose the next policy step for human review. Palisade does not autonomously change the DMARC policy, guarantee delivery, or prove that every future message will authenticate. ## Sources and further reading - [Palisade DMARC checker](/tools/dmarc) - [Palisade vendor comparisons](/compare) - [Valimail alternative guide](/valimail-alternative) - [EasyDMARC alternative guide](/easydmarc-dmarc-alternative) ## Frequently asked questions ### Is Valimail or EasyDMARC automatically cheaper? No. A lower apparent starting price does not establish the cost for your domain inventory, users, contract terms, or required operating scope. Confirm each vendor's current first-party pricing and the unit that drives cost before deciding. ### Should I compare published prices without checking plan limits? No. A published price is useful only with the included limits and billing terms that apply to that plan. Record the exact limit, the expected usage, and any term that needs vendor confirmation. ### Can a DMARC checker tell me which vendor to buy? No. A DMARC checker can inspect the public record for a domain at the time of the lookup. It cannot establish platform pricing, contract terms, report-processing workflow, private support commitments, or future deliverability. ### Does a valid DMARC record prove that all senders are ready for enforcement? No. A valid public DMARC record does not show whether every production sender authenticates and aligns correctly. Validate DNS, vendor status, real delivered-message headers, and aggregate-report evidence before changing policy. ### Should an MSP use the same scorecard as an internal IT team? Yes. Both should compare current commercial terms, operating scope, limits, and open questions. An MSP should also confirm how the selected workflow and commercial model apply to separate customer domains and delegated administration. --- # Warmly email warmup: what the search term may mean Canonical: https://www.palisade.email/learning/warmly-email-warmup > Warmly email warmup is an ambiguous search term. It may refer to Warmy Email Warm-Up, but the spelling and intended workflow are not confirmed. "Warmly email warmup" is ambiguous. No verified product or workflow named "Warmly" is established by the available primary sources. The closest documented name is [Warmy's "Email Warm-Up" offering](https://warmy.io), but treating "Warmly" as a misspelling of "Warmy" is an inference, not a confirmed correction. Confirm the product name and the goal before connecting a sending inbox or changing mail settings. ## Quick takeaways - "Warmly" and "Warmy" are different spellings, and the available sources only document Warmy. - [Warmy](https://warmy.io) labels one offering "Email Warm-Up." - Warmy says it provides "real-time insights into email placement inbox, spam, or promotions." - Warmy also says its service prepares "domains and IPs" for outreach campaigns, which is vendor marketing language. - [Warmup Inbox](https://warmupinbox.com) describes a separate vendor workflow: connect an inbox, exchange messages in its network, then track deliverability. - Neither vendor page establishes a mailbox-provider-endorsed warm-up procedure, a universal sending schedule, or a guaranteed placement outcome. ## What "Warmly email warmup" can refer to The search term may be looking for a product with a similar name, or it may be asking about the general idea of warming up an email-sending inbox. Those are different questions. Warmy's public homepage calls its offering "Email Warm-Up." Its product page also states that it provides "real-time insights into email placement inbox, spam, or promotions," alongside deliverability, domain-reputation, and DNS-configuration metrics. That is a statement about Warmy's product, not evidence that a warm-up service changes a mailbox provider's placement decision. A different vendor, [Warmup Inbox](https://warmupinbox.com), describes its own service in three stated stages: - "Connect your sending inbox" - "Our network opens & replies" - "Track Deliverability" Those statements describe that vendor's workflow. They do not establish that all email warm-up products work the same way, that the process is effective for every sender, or that a receiver will place later messages in the inbox. For broader context on the signals involved in sending mail, see [email deliverability](/email-deliverability). Deliverability is a wider operational subject than the name or workflow of one warm-up service. ## When the answer changes Use the product name and the evidence you have to choose the next action. - If you meant **Warmy**, use Warmy's official site or support documentation to confirm the current setup path, prerequisites, and account-specific settings before connecting an inbox. - If you meant **Warmly** as an email-writing word, this is a writing-style question, not a documented email-deliverability workflow. - If you are evaluating a warm-up service generally, do not infer a universal procedure from either vendor's marketing page. - If you have a delivered production message, inspect its authentication results and the sending path before attributing placement changes to a warm-up service. - If you need to assess an AI-branded warm-up product, see [AI email warmup: what it is and what it cannot prove](/learning/ai-email-warmup). The practical decision rule is narrow: confirm the exact vendor first, then separate the vendor's reported metrics from evidence about your own production mail. ![Decision flow for an ambiguous Warmly email warmup search, from confirming the spelling to checking production mail evidence](/images/editorial/warmly-email-warmup/warmly-email-warmup-decision-rule.webp "1200x829") *Source: Palisade.* ## A worked evidence example A product page can support a statement about what that product says it offers. It cannot, on its own, prove an outcome for a particular sending domain. ```text Search term: warmly email warmup Confirmed product name: not yet confirmed Documented vendor statement: Warmy: "Email Warm-Up" Vendor-reported metric statement: "real-time insights into email placement inbox, spam, or promotions" What this does not establish: - A mailbox provider endorsed the workflow - A fixed warm-up volume or duration - Inbox placement for your production messages - A future delivery outcome ``` If the intended product is Warmy, the documented statement is that Warmy offers "Email Warm-Up." If the intended product is not Warmy, the evidence above does not identify it. A separate evidence object is needed before making operational decisions. A delivered message from the real production application can show authentication results for that message. DNS records can show what is published. Vendor status can show what the vendor reports. DMARC aggregate reports can later show observed authentication patterns across sending sources. These are different layers of evidence. > Do not connect a business-critical sending inbox or change DNS based only on a similarly named search result. Confirm the vendor, account, and intended sending path first. ## What to check next Start with the evidence closest to your question. If the question is "Which product did I mean?", confirm the exact spelling in the vendor account, contract, browser history, or internal request. Do not assume that Warmly means Warmy. If the question is "Is the sending domain ready for outreach?", inspect the domain's authentication and security baseline. Palisade's [email security score tool](/tools/email-security-score) can check public signals related to the domain's email-security posture. If the question is "Did a particular message authenticate?", use the delivered message's raw headers and compare them with the actual sending application. A public domain check cannot show the complete production path or a receiver's private placement decision. If the question is about another named service, use its official documentation. For a separate product-specific discussion, see [Apollo email warmup: what it does and what it cannot prove](/learning/apollo-email-warmup). ## Check the sending domain's public security baseline If the product name is confirmed but the unresolved question is the domain's public email-authentication posture, inspect that baseline before treating a vendor metric as a production result. [Check the email security score](/tools/email-security-score) A public score cannot prove inbox placement, verify a warm-up service's effect, show every production sender, or predict how a receiver will handle future mail. For ongoing DMARC work, Palisade is agentic DMARC software that analyzes aggregate-report data, identifies sending sources and authentication or alignment issues, and proposes a next policy step for human review. It does not control a receiver's private reputation decision or guarantee delivery. ## Sources and further reading - [Warmy homepage](https://warmy.io) - [Warmup Inbox homepage](https://warmupinbox.com) - [Palisade email security score](/tools/email-security-score) - [Palisade email deliverability guide](/email-deliverability) ## Frequently asked questions ### Is warmly a good email closing? "Warmly" is a sign-off, so whether it fits depends on your relationship with the recipient and how formal the message is. That is a writing question rather than a deliverability one, and this page covers email warm-up instead. If you meant the sending process, the answer below explains how warm-up services work. ### How do you warm up an email? You connect a sending inbox to a warm-up service, which then exchanges messages with other mailboxes in its network and reports what it observes. [Warmup Inbox](https://warmupinbox.com) describes exactly that sequence: connect your sending inbox, its network opens and replies, then track deliverability. [Warmy](https://warmy.io) calls its own offering "Email Warm-Up." No mailbox provider endorses a universal procedure, so treat each vendor's version as its own product rather than a standard. ### Is Warmly the same as Warmy? They are spelled differently, and the documented product is Warmy, without the "l." Reading "Warmly" as "Warmy" is a reasonable guess rather than a confirmed correction. Check the spelling in your account, contract, or internal request before you connect an inbox or follow setup instructions. --- # What causes an email to bounce? Canonical: https://www.palisade.email/learning/what-causes-an-email-to-bounce > What causes an email to bounce? Preserve the bounce evidence, validate undeliverable addresses, correct list data, and retest the same path. An email can bounce when the sending list includes an address that is invalid or undeliverable. Start with the returned message and preserve its exact text, then determine whether the recipient address exists and is suitable for sending. Address validation can prevent avoidable list-data failures, but it cannot prove that a receiver will accept a particular future message or place it in the inbox. For broader incidents, use the [delivery errors learning hub](/learning/delivery-errors). ## Quick takeaways - A bounce is evidence from a delivery attempt, so retain the original return or rejection text before changing data. - An address-validation service can identify addresses it classifies as invalid, undeliverable, risky, or unknown. - Validation workflows may check syntax, the domain, MX and DNS records, and mailbox availability. - Remove addresses identified as invalid or high risk before sending another campaign. - A validation result does not prove receiver acceptance, inbox placement, or the cause of every bounce. - Retest with the same sending path after correcting the recipient data. ## What does the failure mean? For this article's address-related diagnostic path, the observable failure is a message sent to an address that does not exist or cannot be classified as deliverable. Mailgun identifies this as a list-quality problem when organizations are [sending to addresses that don't exist](https://www.mailgun.com/products/validate/). ```text sending to addresses that don't exist. ``` That phrase identifies an address-related risk. It does not identify the meaning of every SMTP response, whether a receiver treated the failure as temporary or permanent, or whether the domain's authentication settings caused a separate rejection. Keep the original non-delivery report, SMTP response, or ESP event with the affected recipient record. Do not rewrite the provider's wording in an incident ticket. The exact text, timestamp, sending application, recipient domain, and sending list identify the delivery attempt that needs investigation. An address-validation result is useful before a resend because [Verifalia classifies addresses as Deliverable, Undeliverable, Risky, or Unknown](https://verifalia.com/). That classification is not a receiver promise. A mailbox can change after a check, and the available validation evidence does not establish why a receiver accepted or rejected one specific message. ![Diagnostic flow showing preservation of bounce evidence, recipient address validation, correction of list data, and same-path retesting](/images/editorial/what-causes-an-email-to-bounce/what-causes-an-email-to-bounce-diagnostic-flow.webp "1200x829") *Source: Palisade.* ## What usually causes it? ### The recipient address is invalid or undeliverable An invalid or undeliverable address is the clearest documented cause in the available evidence. Verifalia states that its service identifies "invalid and undeliverable emails" and returns an address classification. If the affected contact is classified as undeliverable, do not keep sending to that address until the contact supplies a corrected one. This conclusion applies to the recipient address. It does not establish that every bounced message has an invalid recipient, because receiver responses can reflect other conditions that require their own authoritative documentation. ### The sending list contains stale contact data A list can retain an address after a person changes jobs, an organization retires a mailbox, or a form captures a typo. The evidence supports checking the actual address before the next send, rather than assuming the rest of the list has the same problem. Mailgun describes validation as a way to [remove invalid and high-risk addresses](https://www.mailgun.com/products/validate/). Treat that as a targeted list-hygiene action. Do not infer that one invalid result proves the whole list is poor quality. ### The address has a risky or unknown validation result A validation result is not always a clear yes or no. Verifalia documents classifications that include Risky and Unknown alongside Deliverable and Undeliverable. Those outcomes call for a sending decision that matches the organization's consent, risk, and contact-management policy. Do not relabel a risky or unknown result as a bounce cause. It is a classification that needs review. The available evidence does not support a universal rule for suppressing every risky or unknown address. ### The validation check has not covered the address before sending A list may be sent without recent validation, leaving invalid and high-risk addresses in the audience. Verifalia describes a workflow with: ```text Syntax validation, domain / MX / DNS check, mailbox availability check ``` Those checks can identify address problems before a campaign goes out. They do not inspect a specific received bounce message, prove the production sender configuration, or guarantee delivery. ![Email validation checklist covering syntax, domain, MX and DNS, and mailbox availability checks](/images/editorial/what-causes-an-email-to-bounce/what-causes-an-email-to-bounce-diagnostic-flow.webp "1200x630") *Source: Palisade.* For issues beyond recipient data, compare the original evidence with the related guidance on [bounce email address diagnosis](/learning/bounce-email-address). Do not assign a general cause from the address alone. ## How do I diagnose the failure? ### 1. Preserve the returned-message evidence Save the full bounce message, non-delivery report, or event record before editing the contact. Record the affected recipient address, the date and time, the sending application, and the list or workflow that used the address. Keep the original wording intact. A return message may contain receiver-specific information, and the available evidence does not provide a standard mapping from bounce strings to causes. The [email deliverability guide](/email-deliverability) provides broader context, but list validation remains a separate check. ### 2. Confirm the exact address that was sent Compare the address in the sending event with the address stored in the CRM, ESP, form submission, or source system. Look for data-entry errors and accidental changes to the contact record. Do not replace the address based on a guess. Ask the contact for a corrected address when practical, or use an approved validation workflow to classify the existing address. ### 3. Validate the address before another send Use an email-address validation service that checks the address before it re-enters a campaign. Verifalia describes checks for syntax, domain, MX and DNS, and mailbox availability, then returns an address classification. Record the outcome alongside the original bounce evidence. A useful incident note distinguishes the observed return message from the later validation result. They are related evidence, but neither one automatically explains every possible receiver decision. ### 4. Separate recipient-data findings from sender-configuration questions If validation identifies the address as invalid or undeliverable, the narrow repair is to correct or remove that address from the sending list. If validation does not establish an address problem, do not force the incident into this category. Authentication and sender-domain configuration can affect the broader security posture of a sending domain. They still do not explain a single receiver's bounce text without message and receiver evidence. Use a provider's own logs or dashboard for a receiver-controlled decision. ### 5. Record the retest path Before resending, record the application, sending domain, recipient address, list segment, and message version. This makes the retest comparable with the failed attempt. A different campaign, different recipient, or different sender route cannot prove that the original failure is resolved. Use the same approved production path when possible. ## How do I fix it? ### Correct an invalid recipient address When validation identifies an address as invalid or undeliverable, replace it only with an address obtained through an approved contact update. If no corrected address is available, remove the invalid address from the active sending list. This repair changes contact data. It does not change DMARC, SPF, DKIM, receiver policy, or the receiver's inbox decision. > Do not repeatedly resend to an address classified as invalid or undeliverable while waiting for a different result. Repeated attempts do not correct the stored contact data. ### Remove invalid and high-risk addresses before the next send Mailgun states that validation can remove invalid and high-risk addresses. Apply that action to the affected list under the organization's retention and consent rules. Keep an audit record of why the contact was removed or suppressed. Do not delete every bounced contact automatically. The available evidence supports removing invalid and high-risk addresses after validation, not a universal deletion rule for all bounce events. ### Recollect the address through a controlled update If the address came from a form, import, or manual entry, correct the source process after confirming the data issue. Use confirmation or validation controls appropriate to that intake path. This repair reduces recurrence from the same data source. It does not prove that other contacts, domains, or campaigns will not bounce for unrelated reasons. ### Escalate evidence that is not address-related When the address is not classified as invalid or undeliverable, preserve the original evidence and investigate through the sending platform or receiving provider's documented path. The [Outlook bounce-back email guide](/learning/bounce-back-email-outlook) can help when the returned message is specific to Outlook. Do not loosen a DMARC policy as a response to an unclassified bounce. A DMARC policy changes requested authentication enforcement. It does not correct recipient data or explain an individual receiver response. ## How do I validate the repair? Send a new message through the same application and sender path to the corrected, confirmed recipient address. Retain the resulting event record with the original incident. Validate each applicable layer: - Check the recipient data in the source system and confirm that the address was corrected or removed. - Check the validation result and retain its Deliverable, Undeliverable, Risky, or Unknown classification. - Check the delivered message or returned message from the same sending path. - Check DMARC aggregate-report data after it accumulates if the sending domain also needs authentication monitoring. A successful validation check is not enough by itself. It does not prove that the production system used the intended address, that a receiver accepted the message, or that future messages will be delivered. ## Check the sending domain after fixing list data After correcting an address-related bounce, inspect the sending domain's broader email-security posture with the [email security score tool](/tools/email-security-score). This can help identify domain-level authentication configuration worth reviewing alongside list hygiene. [Check the sending domain's email security score](/tools/email-security-score) An email-security score cannot interpret one receiver's bounce text, validate an individual mailbox, prove the production sending path, or guarantee future delivery. For ongoing DMARC aggregate-report analysis, Palisade can identify sending sources and authentication or alignment issues, then create prioritized remediation tickets. A human reviews the evidence and applies any change. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=email_deliverability&utm_content=what-causes-an-email-to-bounce) ## Sources and further reading - [Verifalia email validation](https://verifalia.com/) - [Mailgun email validation](https://www.mailgun.com/products/validate/) - [Palisade email security score tool](/tools/email-security-score) ## Frequently asked questions ### How do I stop my emails from bouncing? Validate your mailing list before each send and remove every address classified as invalid, undeliverable, or high risk. A validation service checks syntax, the domain, MX and DNS records, and mailbox availability, which catches the list-data problems behind avoidable bounces. It will not stop a bounce that comes from a receiver's own filtering or policy decision. ### How do you fix a bounced email? Preserve the exact return message, then validate the recipient address that failed. If the address is classified as invalid or undeliverable, correct it through an approved contact update or remove it from the active list. If the bounce text points at something other than the address, keep the original message and investigate through the sending platform or the receiving provider. ### Why am I getting bounced emails that I didn't send? There is no single cause you can read off the situation, so the returned message is where the answer lives. Keep the original bounce with its full headers, then investigate through the provider that generated it. Do not change your sender settings or contact records until that evidence shows which system sent the original mail. ### Should you delete bounced emails? Do not delete every bounced contact automatically. Remove the addresses that validation classifies as invalid or high risk, and keep an audit record of why each one was removed or suppressed. A single bounce event is not by itself a reason to delete a contact. ### Can email validation guarantee delivery? No, because validation tells you about the address, not about the receiver. It classifies the address and can check syntax, the domain, MX and DNS records, and mailbox availability. It cannot promise that a receiver will accept a future message or place it in the inbox. --- # What is SPF? Sender Policy Framework explained Canonical: https://www.palisade.email/learning/what-is-spf > What is SPF? Sender Policy Framework is a DNS record that authorizes mail servers for a domain's envelope sender or HELO identity for a domain. SPF, or Sender Policy Framework, is an email-authentication method that lets a domain publish the mail servers authorized to use that domain in an SMTP envelope sender (`MAIL FROM`) or HELO identity. Receiving servers compare the connecting sender against that DNS policy. An SPF pass does not, by itself, prove that the domain shown in the visible From address is authorized for DMARC. ## Quick takeaways - SPF publishes sender authorization in a DNS TXT record. - SPF evaluates the SMTP `MAIL FROM` identity when it is available, otherwise the HELO identity. - A passing SPF result can use a different domain than the visible From address. - DMARC requires an SPF pass with an identity aligned to the visible From domain, or an aligned DKIM pass. - SPF records can cause a permanent error if evaluation needs more than 10 DNS lookups. - A public SPF lookup shows the record currently published in DNS, not the exact path a production message used. ## How SPF authorization works [RFC 7208 defines SPF](https://www.rfc-editor.org/rfc/rfc7208.html) as a way for a domain owner to publish which hosts may send mail using a particular identity. The policy is normally a DNS TXT record. A receiving mail system evaluates that record against the IP address that connected to it. The identity SPF checks is important. For normal SMTP mail, SPF checks the domain in the envelope sender, also called `MAIL FROM`. If the message has an empty envelope sender, such as a delivery-status notification, SPF uses the HELO or EHLO domain instead. SPF does not authenticate the domain a person sees in the message's From header. A receiving system can record this result in the `Authentication-Results` header. [RFC 8601 defines that header field](https://www.rfc-editor.org/rfc/rfc8601.html), including SPF result properties such as `smtp.mailfrom` and `smtp.helo`. Those properties show the identity the receiver evaluated. They are more useful than assuming SPF checked the visible From domain. An SPF record can authorize sources directly with mechanisms such as `ip4` and `ip6`, or delegate evaluation to another domain with `include`. The [SPF `all` mechanism](/learning/spf-all-mechanism) determines what happens when no earlier mechanism matches. For a term-by-term walkthrough, read [SPF record syntax, mechanisms, and qualifiers](/learning/spf-record-syntax-explained-mechanisms-qualifiers). ## When an SPF pass counts for DMARC An SPF pass is an authorization result. DMARC adds an alignment test. The [DMARC specification](https://www.rfc-editor.org/rfc/rfc9989.html#section-3) requires the domain that passed SPF to align with the visible From domain before SPF can produce a DMARC pass. In relaxed alignment, related organizational domains can align. In strict alignment, the domains must match exactly. Use this decision rule: - If SPF passes for `bounce.mailer.example.net` and the visible From domain is `example.net`, SPF may be DMARC-aligned under relaxed alignment. - If SPF passes for `mailer.example.net` and the visible From domain is `yourdomain.com`, SPF passes but does not align for DMARC. - If SPF fails, DMARC can still pass through an aligned DKIM result. - If neither SPF nor DKIM produces an aligned pass, the message fails DMARC. This distinction matters when investigating an [email rejected per DMARC policy](/learning/email-rejected-per-dmarc-policy) bounce. A passing SPF result does not rule out a DMARC failure. Check the domain attached to `smtp.mailfrom`, then compare it with the visible From domain. ![Decision flow showing SPF identity evaluation and the separate DMARC alignment check against the visible From domain](/images/editorial/what-is-spf/what-is-spf-identity-flow.webp "1200x829") *Source: Palisade.* ## Worked SPF identity example This illustrative record authorizes one IPv4 address and delegates another set of authorized senders to a provider-managed policy. ```text yourdomain.com. TXT "v=spf1 ip4:192.0.2.25 include:spf.sender.example ~all" ``` Do not copy this record into production. Your email providers generate or document the real include domains, IP addresses, and required mechanisms. If a message arrives from `192.0.2.25` with these identities: ```text From: Billing <billing@yourdomain.com> MAIL FROM:<bounce@yourdomain.com> ``` SPF can pass because the envelope sender domain is `yourdomain.com` and the connecting IP matches `ip4:192.0.2.25`. SPF also aligns with the visible From domain, so it can support a DMARC pass. Now change only the envelope sender: ```text From: Billing <billing@yourdomain.com> MAIL FROM:<bounce@sender.example> ``` SPF may pass for `sender.example`, depending on that domain's record. It does not align with `yourdomain.com`, so SPF cannot satisfy DMARC for this message. An aligned DKIM pass could still satisfy DMARC. SPF evaluation also has a hard DNS-query limit. [RFC 7208 section 4.6.4](https://www.rfc-editor.org/rfc/rfc7208.html#section-4.6.4) requires SPF evaluators to stop and return `permerror` after more than 10 DNS-query-causing terms or mechanisms. Nested `include`, `redirect`, `a`, `mx`, `exists`, and `ptr` mechanisms can contribute to that limit. A record that looks short can still exceed it through nested includes. ## Check SPF with the evidence you have Start with the evidence closest to the question you need answered. - If you have a domain name, inspect its public TXT record and identify every `include`, IP range, and final `all` mechanism. The [SPF learning hub](/learning/spf) covers the related concepts in more depth. - If you have a delivered message, inspect its `Authentication-Results` header. Confirm whether the receiver reported `spf=pass`, `spf=fail`, or another result, and read the `smtp.mailfrom` or `smtp.helo` property. - If you are changing a sender, test mail from that exact production path after DNS is published. A correct record alone does not prove the application uses the envelope sender you expected. - If you operate DMARC, use aggregate reports after mail has flowed to identify sources and alignment outcomes over time. For a record that is close to the SPF lookup limit, or changes frequently under controlled sender-management processes, [Palisade Hosted SPF](https://docs.palisade.email/page-breakdowns/hosted-spf/) is an optional way to delegate SPF record management behind one include. It does not discover legitimate senders or make the authorization decision for you. The operator must copy and verify every legitimate include, IP address, and mechanism before publishing a change, then validate mail from each real sending path. ## Inspect the SPF record your domain publishes Run the sending domain through Palisade's SPF checker to inspect the public record before you edit its syntax or add another include. If the record is becoming difficult to maintain, the remaining operational question is whether every authorized source is still intentional and aligned with your visible From domains. [Check the published SPF record](/tools/spf) A public-record check cannot prove the envelope sender used by an individual message, identify every production sender, monitor later changes, or guarantee delivery or inbox placement. For teams that need to review SPF and DMARC evidence across active domains, [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=email_authentication&utm_content=what-is-spf). Palisade's DMARC Agent analyzes aggregate-report data, identifies authentication and alignment issues, and proposes prioritized remediation work for human review. It does not automatically change your DNS or DMARC policy, and it cannot guarantee that future messages will authenticate or reach the inbox. [Palisade documentation](https://docs.palisade.email/) describes the managed workflow. ## Sources and further reading - [RFC 7208: Sender Policy Framework](https://www.rfc-editor.org/rfc/rfc7208.html) - [RFC 8601: Authentication-Results header field](https://www.rfc-editor.org/rfc/rfc8601.html) - [RFC 9989: Domain-based Message Authentication, Reporting, and Conformance](https://www.rfc-editor.org/rfc/rfc9989.html) - [Palisade SPF checker](/tools/spf) ## Frequently asked questions ### Is SPF the same as DMARC? No. SPF authorizes sending hosts for an envelope sender or HELO identity. DMARC evaluates whether SPF or DKIM passed with a domain aligned to the visible From domain, then applies the domain owner's requested policy when DMARC fails. ### Does SPF check the visible From address? No. SPF checks the SMTP `MAIL FROM` identity when present, or the HELO identity for mail with an empty envelope sender. The visible From address is evaluated separately by DMARC alignment. ### Can a message pass SPF and fail DMARC? Yes. SPF can pass for a domain that does not align with the visible From domain. The message can still pass DMARC if DKIM passes with an aligned domain. Otherwise, it fails DMARC. ### What does `-all` mean in an SPF record? It means the domain owner states that senders not matched by an earlier mechanism are unauthorized. It does not guarantee that every receiver will make the same final delivery decision. Publish it on a domain that sends no mail; a domain that does send should end in `~all`, which [SPF hard fail versus softfail](/learning/spf-hardfail-vs-softfail) explains. ### How many DNS lookups can SPF use? RFC 7208 limits SPF evaluation to 10 DNS-query-causing terms or mechanisms. Exceeding that limit produces a permanent SPF error, often shown as `permerror`. ### Does an SPF pass guarantee inbox placement? No. An SPF pass only reports authorization for the SPF identity. Receiving systems can also consider DMARC, DKIM, reputation, content, user signals, and local policy. --- # Which domain reputation statement is correct? Canonical: https://www.palisade.email/learning/which-of-the-following-statements-about-domain-reputation-is-correct > Which statement about domain reputation is correct? It reflects observed harmful activity and can change as internet activity changes over time. The correct statement is that domain reputation is evidence about a domain's observed association with harmful activity, such as spam-related or malicious activity, and it can change over time. It is not a permanent label or a universal score that predicts one fixed email outcome. [Spamhaus](https://spamhaus.org) publishes IP and domain reputation data and notes that internet traffic and adversary activity change daily. ## Quick takeaways - Domain reputation data can relate to spam-related and malicious domain activity. - A reputation result is a current signal to investigate, not a permanent verdict. - Daily reputation statistics can fluctuate as internet activity changes. - A blocklist or reputation result does not document how a specific mailbox provider will handle a message. - No universal score, threshold, or recovery period applies to every domain. - Reputation investigation is one part of the broader [email deliverability](/email-deliverability) picture. ## How domain reputation works Domain reputation is a category of data about a domain's observed activity or association with harmful activity. [Spamhaus describes its data as IP and domain reputation](https://spamhaus.org) and publishes statistics for both spam-related domains and malicious domains. That definition has an important limit. The available public information does not establish one vendor-neutral formula that every reputation service, security product, or mailbox provider uses. It also does not establish that a reputation result causes acceptance, spam-folder placement, or rejection at a particular provider. Spamhaus states: "Global internet traffic changes daily, as do the activities of adversaries." It also states that its statistics are daily-average indicators and that actual daily figures fluctuate. Those statements support a practical interpretation: reputation data reflects changing observations, rather than an irreversible property attached to a domain. For a broader explanation of the term, see [what a domain reputation is](/learning/what-is-a-domain-reputation). This page answers the narrower question of which statement is safe to treat as correct. ![Decision flow showing that a current domain reputation result should lead to investigation rather than a permanent conclusion](/images/editorial/which-of-the-following-statements-about-domain-reputation-is-correct/which-of-the-following-statements-about-domain-reputation-is-correct-decision-flow.webp "1200x676") *Source: Palisade.* ## When the answer changes The answer changes when a statement claims more certainty than the available evidence supports. Treat these statements differently: - Correct: domain reputation data can concern a domain's association with spam-related or malicious activity. - Correct: domain-related activity can change, so reputation data is not necessarily static. - Correct as an inference: a current reputation result should prompt investigation rather than a permanent conclusion. - Unverified: every provider uses the same domain reputation score or threshold. - Unverified: a poor result guarantees rejection, spam placement, or another specific mailbox-provider decision. - Unverified: every domain improves after a fixed number of days. A usable decision rule is: if a reputation or blocklist check returns a result, preserve the result and its check time, then investigate the evidence available for that domain. Do not convert the result into a claim about all future traffic or every receiver's private decision. Spamhaus offers a Domain Blocklist and a Reputation Checker, but its public homepage does not document how a mailbox provider uses those resources in delivery decisions. That gap matters when investigating reputation as part of [deliverability work](/email-deliverability): a public check can identify a signal, but it cannot reveal a receiver's internal filtering logic. ## A worked decision example Suppose a domain check returns a result associated with harmful domain activity. The correct operational conclusion is not "the domain can never send email successfully." The correct conclusion is that there is evidence worth reviewing. ```text Domain checked: yourdomain.com Observed result: reputation or blocklist signal Check time: 2026-08-13T12:00:00Z Decision: investigate the current signal Do not conclude: permanent reputation status or provider-specific delivery outcome ``` This is a record of what the check showed at one time. It does not establish why the result exists, which activity caused it, whether an individual message will be accepted, or how long the result may remain relevant. If the concern is a Spamhaus listing, use a focused [Spamhaus blacklist check guide](/learning/check-spamhaus-blacklist) for that investigation. Keep the scope narrow. A domain reputation result and a message-delivery diagnosis are related topics, but they are not interchangeable evidence. ## What to do next with the evidence you have Start with the type of evidence available: - If you have only a domain name, run a [domain reputation check](/tools/domain-reputation) to inspect current public reputation evidence. - If you have a blocklist result, record the domain, the result, and when you checked it. Then use the relevant provider or blocklist operator's published process to investigate that specific result. - If you have a delivery problem, collect evidence from the exact sending path and the receiving provider where possible. A public reputation lookup alone does not explain the provider's decision. - If you need to understand delivery outcomes more broadly, separate reputation signals from authentication results, message content, and receiver-specific policy. A domain check is a point-in-time diagnostic. It cannot prove the production sending path, monitor later changes, reveal a receiver's private reputation decision, or guarantee future inbox placement. ## Investigate recurring domain reputation signals A one-time result can identify current public evidence, but it does not show which sending sources create ongoing authentication or alignment issues across a domain portfolio. Palisade is agentic DMARC software that analyzes DMARC aggregate-report data, identifies sending sources and authentication or alignment issues, and creates prioritized remediation tickets. A human reviews the evidence and applies any change. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=email_deliverability&utm_content=which-of-the-following-statements-about-domain-reputation-is-correct) Palisade does not change a receiver's private reputation decision, delist an IP, guarantee delivery, or prove that every future message will authenticate. ## Sources and further reading - [Spamhaus IP and domain reputation information](https://spamhaus.org) - [Palisade domain reputation check](/tools/domain-reputation) - [What is a domain reputation?](/learning/what-is-a-domain-reputation) - [Email deliverability guide](/email-deliverability) ## Frequently asked questions ### What is domain reputation in cyber security? Domain reputation in cyber security is data about a domain's observed association with harmful activity, such as spam or malicious behavior. [Spamhaus](https://spamhaus.org) publishes this kind of data as IP and domain reputation and reports on both categories. Because it reflects recent observations, the data can change. ### What is poor reputation of a domain used in message transfer? A poor reputation for a domain used in message transfer means reputation data links that domain to spam or malicious activity. It describes observed behavior at a point in time, not a fixed property of the domain. Mailbox providers do not publish how they use that signal in a delivery decision, so a poor result does not tell you what will happen to a specific message. ### Why is my domain reputation bad? No public checker publishes the reason behind an individual domain's result, so you have to work it out from evidence you collect. Run a [domain reputation check](/tools/domain-reputation) and record the result along with the time you ran it. If the domain appears on a blocklist, follow that operator's published process, which is the documented route to the reason for that listing. ### Does a domain reputation check prove inbox placement? No, because a reputation check reports public evidence about a domain rather than a mailbox provider's private decision. It shows what a checker recorded at the moment you ran it. It cannot tell you where a future message will land. --- # Why emails go to spam instead of inbox Gmail Canonical: https://www.palisade.email/learning/why-emails-go-to-spam-instead-of-inbox-gmail > Why emails go to spam instead of inbox Gmail: the Spam folder alone cannot identify the cause. Use message and sender evidence to investigate. A Gmail message in Spam instead of Inbox does not, by itself, identify why Gmail made that placement decision. The useful answer comes from evidence tied to the affected message and sending path, not from the folder alone. Separate a one-message placement issue from a broader sending problem, retain the message evidence, and check whether Google reports a service outage before treating the event as a sender-side fault. ## Quick takeaways - A message in Gmail Spam is evidence of placement, not evidence of one specific technical cause. - The same visible symptom can require different evidence for a recipient-side issue and a sender-side issue. - A single public DNS result cannot prove the authentication state of the production message that reached Gmail. - A delivered message's headers can preserve evidence that a public record lookup cannot show. - Google directs users with product-access problems to the Google Workspace Status Dashboard for outage and downtime information. - Broader [email deliverability](/email-deliverability) work requires evidence from the real sending path. ## Why the Spam folder does not explain the cause The Gmail Spam folder tells you where a message was placed. It does not expose a complete, universal explanation for that placement. Treat the folder location as the beginning of an investigation. The first decision is whether the observation concerns a recipient's mailbox or mail sent by an organization. A recipient who sees one wanted message in Spam has a mailbox-level question. A sender who sees messages from a production domain reach Spam has a sending-path question. Those are different problems, and neither should be reduced to an assumption based only on the Spam label. This distinction matters because the available evidence changes with the question. A sender can retain the message, inspect the sending configuration, and compare results across recipients or campaigns. A recipient may only have the message and Gmail's mailbox controls. The evidence must match the claim you want to make. Use this rule: > Do not name a cause for Gmail Spam placement until you can connect a specific message, its sending path, and the evidence available for that path. That is an operational inference, not a published Gmail classification rule. It prevents a common error: treating a visible outcome as proof that one particular record, service, or message property caused it. For broader context on the evidence that affects inbox-placement investigations, see the [email deliverability guide](/email-deliverability). ![Decision flow for separating a Gmail Spam observation from the evidence needed to investigate the affected message or sending path](/images/editorial/why-emails-go-to-spam-instead-of-inbox-gmail/why-emails-go-to-spam-instead-of-inbox-gmail-evidence-flow.webp "1200x829") *Source: Palisade.* ## When the answer changes The right next action changes with the evidence you have. If you are a Gmail recipient and the issue appears to be access to Gmail or another Google product, first check the [Google Workspace Status Dashboard guidance](https://support.google.com) for reported outages and downtime. An outage check can help distinguish a product-access issue from a message-placement investigation. It does not explain why an individual email appeared in Spam. If you are responsible for sending the message, preserve the exact message and identify the production path that produced it. Do not substitute a different test email, a marketing preview, or a public DNS lookup for the message that was actually placed in Spam. Those checks can still be useful, but they answer narrower questions. If the issue affects a newsletter, use the evidence from that campaign and compare it with the broader discussion in [why newsletters go to spam](/learning/email-questions/why-are-my-newsletters-going-to-spam). If it concerns a Mailchimp message, the adjacent [Mailchimp spam-placement guide](/learning/email-questions/mailchimp-emails-going-to-spam) is a more specific starting point. A provider-specific symptom is not proof that the same cause applies to Gmail. If a message reaches Gmail Inbox but has different placement at another mailbox provider, do not treat one provider's result as a verdict for the other. See [why email goes to spam in Outlook but not Gmail](/learning/why-is-my-email-going-to-spam-in-outlook-but-not-gmail) for that separate comparison. ## A worked evidence record for a Gmail Spam report Record the observation before making configuration changes. The following is an illustrative incident note, not a Gmail header or a documented Gmail diagnostic format. ```text Incident: Message appeared in Gmail Spam instead of Inbox Affected mailbox: recipient@yourdomain.com Message identifier: retain the message-specific identifier Observed time: 2026-08-13T12:00:00Z Sender visible From domain: yourdomain.com Sending application: identify the actual production application Evidence retained: original message and available headers Scope: one message, one recipient, or repeated placement Google service status checked: yes or no ``` This record keeps the observation separate from an explanation. It also makes later comparison possible. For example, if multiple messages from the same production application show the same result, retain examples from that exact path. If only one message is affected, record that limitation instead of asserting a broad sending problem. Avoid publishing or sharing unredacted message content, recipient addresses, private headers, credentials, or account-generated values. Use redacted copies when an internal team needs help reviewing the issue. ## What to do next with the evidence you have Start with the evidence closest to the observed problem. - If Gmail access itself seems disrupted, check the [Google Workspace Status Dashboard guidance](https://support.google.com). This addresses reported product outages and downtime, not Spam classification. - If you are investigating a single message, preserve the original message and its available headers before moving or deleting it. - If you send from a domain or multiple applications, document which production application sent each affected message. A public DNS result cannot prove that the application used the expected authentication path for that message. - If the issue is recurring, compare the affected messages with messages from the same sender that reached the Inbox. Keep the comparison scoped to the same production path. - If you need a wider framework for the work, use the deliverability learning hub to choose the next topic based on the evidence you have. Do not change DNS, sender settings, or mailbox rules solely because one message appeared in Spam. First establish what changed, what message path was involved, and what evidence can support a proposed change. ## Check the domain's visible security posture If you administer the sending domain, use Palisade's [Email Security Score tool](/tools/email-security-score) as a domain-level starting point before deciding what to investigate next. Compare any public result with the affected message and the actual production sender. [Check your domain's Email Security Score](/tools/email-security-score) A domain-level check cannot prove why Gmail placed one message in Spam, inspect Gmail's private placement decision, or confirm the state of every production sending path. For an ongoing DMARC investigation across one or more domains, [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=email_deliverability&utm_content=why-emails-go-to-spam-instead-of-inbox-gmail). Palisade analyzes DMARC aggregate-report data, identifies sending sources and authentication or alignment issues, and creates prioritized remediation tickets. A human reviews the evidence and applies any policy change. This does not control Gmail's private inbox-placement decision or guarantee inbox placement. ## Sources and further reading - [Google Help: Google Workspace Status Dashboard guidance](https://support.google.com) - [Palisade Email Security Score tool](/tools/email-security-score) - [Palisade email deliverability guide](/email-deliverability) ## Frequently asked questions ### How do I stop my Gmail emails from going to spam? Start with the message that actually landed in Spam: keep it, open its full headers, and work out which application really sent it. Check that SPF and DKIM pass and align with the domain in your From address on that exact path, then compare a message that reached the inbox with one that did not. Gmail never publishes its reason for a single placement, so build the case from evidence on your own side. ### How do I get my Gmail inbox back to normal? Check the Google Workspace Status Dashboard first if Gmail itself looks broken or unreachable, because Google reports outages and downtime there. If mail is arriving but landing in the wrong folder, that is a placement question instead, so keep the affected message and investigate the sending path. Do not change sender settings for what turns out to be an outage. ### How do I change emails from spam to inbox? If you are the recipient, open the message in Spam and mark it as not spam with Gmail's own control, which moves it and trains your own mailbox. If you are the sender, there is no switch to flip: you have to find and fix whatever failed on the sending path. Keep the original message either way, because its headers are the only hard evidence you have. ### Why are my emails going to spam instead of inbox? Gmail judged that message to look more like spam than wanted mail, and it does not publish its reason for any single placement. The usual places to look are authentication that fails or does not align with your From domain, a sending application nobody accounted for, and recipients who never asked for the mail. Narrow it down with the affected message, its headers, and whether the problem hits one recipient or many. ### Can a public domain check prove Gmail will place messages in the Inbox? No, because a domain check reads public DNS and nothing else. It cannot see your production sending path, Gmail's private decision, or what happens to your next message. It is a good way to spot a missing or broken record, not a placement forecast. --- # Woodpecker email warmup Canonical: https://www.palisade.email/learning/woodpecker-email-warmup > Woodpecker email warmup is a free feature Woodpecker says automatically builds sender reputation. Learn what it covers and what to check separately. Yes. Woodpecker offers "Free warm-up" and says the feature "Automatically builds your sender reputation." Woodpecker also presents warm-up alongside email verification, deliverability monitoring, and adaptive sending. That means warm-up is one part of its outbound deliverability offering, not documented proof that a mailbox is authenticated correctly, ready for a campaign, or guaranteed to reach a recipient's primary inbox. ## Quick takeaways - [Woodpecker lists "Free warm-up" as a product feature](https://woodpecker.co). - Woodpecker says its warm-up automatically builds sender reputation. - Woodpecker says users can connect, buy, or warm up domains and mailboxes before running campaigns. - Warm-up and SPF, DKIM, and DMARC are separate deliverability capabilities. - Woodpecker's public site does not document a warm-up schedule, sending volume, or readiness threshold. - A warm-up feature cannot prove future inbox placement at a particular mailbox provider. ## How Woodpecker email warmup fits into deliverability [Woodpecker's product site](https://woodpecker.co) groups warm-up with features intended to help cold email reach inboxes rather than spam folders. The same feature area names free email verification, Deliverability Monitor, and Adaptive Sending. Woodpecker describes the purpose of its free warm-up in a short, specific way: "Automatically builds your sender reputation." Sender reputation is relevant to the wider subject of [email deliverability](/email-deliverability), but warm-up is not the whole delivery path. A receiver can use its own reputation signals and local policies when handling a message. Woodpecker also says users can "Connect, buy or warm up domains/mailboxes" before launching cold-email and LinkedIn campaigns. The public claim supports the availability of warm-up for domains or mailboxes in Woodpecker. It does not establish how Woodpecker activates the feature, how many messages it sends, which mailboxes participate, or when a mailbox is ready for production outreach. ![Decision flow showing that Woodpecker warm-up and email authentication need separate checks before campaign sending](/images/editorial/woodpecker-email-warmup/woodpecker-email-warmup-decision-flow.webp "1200x829") *Source: Palisade.* For broader context on warm-up limits, see [AI email warmup: what it is and what it cannot prove](/learning/ai-email-warmup). ## When warm-up is not enough The answer changes when the question is about authentication rather than reputation. Woodpecker separately advertises domains and email addresses available for purchase with "SPF, DKIM and DMARC pre-configured." [Woodpecker's domain offering](https://woodpecker.co) limits that statement to domains and emails bought through Woodpecker. It does not say that every externally connected mailbox has those controls configured. The practical decision rule is: - If you want to know whether Woodpecker offers warm-up, its public product page answers yes. - If you want to know whether your specific sending mailbox is authenticated, inspect that mailbox's actual domain configuration separately. - If you want to know whether a real campaign message authenticated, check a delivered message from the exact production sending path. - If you want to know whether your sending sources remain aligned over time, review DMARC aggregate-report data after it accumulates. This distinction matters because a warm-up feature and technical authentication address different parts of the outbound-mail problem. A mailbox may be warmed up while its domain configuration still needs review. Conversely, a domain with SPF, DKIM, and DMARC configured does not receive a documented inbox-placement guarantee from that configuration alone. > Do not treat a positive warm-up status as proof that a production message will authenticate or reach a recipient's inbox. Validate the exact mailbox, domain, and sending path before increasing campaign activity. Woodpecker's public site does not document a warm-up volume, ramp schedule, reply behavior, pause condition, or estimated readiness time. Use any account-specific controls only according to current Woodpecker documentation or support guidance. ## A worked evaluation example Consider a team that has connected `sales.yourdomain.com` to Woodpecker and sees that warm-up is available. The available evidence supports this evaluation: ```text Mailbox: outreach@sales.yourdomain.com Question: Does Woodpecker offer warm-up? Answer: Yes, Woodpecker publicly lists "Free warm-up." Question: Does warm-up prove SPF, DKIM, and DMARC are configured? Answer: No. Check the sending domain separately. Question: Does warm-up prove a production campaign will reach the primary inbox? Answer: No. Test a real message through the production sending path and review the recipient-side result. ``` The example is a decision record, not a Woodpecker configuration procedure. Woodpecker's public product information does not establish an account path or activation sequence for warm-up. The useful evidence comes in layers: - DNS: confirm the domain's published email-security configuration through authoritative DNS and a public resolver. - Vendor: review the current status shown by Woodpecker for the connected mailbox or domain. - Message: send a real test message through the same outbound path used for campaigns, then inspect the delivered headers and recipient result. - DMARC: review aggregate reports once they are available to identify the sources using the domain and any authentication or alignment issues. For another vendor-specific framing of this distinction, see [Apollo email warmup: what it does and what it cannot prove](/learning/apollo-email-warmup). ## What to check next Start with the evidence you have. If you only have the sending domain, use the [Palisade email security score](/tools/email-security-score) to inspect publicly visible email-security signals. This is a diagnostic check for the domain, not a test of a particular Woodpecker mailbox or campaign. If you have access to Woodpecker, compare its current mailbox or deliverability status with the configuration your team intended to use. Then send a controlled test through the same mailbox, domain, and campaign path planned for production. Keep the header evidence and recipient outcome with the test record. If you are assessing warm-up as one part of an outbound program, [Palisade's deliverability learning hub](/email-deliverability) covers the wider controls that affect delivery beyond a single sending feature. ## Check the domain behind the warmed mailbox A Woodpecker warm-up status does not show whether the sending domain has the public email-security controls your team expects. Check the domain first, then compare that result with Woodpecker's mailbox status and a real delivered test message. [Inspect the domain's email security](/tools/email-security-score) A public domain check cannot prove Woodpecker's current warm-up state, inspect a private campaign configuration, monitor the mailbox continuously, or guarantee placement at any receiver. If your team needs an ongoing way to identify sending sources and authentication or alignment issues across domains, [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=warm-up_and_sending_practices&utm_content=woodpecker-email-warmup). Palisade analyzes DMARC aggregate-report data and proposes prioritized remediation work, while your team reviews the evidence and applies any policy changes. It does not control Woodpecker's warm-up behavior or guarantee campaign delivery. ## Sources and further reading - [Woodpecker product and deliverability features](https://woodpecker.co) - [Palisade email security score](/tools/email-security-score) - [Palisade guide to email deliverability](/email-deliverability) ## Frequently asked questions ### Can Woodpecker be used to warm up a mailbox? Yes. Woodpecker publicly lists "Free warm-up" and says users can "Connect, buy or warm up domains/mailboxes." Its public product page does not document the exact activation path or mailbox prerequisites. ### What does Woodpecker say its warm-up does? Woodpecker says its free warm-up "Automatically builds your sender reputation." The public statement does not describe the sending schedule, volume, recipient network, or a time-to-readiness estimate. ### Does Woodpecker warm-up replace SPF, DKIM, and DMARC? No. Woodpecker presents warm-up and authentication-related setup as separate capabilities. Its claim about SPF, DKIM, and DMARC being pre-configured applies to domains and emails bought through Woodpecker, not every connected mailbox. ### Does email warm-up guarantee inbox placement? No. Warm-up does not prove how a receiver will handle a future message. A receiver can consider authentication, reputation, content, user signals, and local policy. ### Should I test a Woodpecker mailbox after enabling warm-up? Yes. Send a controlled message through the exact production mailbox and domain, then inspect the delivered message and recipient outcome. A public DNS check and a vendor status indicator each cover only part of that validation. --- # Yahoo email authentication Canonical: https://www.palisade.email/learning/yahoo-email-authentication > Yahoo email authentication can refer to Yahoo account security or sender authentication. Use Yahoo Help to identify the account issue before acting. Yahoo email authentication is an ambiguous phrase. It can refer to access to a Yahoo account, or to authentication of messages sent to Yahoo recipients. [Yahoo Help](https://help.yahoo.com) lists account-help topics including "Account Key," "Account security," "Fix problems signing into your Yahoo account," and "Fix issues with Yahoo Account Key." That help index does not define sender-side SPF, DKIM, or DMARC requirements. ## Quick takeaways - Yahoo Help separates account-help topics from sender-side email authentication documentation. - "Account Key" appears in Yahoo Help's account-help index. - A sign-in or account-security question needs Yahoo account-help guidance. - A question about messages sent to Yahoo recipients needs sender-authentication evidence. - The Yahoo Help index does not document SPF, DKIM, DMARC, alignment, or sender enforcement rules. - Do not treat an account sign-in prompt as evidence that a sending domain has an email-authentication failure. ## How the distinction works Yahoo Help's [account-help index](https://help.yahoo.com) includes the topics "Account Key," "Account security," "Reset or change your Yahoo password," "Fix problems signing into your Yahoo account," and "Fix issues with Yahoo Account Key." Those labels establish that Yahoo provides help paths for account access and account security. They do not establish what an individual Yahoo Mail authentication prompt means, how Account Key works, or how to repair a specific sign-in problem. The exact cause can depend on the account and the prompt shown to the user. Sender authentication is a separate question. It concerns evidence attached to a message and the domain that appears in the message's visible From address. The Yahoo Help index supplied for this topic does not document Yahoo's current sender requirements, its enforcement rules, or its interpretation of SPF, DKIM, or DMARC. For a general explanation of that sender-side topic, see [email authentication](/learning). The distinction matters because an account-access issue cannot be resolved by changing a domain's DNS records, and a message-delivery issue cannot be diagnosed from an account-help topic alone. ## When the answer changes Use the evidence you already have to separate the two meanings. - If the question is about signing in, a password, account security, Account Key, or a Yahoo prompt, begin with [Yahoo Help's account-help topics](https://help.yahoo.com). - If the question is about mail sent to Yahoo recipients, gather evidence from the actual sending path before deciding that Yahoo account authentication is involved. - If the question is about a domain's email authentication generally, start with the protocol context in [what email authentication is and why it matters](/learning/what-is-email-authentication-and-why-does-it-matter). - If the issue is that Yahoo is blocking or rejecting a message, use the message evidence and the specific delivery symptom. [Why is Yahoo blocking my emails?](/email-deliverability/why-is-yahoo-blocking-my-emails) covers that separate problem. A usable decision rule is: account-help labels apply to account access questions. Message delivery needs message and sender-domain evidence. Do not substitute one for the other. > Do not change SPF, DKIM, or DMARC records because a Yahoo account asks for authentication. First establish whether the affected person is signing in to an account or whether a sent message has a delivery problem. If you need to check your sender domain's authentication records, [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=email_authentication&utm_content=yahoo-email-authentication). ## A worked evidence example Suppose a user says, "Yahoo is asking me for authentication." The statement alone does not identify a sender-authentication failure. The verified next evidence is the account screen or help topic involved. Yahoo Help lists these relevant account-help labels: ```text Account Key Account security Fix problems signing into your Yahoo account Fix issues with Yahoo Account Key ``` The list is a navigation aid, not a diagnosis. It does not say which prompt the user received, whether Account Key is enabled, or which repair applies. ![Decision flow separating Yahoo account-help questions from sender-email-authentication questions](/images/editorial/yahoo-email-authentication/yahoo-email-authentication-decision-flow.webp "1200x676") *Source: Palisade.* For a message-delivery case, collect the message's actual delivery result and the sending domain involved. A public DNS result alone cannot prove the production sending path, a receiver's private decision, or future placement. Likewise, an account sign-in result cannot establish whether a message used authenticated sender infrastructure. ## What to do next Start with the narrowest available evidence. For a Yahoo account-access question, open [Yahoo Help](https://help.yahoo.com) and choose the topic that matches the visible account issue. The available index labels include account security, sign-in problems, and Account Key issues. For a sender-domain question, keep account support and sender authentication separate. Record the sending domain, the recipient domain, and the actual message outcome. If the problem is a delivery block, work from the message evidence rather than guessing from a Yahoo sign-in prompt. For broader sender-domain context, the [DKIM learning hub](/learning/dkim) explains the authentication protocol area that can be relevant to outbound mail. It does not establish Yahoo's current provider-specific requirements. ## Read the sender-authentication context If the unresolved question is about mail sent from a domain rather than access to a Yahoo account, read [email authentication](/learning) before changing DNS or asking the account holder to repeat a sign-in step. That explainer provides protocol context. It does not diagnose a Yahoo account prompt, prove why Yahoo handled one message a certain way, or document Yahoo's current sender requirements. ## Sources and further reading - [Yahoo Help](https://help.yahoo.com) - [Email authentication](/learning) - [What is email authentication and why does it matter?](/learning/what-is-email-authentication-and-why-does-it-matter) - [Why is Yahoo blocking my emails?](/email-deliverability/why-is-yahoo-blocking-my-emails) ## Frequently asked questions ### Does Yahoo Mail have an authenticator? Yahoo Help lists "Account Key" and "Fix issues with Yahoo Account Key" among its account topics, so the account does have a sign-in feature under that name. Yahoo's help index does not define what Account Key does or call it an authenticator. Open [Yahoo Help](https://help.yahoo.com) and choose the topic that matches the prompt shown on the account. ### How do I authenticate my Yahoo email account? Open [Yahoo Help](https://help.yahoo.com) and pick the account topic that matches what you see: account security, a sign-in problem, or Account Key. Yahoo does not publish a single generic procedure, because the right step depends on the prompt your account displays. This is account access, which is separate from the sender authentication a domain publishes in DNS. ### How do I fix a Yahoo Mail authentication problem? Work out first whether the problem is an account sign-in prompt or a problem with mail sent to Yahoo recipients, because the two have different repairs. For a sign-in prompt, use Yahoo Help's topics "Fix problems signing into your Yahoo account" and "Fix issues with Yahoo Account Key." For a delivery problem, work from the message evidence and the sending domain instead. ### Why is Yahoo Mail asking for authentication? Yahoo does not publish what triggers an individual authentication prompt, so the wording on screen is your starting point. Its help index covers account security, Account Key, and sign-in problems, which are the areas such a prompt usually comes from. Match the exact prompt to the Yahoo Help topic and follow that support path. ### Does a Yahoo account prompt mean my domain has a DMARC problem? No, because an account prompt concerns access to a Yahoo mailbox while DMARC concerns messages sent using your visible From domain. The prompt on its own is no evidence about the sending domain. Do not change SPF, DKIM, or DMARC records in response to a sign-in prompt. --- # Zoho email warmup: what it is and what it cannot prove Canonical: https://www.palisade.email/learning/zoho-email-warmup > Zoho email warmup is an optional third-party workflow, not a proven Zoho requirement. Check domain authentication before connecting a warm-up service. Zoho email warmup is an optional third-party service workflow that sends and interacts with emails from a connected Zoho inbox. The available provider claims do not establish that Zoho Mail requires warm-up, endorses it, or that warm-up guarantees inbox placement. Before connecting any service, verify the sending domain's authentication posture and confirm the provider's current Zoho connection support. ## Quick takeaways - Zoho email warmup usually refers to a third-party service connected to a Zoho inbox. - Warmbox lists "Zoho Inbox" as a supported inbox integration. - Warmup Inbox lists "Zoho" among the providers it says it works with. - Those provider claims do not prove that Zoho recommends warm-up or that it improves delivery at a specific mailbox provider. - A warm-up service cannot replace SPF, DKIM, and DMARC checks for the sending domain. - Provider-specific connection requirements should be confirmed before granting access to a Zoho inbox. ## How a Zoho email warmup workflow works A third-party warm-up provider connects to a sending inbox and performs activity through its own network. [Warmbox describes its workflow](https://warmbox.ai) with the statement, "Warmbox will send everyday realistic emails from your inbox." Its product description also says it can remove emails from spam, open, bookmark, reply to, and favorite messages. [Warmup Inbox describes a separate workflow](https://warmupinbox.com) that connects a sending inbox through OAuth or SMTP, exchanges messages with its network, and tracks inbox, spam, and bounce rates. Its provider list includes "Zoho," and its connection copy states: "Connect your sending inbox OAuth into Gmail, Outlook, or any SMTP." These descriptions explain what the warm-up vendors say their products do. They do not document Zoho Mail behavior, a Zoho Mail recommendation, or a receiver's inbox-placement decision. Email deliverability is affected by more than inbox activity. [Email deliverability]( /learning/email-deliverability) also depends on authentication, sender behavior, message content, recipient engagement, and each receiving system's local filtering decisions. ![Decision flow for assessing a proposed Zoho email warmup service, starting with domain authentication and ending with provider-specific connection confirmation](/images/editorial/zoho-email-warmup/zoho-email-warmup-decision-rule.webp "1200x829") *Source: Palisade.* ## When a Zoho warmup decision changes The useful decision rule is based on what is known and what remains unknown. - If the sending domain does not have a known authentication baseline, check that first. Inbox activity cannot establish that the domain's SPF, DKIM, or DMARC posture is correct. - If a vendor says it supports Zoho, treat that as the vendor's compatibility claim. Confirm its current connection requirements and access scope before authorizing the connection. - If a mailbox provider places a message in spam or rejects it, use the delivered message, headers, bounce information, and the provider's own tools to investigate. A warm-up dashboard cannot prove why that receiver made its decision. - If the goal is to set up an ESP or sender safely, use the broader [email service provider setup guidance](/learning/esp-setup) for the account and domain configuration work. The available material does not support a universal daily sending ramp, a recommended warm-up duration, or an inbox-placement target for Zoho. It also does not establish that a service's automated interactions improve delivery to Gmail, Microsoft, Yahoo, or Zoho recipients. > Do not grant a third-party warm-up service access to a production inbox until the team has reviewed the provider's current authorization method, data handling, and disconnect procedure. ## Worked decision example Use this example as a decision record, not as a configuration command or a promise about delivery. ```text Sending domain: mail.yourdomain.com Sending inbox: outreach@yourdomain.com Known evidence: A third-party service states that it supports Zoho. Unknown evidence: Zoho's current connection requirements and whether the service affects recipient placement. Next action: Check the sending domain's authentication baseline, then confirm the provider's current Zoho connection path before authorizing access. ``` This distinction matters because a connected inbox and an authenticated domain answer different questions. A service may be able to connect to a mailbox, while the domain still has an incomplete or misaligned authentication configuration. Conversely, a public DNS result can show published records without proving that a specific application used the expected sending path. For a broader explanation of automated inbox activity, see [AI email warmup: what it is and what it cannot prove](/learning/ai-email-warmup). If your outbound mail uses Zoho Campaigns, [SPF and DKIM setup for Zoho Campaigns](/learning/how-do-i-set-up-spf-and-dkim-for-zoho-campaigns) covers that distinct authentication task. ## Take the next step based on your evidence Start with the evidence you have: - If you only have the domain name, inspect its public authentication baseline before evaluating warm-up. - If you have a delivered message, review its authentication results and the actual sending path before attributing placement to a warm-up service. - If you have a provider proposal, confirm that its stated Zoho support, authorization method, and permissions still match your account. - If you have a receiver-side problem, collect the receiver's bounce or dashboard evidence. A public domain check cannot reveal a receiver's private filtering decision. A public check is a starting point. It does not prove that a Zoho mailbox is connected correctly, that a production message used the expected authentication, or that future messages will reach the inbox. ## Check the sending domain before connecting a warm-up service Assess the sending domain's public email-security posture before relying on a third-party Zoho warm-up workflow. This gives you a baseline for the domain behind the proposed sending inbox. [Check the sending domain's email security](/tools/email-security-score) A public domain check does not prove a warm-up provider's Zoho compatibility, repair a sender configuration, monitor a connected inbox, or guarantee delivery at any recipient. ## Sources and further reading - [Warmbox](https://warmbox.ai) - [Warmup Inbox](https://warmupinbox.com) - [Palisade Email Security Score]( /tools/email-security-score) - [Palisade guide to email deliverability](/email-deliverability) ## Frequently asked questions ### Is Zoho email warmup required? Zoho does not require warm-up. Zoho Mail publishes no warm-up requirement and no warm-up recommendation for its accounts. The vendors that advertise Zoho support are selling an optional service of their own, so treat warm-up as a choice rather than a setup step. ### Can a warm-up service connect to a Zoho inbox? Some services can, as long as the provider supports the connection method Zoho offers and your account can authorize it. Warmbox lists "Zoho Inbox" and Warmup Inbox lists "Zoho" among its supported providers. Confirm the provider's current requirements before you grant access to a production inbox. ### Does Zoho email warmup guarantee inbox placement? No warm-up service can guarantee inbox placement, because every receiver decides for itself where a message lands. Automated activity inside a vendor's own network tells you nothing about how Gmail, Microsoft, Yahoo, or Zoho will filter your next production message. ### Should SPF, DKIM, and DMARC be checked before warm-up? Yes, check the sending domain's SPF, DKIM, and DMARC first, so you have an authentication baseline before you credit or blame a warm-up service. Published records still need to be compared with evidence from the real production sending path. ### Can a public domain check prove that Zoho is sending correctly? No, a public domain check only reads what DNS publishes, so it cannot show that a specific Zoho message used the expected authentication path. It also cannot explain why a receiver placed a message where it did. Use the delivered message's headers for that. --- # Braze one-click unsubscribe Canonical: https://www.palisade.email/learning/braze-one-click-unsubscribe > Braze one-click unsubscribe requirements need current Braze, RFC, and mailbox-provider documentation before implementation guidance is safe. Braze is a customer engagement platform with cross-channel messaging capabilities, but the available evidence does not establish whether or how Braze supports header-based one-click unsubscribe for email. Do not treat a visible unsubscribe link as proof of one-click unsubscribe. Safe implementation guidance requires current official Braze documentation, the controlling IETF standard, and the relevant mailbox-provider requirements. ## Quick takeaways - A visible unsubscribe link in a Braze email does not by itself prove that the message supports header-based one-click unsubscribe. - Confirm the current Braze implementation in official Braze documentation before documenting configuration steps. - Compare the implementation with the controlling IETF standard and current mailbox-provider requirements. - Inspect the delivered message headers, not only the link visible in the email body. - Verify the behavior with a controlled test message before treating the setup as complete. - Keep provider requirements separate from Braze product behavior. A mailbox provider may define requirements that a sending platform must help satisfy, but the platform's interface and documentation still need separate verification. - If the evidence does not establish support, describe the result as unconfirmed rather than assuming that the feature exists. ## What one-click unsubscribe means here The phrase “one-click unsubscribe” can describe more than one user experience. A message may contain a visible link that takes the recipient to an unsubscribe page. It may also contain header-based unsubscribe information that a mailbox interface can use when presenting an unsubscribe control. Those two mechanisms should not be treated as interchangeable. A recipient might be able to unsubscribe through the body of a message while the message still lacks the header information required for a mailbox-provider one-click workflow. The reverse also requires verification. A header alone does not establish that the complete recipient experience works as intended. For Braze, the available evidence in this draft does not establish whether or how the platform supports header-based one-click unsubscribe for email. That uncertainty matters because a configuration guide would need to identify the exact setting, field, template behavior, or message-level control involved. Without current product documentation and a delivered-message test, a precise instruction would risk describing a capability that is unavailable, implemented differently, or limited to a particular sending path. ## How to assess a Braze implementation Start with the current official Braze documentation. Search for documentation that addresses unsubscribe headers, one-click unsubscribe, message headers, email subscription groups, or the specific Braze email sending workflow in use. Record the exact product area and the date of the documentation you reviewed. Next, identify the requirements that control the mailbox-provider behavior. The relevant IETF standard should be read alongside current requirements from the mailbox providers that matter to the sender. These sources answer different questions: - The IETF standard defines the protocol behavior and the relevant message fields. - Mailbox-provider documentation explains when a provider expects or uses that behavior. - Braze documentation explains whether the platform exposes a supported way to produce the required message. - A delivered-message test shows what the recipient's message actually contains. Do not use one source as a substitute for the others. A Braze help page may describe a product option without proving that the resulting message satisfies every mailbox-provider condition. A mailbox-provider page may describe the expected message behavior without explaining how to configure Braze. A visible unsubscribe link may confirm only the body experience. ## What to inspect in the delivered message Send a controlled test message through the same Braze path used for production mail. Use a test domain or test audience where possible, and preserve the original message source for review. Inspect the complete message rather than relying on a rendered view in a mailbox application. The review should answer these questions: - Does the delivered message contain the expected unsubscribe-related header fields? - Are the header values consistent with the controlling IETF standard? - Does the message body still contain the expected visible unsubscribe path? - Did the headers survive the sending and delivery path? - Does the observed result match the current Braze documentation? - Does the result align with the mailbox-provider requirement being evaluated? If the answer to any required question is unknown, leave the implementation status unconfirmed. Record the message path, the Braze configuration used, the test date, and the raw header evidence. This makes the conclusion reproducible without turning an assumption into a product claim. ## Braze documentation and evidence boundaries The available evidence does not establish whether Braze supports header-based one-click unsubscribe. That is a boundary on what this article can safely claim. It does not establish that Braze lacks the feature, and it does not establish that every Braze email workflow behaves the same way. Product interfaces and documentation can change. A setting may be available only in a specific campaign type, template, email configuration, or account context. A general unsubscribe capability may also be described with terminology that differs from the terminology used by the IETF standard or a mailbox provider. For that reason, implementation guidance should cite the current official Braze source that describes the exact behavior. If no such source is available, the correct result is to document the uncertainty and continue testing. Do not infer support from a button label, an unsubscribe URL, a campaign preview, or a successful visit to an unsubscribe page. Related Palisade guidance can provide context for [DMARC concepts](/learning/dmarc), [DMARC checking](/tools/dmarc), and [email deliverability](/email-deliverability), but those pages do not replace current Braze documentation or the controlling standard for this specific question. ## A safe verification record Keep a short record for each implementation review. Include the Braze workflow, the sending domain, the test date, the documentation consulted, the relevant mailbox-provider requirement, and the observed message headers. Store the conclusion as confirmed, not confirmed, or unconfirmed according to the evidence available. A confirmed result should identify the source and the delivered-message evidence supporting it. A not confirmed result means the available documentation or test did not establish the behavior. An unconfirmed result means that a conclusion would require additional current documentation or a new test. This distinction helps prevent a common documentation error: treating an ordinary unsubscribe link as proof of header-based one-click unsubscribe. It also gives future reviewers a clear place to update the article when Braze documentation or mailbox-provider requirements change. ## Sources and further reading - [Braze](https://braze.com) - [Palisade DMARC concepts](/learning/dmarc) - [Palisade DMARC checker](/tools/dmarc) - [Palisade email deliverability guidance](/email-deliverability) ## Frequently asked questions ### Does a Braze unsubscribe link prove one-click unsubscribe? No, because a visible link only shows that the message body offers an unsubscribe path. Header-based one-click unsubscribe lives in the message headers instead, so it has to be verified against the controlling IETF standard, current mailbox-provider requirements, Braze documentation, and the delivered message itself. ### Should a Braze implementation be documented from the email preview? No, because a preview renders the body and does not show which headers reach the recipient. Send a test message through the same Braze path you use in production, then read the raw source of what arrives and compare it with the standard and the mailbox-provider requirement. ### Is a visible unsubscribe page enough to verify the implementation? No, because a working unsubscribe page shows only that the body-level path processes a request. It says nothing about the headers a mailbox interface reads when it presents its own unsubscribe control, so the delivered message's headers still need review. ### What should be recorded during verification? Record the Braze workflow, sending domain, test date, documentation consulted, relevant mailbox-provider requirement, and observed message headers. Keep the conclusion tied to that evidence and mark it unconfirmed when the evidence is incomplete. --- # PowerDMARC SPF checker Canonical: https://www.palisade.email/learning/powerdmarc-spf-checker > PowerDMARC SPF checker information: what PowerDMARC publicly lists, what an SPF lookup can establish, and which evidence is still needed today. PowerDMARC publicly lists an "SPF Lookup" tool and a hosted SPF service, but its public homepage and support index do not document the lookup's current input fields, result labels, warnings, or repair workflow. Treat a lookup as a way to inspect a published SPF configuration, then keep that DNS observation separate from evidence about the production sender and a delivered message. ## Quick takeaways - [PowerDMARC lists "SPF Lookup" among its tools](https://powerdmarc.com). - [PowerDMARC's support index lists "Free SPF Record Lookup" under Tools](https://support.powerdmarc.com). - The publicly available pages reviewed for this article do not establish the lookup's current result states or UI workflow. - A public SPF-record result is DNS evidence, not proof of a specific production sending path. - A checker result alone cannot explain an individual receiver's decision about one message. - Compare a public lookup with sender and message evidence before changing a production record. ## What this tool checks PowerDMARC's public homepage includes the tool name "SPF Lookup," and its support index includes "Free SPF Record Lookup." Those public references establish that PowerDMARC offers an SPF lookup, but they do not establish what the current tool asks a reader to enter, how it resolves DNS, or how it labels a result. The public references also do not document whether the tool evaluates a record beyond displaying it. PowerDMARC separately describes hosted SPF as: > "One-click Hosted SPF optimization with record flattening or SPF Macros approach to always stay under the lookup limit and enjoy error-free SPF." That statement concerns PowerDMARC's hosted product. It is not evidence that the free lookup performs record flattening, detects a particular problem, repairs DNS, or returns a particular warning. This distinction matters when comparing a vendor lookup with another workflow. A public check can inspect an answer visible in DNS. It cannot see which service sent a particular message, whether that service used the expected return path, whether a receiver accepted the message, or what happens after the check completes. Readers comparing SPF tools can run the same inspection with the free [Palisade SPF checker](/tools/spf), or use the [Palisade comparison hub](/compare) to place that narrower task beside broader email-authentication work. ![Evidence map separating a public SPF lookup from sender and delivered-message evidence](/images/editorial/powerdmarc-spf-checker/powerdmarc-spf-checker-evidence-map.webp "1200x676") *Source: Palisade.* ## How to run the check The current public PowerDMARC material does not provide a verified step sequence for its SPF Lookup interface. Do not rely on a guessed field name, button label, or result color when documenting or using that interface. Open the vendor's current [PowerDMARC website](https://powerdmarc.com) or [PowerDMARC support center](https://support.powerdmarc.com) and follow the live tool path shown there. ### 1. Identify the domain whose published configuration you need to inspect Use the domain associated with the sending identity under investigation. Keep the domain separate from any assumptions about an individual application, mailbox provider, or message recipient. If the question is comparative, identify the task first: inspecting a published SPF configuration is different from confirming what an outbound message actually did. The [email-authentication guidance for Gmail](/learning/authenticate-email-for-gmail) is relevant when the operational question concerns mail sent to Gmail, rather than a public DNS result alone. ### 2. Run a repeatable public DNS lookup Use a public DNS query as an independent record of the answer you observed. Replace the example domain with the domain you are authorized to inspect. ```bash dig +short TXT yourdomain.com ``` A DNS response is useful evidence to retain alongside the tool result. It does not establish that every TXT response is an SPF record, nor does it prove that an application used an authorized production path. ### 3. Record only the observations the live tool actually returns Capture the domain you entered, the time of the check, and the exact result text shown by the live service. If the service shows a returned record, retain that text. If it shows an error or warning, retain the exact wording rather than converting it into a diagnosis. Do not infer a vendor result state from its hosted-product marketing. "Hosted SPF optimization" is a separate product statement. It does not document the behavior of the free lookup. ## How to interpret the results The public material does not document PowerDMARC SPF Lookup result labels, warning strings, or an interpretation guide. The safe interpretation is therefore limited to the evidence itself. ### A published record is shown If the live tool displays a published SPF-related DNS result, treat that as a public-DNS observation for the domain submitted at that time. Preserve the exact returned text and compare it with an independent DNS query. Do not use that result alone to conclude that a production application is authorized. A public record can be present while the sender under investigation uses a different identity or configuration. A delivered message from the same production path remains separate evidence. ### No usable result is shown If the live tool does not show a usable result, record the exact text it returns and repeat the DNS query against the same domain. The public documentation reviewed here does not establish whether a particular message means no record exists, DNS resolution failed, the submitted value was invalid, or another condition applies. Move to the authoritative DNS provider when the public answer and the configured record need to be compared. Do not copy a record from another domain or tenant to resolve an unclear result. ### A warning or recommendation is shown Treat a warning as a vendor-specific observation until the current vendor documentation explains its condition and remedy. The available public PowerDMARC pages do not document the lookup's warning taxonomy, so a warning cannot be translated into a repair threshold from those pages alone. The practical next step is evidence collection: retain the exact warning, inspect the published DNS response, identify the production sender, and inspect a delivered message from that sender. This keeps a DNS observation from becoming an unsupported conclusion about mail flow. ### A hosted SPF option is offered PowerDMARC's homepage describes hosted SPF optimization with record flattening or SPF Macros. That is a hosted-product description. It does not show that a specific free-lookup result requires hosted SPF, or that adopting the hosted service will resolve a particular sending problem. Before changing DNS, determine which record is currently published and which sender is affected. A tool recommendation can inform the next question, but it does not replace evidence from the sender configuration and a real message. ## How to act on the result Start with the least assumptive action. Preserve the exact domain and DNS response from the lookup. Then identify the application or service that sent the message at issue. If the operational question arose from delivery to Gmail, compare the result with the sender's actual configuration and the delivered-message evidence described in [how to authenticate an email for Gmail](/learning/authenticate-email-for-gmail). When a message uses a third-party sending service, do not assume that a visible SPF result answers DMARC alignment. The [Brevo SPF alignment explanation](/learning/brevo-spf-alignment) illustrates why sender-path evidence and alignment questions must stay distinct. > Do not replace or flatten a production SPF record from a checker result alone. A DNS change can alter mail authorization for every service that uses the domain. Use these evidence layers before approving a record change: - DNS: compare the authoritative record with at least one public DNS response. - Sender: identify the application and configuration responsible for the relevant mail. - Message: inspect a delivered message from that same production path. - DMARC: review aggregate-report evidence after data accumulates. A green or complete-looking DNS result does not remove the need for the sender and message layers. A failed lookup does not prove which production system needs a change. ## Investigate this with your coding agent Use this when a public SPF lookup identified a record that needs investigation and the domain's DNS configuration is managed in a repository. Provide only a redacted result and non-sensitive configuration context. ```agent Problem: A public SPF lookup for the domain returned a result that needs investigation before any DNS change. Evidence: Redacted checker result, domain name, timestamp, public DNS response, and the names of known sending services. Do not provide credentials, private keys, tokens, unredacted message headers, or customer data. Repository scope: Inspect the repository locations that define DNS records, mail-sender configuration, and deployment runbooks for the affected domain. Constraints: Inspect before editing. Do not apply changes until I approve the proposed diff. Do not alter unrelated DNS records. Treat the public lookup as DNS evidence only, and identify any sender relationship that cannot be proven from repository contents. Requested output: Diagnosis, minimal proposed change, rollback, and unknowns. Verification: Repeat the same public SPF lookup and the same public DNS query for the affected domain after an approved change. Stop if: Credentials, private data, production mutation, or missing evidence is required. ``` ## How to retest Repeat the same lookup path with the same domain after an approved DNS change. Retain the before-and-after result text and repeat the public DNS query. ```bash dig +short TXT yourdomain.com ``` The expected DNS change is only the changed public answer for the affected domain. A changed lookup result does not prove that a production application has adopted the intended configuration. Send a new message through the same application and recipient path, then inspect that delivered message before treating the repair as complete. For a broader inventory task, a [bulk DMARC checker](/learning/bulk-dmarc-checker) can help organize domain-level checks. It does not replace sender-level or delivered-message evidence. ## Compare the next SPF-checking workflow If you need to compare a public SPF lookup with another vendor workflow, start with the [Palisade comparison hub](/compare). Choose a checker based on the evidence you have: a domain for public DNS inspection, a sender configuration for setup review, or a delivered message for message-path validation. A comparison page cannot prove what one production message used, repair a DNS record, monitor later changes, or explain a receiver's private delivery decision. ## Sources and further reading - [PowerDMARC homepage](https://powerdmarc.com) - [PowerDMARC support center](https://support.powerdmarc.com) - [Palisade comparison hub](/compare) ## Frequently asked questions ### Does PowerDMARC offer an SPF lookup? Yes. PowerDMARC publicly lists "SPF Lookup" among its tools, and its support index lists "Free SPF Record Lookup" under Tools. ### Does the public PowerDMARC information document the SPF Lookup result states? No. The public homepage and support index reviewed for this article do not document the current input fields, result labels, warnings, or repair workflow for the lookup. ### Does a public SPF lookup prove a production sender is authorized? No. A public lookup can provide DNS evidence for the submitted domain. It does not prove which configuration a specific production application used or what a delivered message contained. ### Can a checker result explain why one receiver handled a message a certain way? No. A public DNS result cannot establish a receiver's private decision about an individual message. Inspect the delivered message and the relevant sender configuration. ### Should a hosted SPF product be treated as the same thing as a free lookup? No. PowerDMARC describes hosted SPF optimization separately from its publicly listed SPF Lookup tool. The public statements do not establish that the free lookup performs hosted optimization or that a given lookup result requires it. --- # Why is my BIMI SVG format causing logo issues? Canonical: https://www.palisade.email/learning/why-is-my-bimi-svg-format-causing-logo-issues > Why BIMI SVG format causes logo issues: check the public SVG Tiny PS asset, BIMI DNS record, certificate status, and delivered-message evidence. BIMI SVG format causes logo issues when the public URL in the BIMI record does not return a BIMI-compatible SVG Tiny PS file, or when the asset is valid but another eligibility condition prevents a mailbox client from displaying it. Start with the exact public `l=` URL and the validator result. DNS edits alone do not repair an incompatible SVG export, an inaccessible hosted file, or a receiver's display decision. ## Quick takeaways - BIMI DNS, the hosted SVG asset, certificate evidence, and mailbox display are separate checks. - BIMI logo artwork must use the constrained SVG Tiny Portable/Secure profile, usually called SVG Tiny PS. - A logo that opens locally can still fail when retrieved from the public URL in the BIMI record. - A valid SVG and BIMI record establish public publication evidence, not a promise that every provider or client will show the logo. - Check a fresh message from the affected production path after repairing the public asset. - Preserve an evidence packet before replacing artwork, DNS values, or certificate references. ## What does the failure mean? A BIMI record tells receivers where to retrieve a brand logo. The [BIMI Group's SVG conversion guidance](https://bimigroup.org/creating-bimi-svg-logo-files/) requires a constrained SVG Tiny PS profile rather than an ordinary web SVG. If a checker reports an SVG-format issue, it is evidence that the published asset could not be accepted as BIMI artwork. It does not prove that the domain's DMARC authentication, certificate status, or a receiver's logo-display rules are correct. Preserve the observed evidence exactly before changing the logo: ```text Sending domain: example.com Published BIMI record name: default._bimi.example.com Published logo URL: https://assets.example.com/brand/bimi-logo.svg Hosted URL status: 200 Hosted response content type: <record the observed value> Validator result: <copy the exact error text> Production message evidence: <redacted Authentication-Results or provider status> ``` The relevant file is the response a recipient can retrieve from the HTTPS URL published in DNS. A local design preview, staging URL, or file attached to a ticket does not test that public response. ![Flow showing BIMI DNS publication, public SVG retrieval, SVG Tiny PS validation, certificate evidence, and mailbox display as separate checks](/images/editorial/why-is-my-bimi-svg-format-causing-logo-issues/why-is-my-bimi-svg-format-causing-logo-issues-bimi-evidence-flow.webp "1200x829") *Source: Palisade.* ## What usually causes it? ### The published logo is ordinary SVG rather than SVG Tiny PS Design applications can export SVG files with elements or metadata outside the BIMI profile. The artwork can render correctly in a browser while a BIMI validator rejects it. The [BIMI SVG Tiny PS conversion requirements](https://bimigroup.org/creating-bimi-svg-logo-files/) explain why a general SVG export is not enough for BIMI. This is the most likely branch when the public URL returns the intended file and the validator identifies an SVG-format failure. The particular unsupported element remains an inference until the validator or direct file inspection identifies it. ### The BIMI record points to the wrong public asset The `l=` tag can contain an old URL, a test path, or a typo. DNS can therefore be valid as DNS while still identifying artwork that is not the approved logo. Use the [Palisade BIMI checker](/tools/bimi) to inspect the BIMI record visible through public DNS. A public lookup can show the currently published record. It cannot prove what a receiver cached, whether the sending message qualifies for BIMI, or whether a logo will appear in a particular mailbox client. ### The asset cannot be retrieved over HTTPS The public URL can redirect to an error page, require access, return HTML instead of the SVG, or serve a different object than the uploaded file. The [BIMI Group implementation guidance](https://bimigroup.org/creating-bimi-svg-logo-files/) treats the logo asset itself as part of the BIMI implementation. This is a hosting or deployment issue, not evidence that the source artwork is malformed. Retrieve and retain the downloaded response, its final URL after redirects, response headers, and file hash. ### A required VMC or CMC is missing or invalid Some mailbox-provider implementations require a verified mark certificate before displaying a BIMI logo. [Google Workspace's BIMI documentation](https://support.google.com/a/answer/10911320) describes its certificate and authentication requirements for displaying brand indicators in Gmail. A valid SVG does not replace a certificate requirement where that provider applies one. Treat certificate status as its own evidence branch. Record whether the published BIMI record includes an `a=` location, whether that location retrieves as expected, and the certificate status reported by the applicable provider or certificate issuer. ### The production message does not meet authentication conditions BIMI relies on email authentication conditions beyond the artwork file. [RFC 9989 defines DMARC](https://www.rfc-editor.org/rfc/rfc9989.html), including how aligned SPF or DKIM results support DMARC evaluation. A compatible SVG does not repair a production message that fails DMARC. Inspect a delivered message from the exact application and route where the logo is expected. Do not substitute a test from another sending platform. ### The provider or client did not display the logo Mailbox providers and clients apply their own support, eligibility, caching, and presentation decisions. A valid BIMI record, accessible SVG, and passing message establish useful evidence, but they do not guarantee logo display in every provider or client. If the asset checks pass, the SVG is no longer the confirmed cause. Review the affected provider's documentation and preserve the delivered-message context. ## How do I diagnose the failure? ![BIMI troubleshooting checklist covering DNS, public SVG retrieval, SVG Tiny PS validation, certificate status, and production-message checks](/images/editorial/why-is-my-bimi-svg-format-causing-logo-issues/why-is-my-bimi-svg-format-causing-logo-issues-diagnostic-checklist.webp "1200x582") *Source: Palisade.* ### 1. Preserve the public record and validator result Save the claimed sending domain, full BIMI DNS owner name, complete TXT value, exact `l=` URL, validator result, timestamp, and resolver used. Do this before uploading a replacement file or changing DNS. The [email infrastructure learning center](/learning/infrastructure) has related guidance on separating DNS publication from delivered-message authentication evidence. A new export can remove the evidence that distinguished an asset problem from a DNS or provider-display problem. ### 2. Query the published BIMI record Query the exact BIMI owner name through the authoritative DNS service and at least one public resolver: ```bash dig TXT default._bimi.yourdomain.com ``` This command is illustrative only. Use your organization's domain and published selector. If the authoritative response and public resolver differ, allow the DNS update to propagate before attributing the issue to the SVG. Record the result as a redacted DNS-to-SVG evidence fragment: ```text Domain: example.com DNS owner: default._bimi.example.com TXT value: v=BIMI1; l=https://assets.example.com/brand/bimi-logo.svg; a=https://assets.example.com/brand/example-vmc.pem SVG asset: https://assets.example.com/brand/bimi-logo.svg Asset SHA-256: <redacted recorded hash> Asset version: 2026-08-12-v2 SVG validation: <copy the exact validator result> ``` This is an illustrative structure only. Do not publish another organization's logo URL, certificate URL, hash, or DNS value. ### 3. Retrieve the exact SVG asset Request the `l=` URL outside the design or hosting environment. Confirm the final response returns the intended SVG file rather than a login page, object-store error, HTML document, or unexpected redirect. Compare the downloaded file's hash and version with the approved export. If they differ, repair the deployment first. Re-exporting artwork does not fix a CDN, object permission, or URL-mapping problem. ### 4. Inspect the file against SVG Tiny PS requirements Compare the retrieved file with the [BIMI Group SVG Tiny PS requirements](https://bimigroup.org/creating-bimi-svg-logo-files/). Ask the artwork owner to identify the exact feature cited by the validator and remove or replace only that feature in the editable source. Keep the original artwork and upload the corrected export at a new approved HTTPS URL. This keeps the prior asset available for rollback while public retrieval and validation are retested. > Do not overwrite the only known working logo asset during a broad send. Keep the prior URL and DNS value available until the replacement has passed the same public checks. ### 5. Record the BIMI evidence packet Collect these fields in the incident record so DNS, file, certificate, and display evidence do not get mixed together: - Claimed sending domain. - BIMI DNS owner name and complete published value. - SVG asset URL, downloaded file hash, and version or deployment identifier. - SVG Tiny PS profile result or the exact validator result. - VMC or CMC status, when applicable, including the published `a=` location. - Observed mailbox provider and client context. - Timestamp of the observation and planned retest date. - A redacted copy of the delivered message's relevant authentication results. A passing SVG check establishes that the public file retrieved at that time matches the expected profile check. A passing DNS check establishes that the resolver returned the recorded BIMI value. Neither result establishes that a mailbox provider will display the logo for every message, client, or future retrieval. ### 6. Check a fresh production message Send a new message through the same application, sender identity, outbound route, recipient provider, and mailbox client where the logo is expected. Preserve the full raw message in an access-controlled record. [RFC 8601 defines the Authentication-Results header field](https://www.rfc-editor.org/rfc/rfc8601.html). Record the receiver-added DMARC, SPF, and DKIM outcomes, including aligned identifiers when provided. A green status in a sending platform is useful evidence, but it is not a delivered-message check. ## How do I fix it? ### Replace an invalid SVG structure When the validator identifies an unsupported SVG feature, correct that feature in the editable artwork and export a BIMI-compatible SVG Tiny PS file. The free [Palisade BIMI SVG converter](/tools/bimi-svg-converter) converts an SVG to the Tiny Portable/Secure profile (square canvas, correct profile, valid title, no scripts) in the browser. It flags live `<text>` rather than outlining it, so convert lettering to paths in your design tool first. Upload the new file to a controlled HTTPS location, validate the public response, then update the `l=` value if the URL changed. This repair changes the logo asset. It does not change DMARC enforcement or prove mailbox display. ### Repair an inaccessible asset or HTTPS response When the public URL returns a redirect loop, access-denied response, HTML error page, or an unintended object, correct the hosting path, object permissions, HTTPS configuration, or deployment mapping. Retest the final URL from outside the hosting account before editing DNS. Do not change the BIMI record to hide a hosting failure. The record should name the asset that independent recipients can retrieve. ### Correct missing or invalid certificate evidence When the affected provider requires a VMC or CMC and its documented status indicates a missing or invalid certificate, resolve the certificate issue with the applicable issuer and publish the correct `a=` reference where required. Follow the provider's current documentation for its certificate and authentication conditions. This repair affects certificate evidence. It does not alter the SVG structure or guarantee client display. ### Document provider or client display variation When DNS, SVG retrieval, certificate status, and the production message all pass, record the mailbox provider, client, observation time, and any provider diagnostics. Treat a missing display as provider or client variation unless evidence identifies another cause. Do not loosen the DMARC policy as a response. Changing `p=` changes requested enforcement. It does not repair SVG compatibility, public hosting, certificate validity, or a receiver's display choice. ## How do I validate the repair? To validate the repair, repeat the original failure path with a fresh message. Check four independent layers: - DNS: Confirm the authoritative DNS service and a public resolver return the intended BIMI owner name and `l=` value. - Vendor or certificate: Confirm the relevant sending platform or certificate process reports the expected current status, where applicable. - Message: Inspect a newly delivered message from the same production path and record trusted receiver-added authentication results. - DMARC: Review aggregate-report data after it accumulates to confirm the source continues to authenticate and align as expected. Then repeat the public asset retrieval and SVG Tiny PS validation. Keep the prior asset URL, DNS value, validator result, and retest date in the incident record. A passing public check today cannot monitor later DNS drift, new sending sources, private receiver eligibility logic, or future logo presentation. ## Check the published BIMI record before replacing the asset If the failure evidence still points to the public record or `l=` location, inspect the currently published BIMI record before making another artwork change. [Check the BIMI record](/tools/bimi) A public BIMI lookup can inspect the record visible in DNS. It cannot validate a private sending path, repair the hosted SVG, confirm a receiver's certificate decision, or guarantee logo display. For teams that need to track which sending sources continue to pass DMARC after the asset issue is resolved, Palisade is DMARC software that analyzes aggregate-report data, identifies authentication or alignment issues, and proposes the next policy step for human review. It does not control a mailbox provider's private logo-display decision. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=email_authentication&utm_content=why-is-my-bimi-svg-format-causing-logo-issues) ## Sources and further reading - [BIMI Group: converting a logo to BIMI SVG Tiny PS](https://bimigroup.org/creating-bimi-svg-logo-files/) - [Google Workspace Admin Help: BIMI and Gmail](https://support.google.com/a/answer/10911320) - [RFC 9989: DMARC](https://www.rfc-editor.org/rfc/rfc9989.html) - [RFC 8601: Authentication-Results header field](https://www.rfc-editor.org/rfc/rfc8601.html) - [Palisade BIMI checker](/tools/bimi) - [How to convert your company logo to SVG](/learning/bimi-logo-checker) ## Frequently asked questions ### Does a valid SVG Tiny PS file guarantee that my BIMI logo will display? No. A valid public SVG asset establishes file-format evidence. A provider or client can still apply separate authentication, certificate, eligibility, caching, and presentation conditions. ### Can I use any SVG export for BIMI? No. BIMI requires SVG Tiny PS rather than a general-purpose SVG export. Validate the file retrieved from the public `l=` URL, not only the local artwork file. ### Does changing DMARC to p=none fix a BIMI SVG problem? No. Changing `p=` changes the DMARC policy's requested enforcement. It does not repair SVG structure, the hosted response, a VMC or CMC issue, or a mailbox provider's display decision. ### Should I replace the SVG before checking the published URL? No. First preserve the BIMI record, the exact public URL response, and the validator result. If the public URL returns the wrong object or an access error, replacing the local export will not solve the hosting issue. ### Can a BIMI DNS checker prove that Gmail will show my logo? No. A public checker can show the BIMI record visible through DNS. It cannot prove Gmail's private eligibility decision, a particular client's display behavior, or future logo presentation. ### What evidence should I keep after a BIMI retest? Keep the domain, BIMI DNS owner and value, SVG URL, downloaded hash and version, SVG validation result, certificate status when applicable, mailbox and client context, timestamp, retest date, and redacted delivered-message authentication results. --- # What are Gmail and Yahoo error codes and how can I fix them? Canonical: https://www.palisade.email/learning/what-are-gmail-and-yahoo-error-codes-and-how-can-i-fix-them > Gmail and Yahoo error codes explain a temporary or permanent SMTP failure. Preserve the full response, identify its cause, repair it, and retest. Gmail and Yahoo error codes are SMTP responses that tell a sending server why delivery was deferred or rejected. A `4xx` response is temporary and a `5xx` response is permanent for that attempt, but neither numeric code is a complete diagnosis. Preserve the entire response and its sending context, identify the evidence you control, apply the narrowest repair, then retest through the same production path. ## Quick takeaways - A `4xx` SMTP response asks the sending system to retry, while a `5xx` response rejects the delivery attempt. - Gmail and Yahoo use response text alongside numeric and enhanced status codes, so the full response matters more than the number alone. - A Gmail `550 5.7.26` response can indicate different authentication branches, including SPF, DKIM, and DMARC-related failures. - Public DNS checks show published records, not the authentication result of a specific production message. - Receiver reputation and policy decisions are provider-specific. A sender cannot prove or change them through DNS alone. - Do not lower a DMARC policy to conceal an authentication failure. Repair the affected sending path. ## What does the failure mean? SMTP replies tell the sending server whether a recipient system accepted, temporarily deferred, or rejected a message. [Google's SMTP error overview](https://knowledge.workspace.google.com/admin/support/troubleshooting/about-smtp-error-messages) explains that replies beginning with `4` are temporary failures and replies beginning with `5` are permanent failures. A temporary response still needs investigation when it repeats. A permanent response needs a supported correction before retrying the same path. The following is an illustrative redacted response fragment. It shows the evidence pattern to preserve, not a universal Gmail or Yahoo diagnosis. ```text 4xx: temporary SMTP failure 5xx: permanent SMTP failure 550 5.7.26 550 5.7.1 ``` The response class identifies how the receiver handled that delivery attempt. The enhanced status code and explanatory text identify the branch to investigate. [Google's SMTP error reference](https://support.google.com/mail/answer/3726730?hl=en) documents multiple authentication-related conditions under `550 5.7.26`, including messages that do not pass SPF or DKIM checks, SPF hard-fail situations, and unauthenticated mail that Gmail does not accept under the sender domain's DMARC policy. ### Response evidence packet Keep a labelled evidence packet for every repeated Gmail or Yahoo response: - **Complete SMTP response and enhanced status code:** Preserve the exact returned text, including punctuation and links. - **Provider and recipient domain:** Record whether the recipient uses Gmail, Yahoo, or another destination, plus the recipient domain. - **Timestamp and timezone:** Record when the response occurred in a timezone that incident responders can compare with mail logs. - **Sender IP and sending service:** Record the outbound IP and the application, mailbox, ESP, relay, or gateway that submitted the message. - **Authenticated identifiers:** Record the envelope sender, visible From domain, DKIM `d=` domain, DKIM selector, and results from a receiver-added `Authentication-Results` field when available. - **Sending application:** Identify the exact application or workflow that produced the message. - **Recipient scope:** State whether the response affects one recipient, one recipient domain, or an entire sending stream. - **Controlled retry outcome:** Record whether one approved retry later succeeded, deferred again, or received the same permanent response. The full response and context prevent a common mistake: changing a public DNS record because a numeric code sounds authentication-related, when the actual response points to a recipient, route, content, or provider-policy issue. ![Flow showing how to preserve a Gmail or Yahoo SMTP response, classify it, inspect sender-controlled evidence, and retest the same path](/images/editorial/what-are-gmail-and-yahoo-error-codes-and-how-can-i-fix-them/what-are-gmail-and-yahoo-error-codes-and-how-can-i-fix-them-response-evidence-flow.webp "1200x829") *Source: Palisade.* ## What usually causes it? ### Gmail reports an authentication failure under 550 5.7.26 Gmail documents more than one cause under `550 5.7.26`. A message may lack passing SPF and DKIM authentication, fail SPF where the domain publishes a hard-fail `-all` mechanism, or fail Gmail's documented DMARC-related branch for unauthenticated mail. Match the complete Gmail response to [Google's documented SMTP error branch](https://support.google.com/mail/answer/3726730?hl=en) before editing DNS. For DMARC, SPF or DKIM must pass and align with the visible From domain. [RFC 8601 defines `Authentication-Results`](https://www.rfc-editor.org/rfc/rfc8601.html), the header field receiving systems use to communicate message authentication status. The header is stronger evidence than a DNS lookup because it describes the delivered test message. ### Gmail returns 550 5.7.1 for another sender problem `550 5.7.1` is not a universal blocklist verdict. Google's reference documents distinct conditions under this response family, including direct-to-MX restrictions, recipient or domain policy conditions, and IP or [domain reputation](/tools/domain-reputation) signals. Use the explanatory text to select the next action. If the response identifies an unsupported direct connection, review the sending service's supported relay route. If it identifies reputation or a policy condition, inspect the affected stream and compare it with [Google's Gmail sender guidelines](https://support.google.com/a/answer/81126?hl=en). A DNS edit does not prove or alter Google's private reputation assessment. ### Yahoo temporarily defers the message [Yahoo's SMTP error-code reference](https://senders.yahooinc.com/smtp-error-codes/) separates temporary `421` and `451` responses from permanent failures. Yahoo documents temporary categories that can relate to unusual traffic, spam-like characteristics, user complaints, temporary nameserver failures, or temporary authentication evaluation errors. A repeated deferral is evidence to inspect the sending path and retry behavior. It does not prove that an SPF, DKIM, or DMARC record is wrong. ### Yahoo permanently rejects the message Yahoo also documents permanent response categories, but the accompanying text determines whether the issue concerns a connection, a message, a recipient, authentication, or receiver policy. Do not assign one meaning to `553` or `554` when the documented response text is unavailable. The practical conclusion is an operational inference: combine Yahoo's full response with the message evidence before changing configuration. ![Checklist for diagnosing Gmail and Yahoo SMTP errors using response text, authentication results, DNS, sending route, and retry outcome](/images/editorial/what-are-gmail-and-yahoo-error-codes-and-how-can-i-fix-them/what-are-gmail-and-yahoo-error-codes-and-how-can-i-fix-them-gmail-yahoo-error-diagnosis-checklist.webp "1200x639") *Source: Palisade.* ## How do I diagnose the failure? ### 1. Preserve the complete receiver response Export the SMTP transcript or bounce exactly as received. Save the numeric code, enhanced status code, explanatory text, queue ID, timestamp, recipient domain, envelope sender, and sending IP. Do not rely on a mail-client screenshot. The response may identify a sending IP, authentication condition, or policy branch that is absent from the rendered message. ### 2. Classify the reply without treating it as a diagnosis For a `4xx` response, confirm that the mail system follows its normal retry policy. Then determine whether the same response repeats for the same provider, recipient scope, and sending path. For a `5xx` response, pause repeated attempts until you identify the documented cause. Repeating a permanent authentication or recipient error does not repair it. ### 3. Inspect authentication evidence from the same path Send or obtain a delivered test message from the same application, outbound service, envelope sender, visible From domain, and route. Record the receiver-added `Authentication-Results` field, including SPF, DKIM, and DMARC outcomes where present. The [email authentication learning hub](/learning) explains how SPF, DKIM, and DMARC relate. A public DNS record can appear correct while the production sender uses a different envelope domain, DKIM selector, or outbound relay. ### 4. Check only the public record that matches the evidence When a Gmail response identifies an authentication or DMARC branch, use the [DMARC checker](/tools/dmarc) to inspect the published DMARC record for the visible From domain. Compare the lookup with the failed message's headers. A DMARC record has this structural shape: ```text Illustrative only. Do not publish this value without reviewing your reporting and policy requirements. _dmarc.yourdomain.com. TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com" ``` The lookup shows what public DNS returns. It cannot prove why Gmail or Yahoo handled one message a certain way, show every production sender, or reveal a receiver's private policy decision. ### 5. Map the actual sending service Map the route from the sending application through the outbound service, relay, and any gateway to Gmail or Yahoo. Identify which service sets the envelope sender, which service applies DKIM, and whether another service rewrites or relays the message. If SPF hard-fails, compare the sending IP and envelope domain with that envelope domain's SPF record. If DKIM is expected to support DMARC, compare the DKIM `d=` value with the visible From domain. The related guide on [resolving Yahoo and Gmail email error codes](/learning/how-can-you-resolve-yahoo-and-gmail-email-error-codes) can help organize the provider response with sender evidence. ## How do I fix it? ### Repair the authenticated identity identified by Gmail When Gmail's full response identifies missing SPF or DKIM authentication, repair the configuration for the actual sending path. Confirm that the outbound service uses the intended envelope domain and that its DKIM signature is present and valid. For a DMARC-related response, repair the authentication and alignment failure. Changing `p=` to a less strict value changes requested enforcement. It does not repair the sender that failed authentication. > Do not publish an SPF record copied from another tenant or service. Use the value generated for your own sending service, and change SPF only after confirming the envelope domain and authorized senders. ### Correct a recipient or address issue If the response identifies an unknown, disabled, blocked, or otherwise unavailable recipient, correct the address or recipient-side condition through the appropriate owner. SPF, DKIM, and DMARC changes do not fix a recipient-address failure. Retest only with an authorized recipient. Do not use repeated retries to probe an address. ### Treat provider-specific temporary responses as temporary For a documented Yahoo temporary response, preserve the evidence packet, allow the approved queue retry, and reduce or pause the affected stream if your sending platform and provider guidance require it. Check whether the retry succeeds through the same route. Do not turn a temporary response into a permanent diagnosis based only on its first numeric code. If it repeats, collect the full response and consult the provider documentation that matches its text. ### Escalate a persistent provider-policy response with evidence When the same provider-specific response persists after sender-controlled authentication and route checks pass, use the provider's official guidance or support route named in the returned response. Include the redacted response packet and controlled retry outcome. This is appropriate for a receiver policy or reputation decision that public DNS cannot explain. Neither Palisade nor a DNS checker can change a mailbox provider's private reputation or guarantee future acceptance. ## How do I validate the repair? Send a new message through the same application, sending service, envelope sender, visible From domain, and recipient provider that produced the failure. Compare the new SMTP result with the preserved response packet. Validate at each applicable layer: - **DNS:** Query the authoritative DNS source and a public resolver for the record you changed. - **Vendor:** Confirm the outbound service reports the intended authentication configuration, when it provides a verification state. - **Message:** Inspect the raw source of a delivered message and its trusted receiver-added `Authentication-Results` field. - **DMARC:** After reports accumulate, review aggregate-report data for the same sending source and alignment outcome. A passing DNS lookup or vendor indicator is not proof that the production message used the intended configuration. Keep the passing raw message, response comparison, configuration change, and rollback condition in the incident record. ## Check the DMARC record behind an authentication response If the Gmail or Yahoo response points to DMARC or authentication, inspect the visible From domain's published DMARC record before changing policy. Compare the result with the same-path message headers and the exact receiver response. [Check the DMARC record](/tools/dmarc) A public DMARC check cannot identify every sender using the domain, prove why one receiver rejected one message, monitor later changes, or control Gmail's or Yahoo's private policy decisions. Palisade is agentic DMARC software that analyzes DMARC aggregate-report data, identifies sources and authentication or alignment issues, and creates prioritized remediation tickets. It can propose a next policy step for human review, but it does not change a mailbox provider's delivery decision or autonomously change your DMARC policy. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=email_authentication&utm_content=what-are-gmail-and-yahoo-error-codes-and-how-can-i-fix-them) ## Sources and further reading - [Google Workspace Admin Help: About SMTP error messages](https://knowledge.workspace.google.com/admin/support/troubleshooting/about-smtp-error-messages) - [Google Help: SMTP errors and codes](https://support.google.com/mail/answer/3726730?hl=en) - [Google Workspace Admin Help: Email sender guidelines](https://support.google.com/a/answer/81126?hl=en) - [Yahoo Sender Hub: SMTP error codes](https://senders.yahooinc.com/smtp-error-codes/) - [RFC 8601: Authentication-Results header field](https://www.rfc-editor.org/rfc/rfc8601.html) ## Frequently asked questions ### Is a 4xx Gmail or Yahoo error safe to ignore? No. A `4xx` response is temporary for that delivery attempt, but repeated deferrals can indicate a recurring provider-specific condition. Preserve the full response and check whether controlled retries succeed through the same sending path. ### Does Gmail 550 5.7.26 always mean DMARC failed? No. Google documents multiple authentication-related branches under `550 5.7.26`, including SPF and DKIM conditions. Use the full response and receiver-added authentication results to identify the documented branch. ### Does Gmail 550 5.7.1 mean my IP is blocklisted? No. Google documents several conditions under `550 5.7.1`, including connection restrictions, policy conditions, and reputation signals. The accompanying response text determines the next investigation. ### Can a DMARC checker explain a Yahoo rejection? No. A DMARC checker can inspect the public record for the visible From domain. It cannot inspect Yahoo's private receiver policy, authenticate a past message, or prove why Yahoo rejected an individual delivery attempt. ### Should I change DMARC to p=none after a Gmail rejection? No. Lowering the DMARC policy changes requested enforcement but does not repair SPF, DKIM, alignment, a recipient issue, or a provider-specific policy response. Repair the confirmed sending-path problem first. --- # What is URL spoofing and how can I stop it? Canonical: https://www.palisade.email/learning/whatisurlspoofing > URL spoofing uses deceptive web addresses to send people to attacker-controlled sites. Learn how to inspect links and reduce phishing risk safely. URL spoofing is the use of a deceptive web address to make an attacker-controlled website appear trustworthy. The address may imitate a brand, hide the real domain in a subdomain or redirect, or use visually similar characters. Stop it with a layered approach: inspect unexpected links, use browser and mailbox protections, protect accounts with MFA, and use DMARC to reduce email impersonation of domains you control. ## Quick takeaways - A URL's hostname identifies the server a browser contacts, while visible link text can say anything. - In `account.example.com.login-check.badsite.test`, the registered domain is `badsite.test`, not `example.com`. - HTTPS encrypts the connection to a site. It does not prove that the site belongs to the brand named in the URL. - A phishing page can use its own domain and still pass SPF, DKIM, and DMARC for that domain. - DMARC helps prevent unauthorized email that claims to use your real From domain. It does not inspect or block URLs inside messages. - A public URL or DNS check is a point-in-time result. It cannot prove a receiver's private decision or protect future clicks. ## How URL spoofing works A URL has several components. [RFC 3986 defines the URI syntax](https://www.rfc-editor.org/rfc/rfc3986) used for web addresses, including the authority component that contains a hostname. Attackers use the parts people tend to scan quickly, such as a familiar brand name in a subdomain or path, while registering a different domain that they control. For example, this address can look plausible at a glance: ```text https://signin.example-bank.com.account-review.badsite.test/login ``` The hostname ends before the next slash. Read its labels from right to left: the relevant registered domain in this illustrative example is `badsite.test`. `signin.example-bank.com.account-review` is only a subdomain controlled by whoever controls that domain. Other common patterns include: - A typo or character substitution, such as `examp1e.test` instead of `example.test`. - A brand name combined with extra words, such as `example-support.test`. - A shortened or redirected link that conceals the final destination until it opens. - An internationalized domain name that uses characters which resemble Latin letters. [Chrome's IDN display guidance](https://chromium.googlesource.com/chromium/src/+/main/docs/idn.md) describes safeguards that can display suspicious names in an ASCII-compatible form, but visual similarity is still a reason to inspect an unexpected destination carefully. ![Flow showing an unexpected email link being checked for its real destination, then handled through browser and mailbox protections](/images/editorial/whatisurlspoofing/whatisurlspoofing-url-check-flow.webp "1200x676") *Source: Palisade.* A spoofed URL can arrive in email, text messages, chat, ads, or search results. The technique is about the destination, not the delivery channel. That distinction matters when deciding which control can help. ## When URL spoofing changes from suspicious to dangerous An unfamiliar URL is not automatically malicious. A link needs more scrutiny when the message is unexpected, asks for credentials or payment, or directs the recipient to act under time pressure. The [UK National Cyber Security Centre's phishing guidance](https://www.ncsc.gov.uk/collection/phishing-scams) advises people to avoid using contact details supplied in a suspicious message and instead use a known route to contact the organization. Use this decision rule: - If you did not expect the message, do not sign in through its link. - If the message names a company you use, open that company's known app, bookmark, or manually entered address instead. - If you need to inspect a link, identify the hostname before opening it and treat lookalike spelling, unfamiliar suffixes, and misleading subdomains as warning signs. - If a link has already been opened, do not enter credentials. Report it through your organization's process and change passwords only through the legitimate service if credentials were submitted. - If the same brand is repeatedly impersonated, investigate both the spoofed destination and whether attackers are also sending mail that claims to be from your domain. A valid certificate does not change this rule. TLS protects data in transit between a browser and the site it reached. It does not verify that the destination is the organization a recipient expected. ## A worked URL-reading example Consider this illustrative URL: ```text https://microsoft-login.security-review.badsite.test/session?return=portal.example.com ``` The destination hostname is: ```text microsoft-login.security-review.badsite.test ``` The query parameter `return=portal.example.com` does not make the link go to `portal.example.com`. It is data supplied to the destination. Likewise, a familiar name at the beginning of a hostname does not establish ownership of the domain at the end. Inspect the link in this order: - Find the hostname, between `https://` and the next `/`. - Ignore the path and query string until you know who controls the hostname. - Identify the domain registration boundary from the right, using your organization's approved browser, security tooling, or domain-review process. - Compare it with the address you would normally use for that service. - If the link is suspicious, do not use it to authenticate, download software, or provide information. This is a reading method, not a guarantee that a familiar-looking domain is safe. Attackers can compromise legitimate sites, and a newly registered domain can have no public reputation history yet. ## What stops URL spoofing in practice Use controls that address the point where the risk appears. For individual clicks, browsers and mailbox security products can warn on known unsafe destinations. [Google Safe Browsing](https://safebrowsing.google.com/) provides protections used across Google products and Chrome. Organizations using Microsoft 365 can review [Microsoft Defender for Office 365 Safe Links documentation](https://learn.microsoft.com/en-us/defender-office-365/safe-links-about), which describes URL protection and time-of-click checks for supported workloads. For account compromise, require MFA so a captured password is less likely to be enough for an attacker to access an account. For email impersonation, publish and enforce email authentication for domains your organization owns. The [email authentication learning hub](/learning) explains how SPF, DKIM, and DMARC work together. DMARC has a clear boundary in this problem. It can help receivers identify mail that falsely claims to use a protected From domain when the message fails DMARC. It does not examine the destination URL, remove a link from a message, or prevent an attacker from registering and authenticating a lookalike domain. For the broader response process, see [how to stop spoofing attacks](/learning/what-exactly-is-spoofing-and-how-can-you-stop-it) and [what spoofing is and how to stop it](/learning/what-exactly-is-spoofing-and-how-can-you-stop-it). > Do not change a DMARC policy in response to one suspicious link without first reviewing legitimate sending sources and their alignment. A policy change can disrupt real mail that is still failing DMARC. ## Check a suspicious link before opening it If you have an unexpected URL, inspect it with Palisade's phishing link checker before anyone uses it for a login or download. Compare the result with the full message context and your known contact route for the organization. [Check the suspicious link](/tools/phishing-link-checker) A link check cannot prove that a site is safe, explain a mailbox provider's private filtering decision, or prevent a later change to the destination. If the recurring problem is mail impersonating domains you manage, Palisade is agentic DMARC software that analyzes DMARC aggregate-report data, identifies sending sources and authentication or alignment issues, and creates prioritized remediation tickets. It can propose the next policy step when evidence supports it, while your team reviews the evidence and applies the DNS change. It does not block URLs, change a receiver's decision, or autonomously change your DMARC policy. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=existing_content_migration&utm_content=whatisurlspoofing) ## Sources and further reading - [RFC 3986: Uniform Resource Identifier syntax](https://www.rfc-editor.org/rfc/rfc3986) - [Chrome internationalized domain name display guidance](https://chromium.googlesource.com/chromium/src/+/main/docs/idn.md) - [UK National Cyber Security Centre phishing guidance](https://www.ncsc.gov.uk/collection/phishing-scams) - [Google Safe Browsing](https://safebrowsing.google.com/) - [Microsoft Defender for Office 365 Safe Links](https://learn.microsoft.com/en-us/defender-office-365/safe-links-about) ## Frequently asked questions ### Is URL spoofing the same as phishing? No. URL spoofing is a technique that makes a destination appear trustworthy. Phishing is a broader attempt to obtain information, credentials, money, or access through deception. A phishing message may use a spoofed URL, but phishing can also use phone calls, attachments, or other methods. ### Does HTTPS mean a URL is legitimate? No. HTTPS means the browser has established an encrypted connection to the address it reached. It does not establish that the domain belongs to the organization named in the page, email, or link text. ### Can DMARC stop a spoofed website? No. DMARC applies to email authentication and the visible From domain. It can reduce unauthorized email impersonation of domains you control, but it does not inspect web pages or prevent registration of lookalike domains. ### Should I click a suspicious shortened URL to see where it goes? No. Use an approved security tool or inspect the message through your organization's process before opening an unexpected shortened URL. If you need the service named in the message, reach it through a known address instead. ### What should I do if I entered my password on a spoofed site? Change the password through the legitimate service immediately, follow your organization's incident-reporting process, and review active sessions and MFA settings. The exact response depends on the affected service and your organization's security procedures. --- # How do you fix 'Reverse DNS does not match SMTP banner'? Canonical: https://www.palisade.email/learning/reverse-dns-does-not-match-smtp-banner > Reverse DNS does not match SMTP banner means the tested server greeting and PTR hostname differ. Compare the route, repair the owning layer, and retest. `Reverse DNS does not match SMTP banner` means a check reached one SMTP endpoint and found that its opening `220` greeting identifies a different hostname than the PTR record for that IP address. Test the same IP address and port, verify that the PTR hostname resolves back to that IP, then align the SMTP greeting and intended hostname through the teams that own those layers. This warning does not prove a DMARC, SPF, or DKIM failure. ## Quick takeaways - The SMTP banner is the server's opening `220` greeting, not the later `HELO` or `EHLO` command from the client. - Capture the exact public IP address, port, timestamp, and opening greeting before changing DNS or MTA settings. - A PTR hostname and its forward A or AAAA record should resolve to the same public sending IP when sending mail to personal Gmail accounts. - The IP-block owner usually controls PTR records, while the SMTP-service owner controls the greeting. - A matching PTR and banner do not prove message authentication, receiver reputation, or inbox placement. - Changing a DMARC policy does not repair a PTR, forward-DNS, or SMTP-banner mismatch. ## What does the failure mean? An SMTP server starts a session with a `220` greeting. The client sends `HELO` or `EHLO` afterward, so the client identity and the server greeting are separate fields in the SMTP exchange. [RFC 5321's SMTP session sequence](https://www.rfc-editor.org/rfc/rfc5321.html) defines the server greeting separately from the client commands. [cPanel documents this exact warning](https://support.cpanel.net/hc/en-us/articles/1500000922762-Reverse-DNS-does-not-match-SMTP-Banner) as a comparison between the hostname in an SMTP banner and the PTR configuration for the tested IP. Its example concerns Exim, so treat the result as evidence about the endpoint tested, not as a universal receiver rule. ```text Observed health-check warning: Reverse DNS does not match SMTP banner Evidence to collect: public IP, SMTP port, PTR answer, A or AAAA answer, opening 220 greeting ``` The warning shows an identity mismatch for one reachable SMTP path. It does not establish which hostname is correct, whether a message will pass DMARC, whether the IP has a reputation problem, or whether a receiver will place a message in the inbox. It also does not establish a TLS certificate problem. Certificate validation is separate evidence. [DMARC](/learning/what-is-dmarc) evaluates message authentication and identifier alignment. The DMARC policy does not require a particular SMTP banner, so changing `p=` cannot correct this infrastructure warning. ![Flow showing the same SMTP endpoint being checked against its PTR hostname and forward DNS before a controlled retest](/images/editorial/reverse-dns-does-not-match-smtp-banner/reverse-dns-does-not-match-smtp-banner-diagnostic-flow.webp "1200x829") *Source: Palisade.* ## What usually causes it? ### The PTR points to a hostname different from the SMTP greeting This is the direct cause suggested by the warning. For example, the listener can greet with `mail.yourdomain.com` while the tested IP's PTR returns `server.provider.example`. cPanel notes that its Exim SMTP banner normally returns the server hostname, and a differently configured PTR can trigger the warning. The mismatch alone does not say whether the PTR or greeting should change. First determine which public hostname the sending service is intended to use. ### The PTR hostname does not resolve forward to the tested IP A PTR record can exist but still fail forward confirmation. [Google's sender guidelines](https://support.google.com/mail/answer/81126?hl=en) require public sending SMTP IP addresses that send to personal Gmail accounts to have a PTR record whose hostname resolves through A or AAAA DNS to the same public sending IP. This is a separate check from the banner comparison. A greeting can match the PTR hostname while that hostname points forward to another IP address. ### The checker reached a different listener than expected A sending environment can have multiple public IP addresses, SMTP listeners, load balancers, or virtual interfaces. The intended hostname may be configured on one listener while the IP and port named in the warning return another greeting. This is an inference that must be tested with route-specific evidence. Preserve the tested IP, port, and exact opening line before changing a server-wide hostname. ### The reverse-DNS setting is still provider-controlled PTR records use the `in-addr.arpa` and `ip6.arpa` reverse-DNS hierarchy, not the ordinary DNS zone for your domain. [Microsoft's reverse-DNS overview](https://learn.microsoft.com/en-us/azure/dns/dns-reverse-dns-overview) explains that reverse-zone authority follows the assigned IP block or a provider-managed arrangement. Changing an A record in `yourdomain.com` does not update the PTR for a provider-owned public IP. The cloud, hosting, relay, or email provider may need to make the PTR change through its own control plane or support process. ## How do I diagnose the failure? ### 1. Capture the exact endpoint and opening greeting Record the public IP, SMTP port, test time, source of the warning, and complete opening `220` line. If you make a controlled connection, use the same IP address and port identified by the health check. ```bash openssl s_client -connect 192.0.2.25:25 -starttls smtp -crlf ``` The IP address is illustrative only. Do not place production IPs, customer hostnames, credentials, or message content in a shared ticket. Do not substitute an application hostname, outbound trace, or client `EHLO` value from another route. The useful comparison is the greeting emitted by this listener. ### 2. Query the PTR record for that public IP Resolve reverse DNS for the exact tested address: ```bash dig -x 192.0.2.25 +short ``` Save the returned hostname exactly, including a trailing dot if the resolver displays one. If there is no PTR answer, preserve that result. A missing PTR must be addressed before a banner comparison can be meaningful. For background on the record and reverse lookups, see [what a PTR record is](/learning/what-is-a-ptr-record). The relevant answer is the PTR for this sending IP, not a hostname shown in a hosting dashboard. ### 3. Confirm the PTR hostname resolves forward Query the hostname returned by the PTR. Use an A record for an IPv4 sending IP and an AAAA record for an IPv6 sending IP. ```bash dig A mail.yourdomain.com +short dig AAAA mail.yourdomain.com +short ``` For an IPv4 sender, the A response should include the tested IPv4 address. For an IPv6 sender, the AAAA response should include the tested IPv6 address. Check the authoritative DNS response and at least one public resolver. This confirms published DNS, not the live production sending path or a receiver's private decision. ### 4. Build an identity evidence packet Use one labelled packet for the incident. It keeps the route-specific evidence together and makes handoff between DNS, infrastructure, and email teams less ambiguous. ```text Sending IP: 192.0.2.25 Exact PTR owner and returned hostname: provider or reverse-zone owner, mail.yourdomain.com. Forward-confirmation result: A mail.yourdomain.com -> 192.0.2.25 Observed SMTP banner: 220 mail.yourdomain.com ESMTP Observed HELO or EHLO name: client.example, if captured Source and time: health check or controlled connection, UTC timestamp Sending-service owner: internal MTA team or named provider Controlled retest result: same IP and port return matching PTR and banner ``` The values are illustrative only. Redact customer hostnames, recipient details, message content, and account identifiers before sharing the packet. The SMTP banner and client `EHLO` have different roles. Record both when available, but do not treat a client `EHLO` value as proof of the server greeting. ### 5. Identify the owner of each failed layer Assign a responsible owner before editing: - The IP-block owner or its provider controls the PTR or reverse-zone delegation. - The DNS operator controls the forward A or AAAA record. - The local MTA, relay, or load-balancer owner controls the greeting for the tested listener. - The certificate owner controls TLS deployment, which is separate from this warning. Repeat the evidence capture for each IP address and port that produces the warning. A global hostname change is risky when only one listener is affected. ![Comparison card showing an SMTP greeting, PTR hostname, and A-record result that must be checked for the same sending IP](/images/editorial/reverse-dns-does-not-match-smtp-banner/reverse-dns-does-not-match-smtp-banner-identity-evidence.webp "1200x600") *Source: Palisade.* ## How do I fix it? ### Repair the PTR through the IP owner Choose the intended public hostname only after confirming the sending route. Ask the organization that controls the reverse DNS for the tested IP to set the PTR to that hostname. This changes reverse DNS, not message authentication or DMARC enforcement. For a provider-owned IP, use the provider's documented reverse-DNS setting or support process. Do not add a PTR-style record to the normal forward DNS zone and expect it to affect a reverse lookup. > Do not request a PTR change until the intended hostname has a correct forward A or AAAA answer. A reverse record that points to a hostname without forward confirmation can create a different compliance problem. ### Repair a forward-confirmation mismatch If the PTR already names the intended host but its A or AAAA record does not include the tested IP, correct the forward DNS record through the domain's DNS operator. This repair changes forward DNS only. Use the matching address family. Do not remove another address from a multi-address hostname unless the sending architecture confirms it is unused. The requirement is that the PTR hostname resolve to the tested sending IP, not that it have only one address. ### Configure the greeting on the local MTA or listener If your team owns the SMTP listener and the PTR is the intended hostname, configure that listener to present the same hostname in its opening greeting. Confirm the setting applies to the exact interface and port in the evidence packet. A local MTA hostname change can affect other listeners and mail flows. Test it in an approved scope, keep the previous configuration available, and verify that every expected sending path still reaches the intended listener. This repair changes the SMTP greeting, not the PTR, DMARC policy, or receiver reputation. ### Escalate a provider-controlled banner safely If a relay, cloud platform, or hosted email service produces the banner, do not attempt to modify a provider-controlled host. Send the provider the redacted identity evidence packet and ask which public hostname it supports for the tested IP and port. A provider may use shared IP space or a provider hostname by design. The provider's answer determines whether a customer-controlled PTR is possible. Do not claim a mismatch is repaired until the same endpoint returns the expected values. ## How do I validate the repair? Repeat the same check against the same public IP address and SMTP port. Capture the new `220` greeting, query the PTR again, and query the corresponding A or AAAA record. Update the identity evidence packet with the controlled retest result. For mail sent to personal Gmail accounts, confirm that the PTR hostname resolves forward to the same public sending IP as required in [Google's sender guidelines](https://support.google.com/mail/answer/81126?hl=en). Then send a new message through the affected production path and retain the received message's trusted `Authentication-Results` header if message authentication is also in scope. A passing DNS and banner test does not prove that all production mail uses that listener, that every message authenticates, or that a receiver will accept or place future mail. For broader transport controls and related checks, use the [email transport security learning hub](/learning/infrastructure). ## Continue monitoring the sending paths behind the warning After the repair, use the [Email Security Score](/tools/email-security-score) to inspect the domain's public email-security configuration. Compare its public findings with the route-specific PTR, forward-DNS, and SMTP evidence you collected. A public score cannot prove the production SMTP route, a receiver's policy decision, or future delivery. If the unresolved problem is recurring visibility into which sources send for one or more domains, [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=email_transport_security&utm_content=reverse-dns-does-not-match-smtp-banner). Palisade's DMARC Agent analyzes DMARC aggregate-report data, identifies sending sources and authentication or alignment issues, and creates prioritized remediation tickets for review. It does not change PTR records, MTA identity, DMARC policy, or a receiver's private reputation decision. ## Sources and further reading - [RFC 5321: Simple Mail Transfer Protocol](https://www.rfc-editor.org/rfc/rfc5321.html) - [Google Email sender guidelines](https://support.google.com/mail/answer/81126?hl=en) - [cPanel: Reverse DNS does not match SMTP Banner](https://support.cpanel.net/hc/en-us/articles/1500000922762-Reverse-DNS-does-not-match-SMTP-Banner) - [Microsoft Azure DNS reverse DNS overview](https://learn.microsoft.com/en-us/azure/dns/dns-reverse-dns-overview) - [Palisade Domain Overview documentation](https://docs.palisade.email/page-breakdowns/domain-overview/) ## Frequently asked questions ### Does a reverse-DNS and SMTP-banner mismatch mean DMARC fails? No. The warning compares infrastructure identity for an SMTP endpoint. DMARC evaluates SPF and DKIM results and their alignment with the visible From domain. ### Can I fix this by changing the DMARC policy to `p=none`? No. Changing `p=` changes requested DMARC enforcement. It does not change the PTR record, the forward DNS record, or the SMTP greeting. ### Does the SMTP banner need to match the client's EHLO name? No. The SMTP banner is sent by the server at connection start. `HELO` and `EHLO` are later commands sent by the client and can be recorded as separate evidence. ### Can I create the PTR record in my normal DNS zone? Only if you control the delegated reverse DNS for the public IP block. Most domain DNS zones do not control the relevant `in-addr.arpa` or `ip6.arpa` reverse zone. ### Does a matching PTR and banner guarantee inbox placement? No. A match can resolve this identity warning and support valid reverse-DNS configuration. It does not prove message authentication, IP reputation, receiver policy, or inbox placement. --- # Why is my email queued and how do I fix it? Canonical: https://www.palisade.email/learning/why-is-my-email-queued-and-how-do-i-fix-it > Why is my email queued? Find the queue location, capture the SMTP response, repair the documented condition, and validate the same delivery path. `Queued` means an email is waiting before final acceptance by the recipient mail server. It may still be in a local outbox, or a sending mail transfer agent (MTA) may be retrying after a temporary SMTP response. Find the queue owner and preserve the exact SMTP response first. Then repair the condition that response identifies and retest through the same application, relay, and recipient path. ## Quick takeaways - `Queued` is a state, not a complete diagnosis. - An SMTP response beginning with `4` is temporary, so the sending MTA should retain and retry the message. - A queue ID, destination host, and exact SMTP response are stronger evidence than a mail client's `Queued` label. - A public MX lookup can show a recipient domain's published route, but cannot prove receiver availability or a private filtering decision. - Do not change the [DMARC policy](/learning/what-is-dmarc) to solve an SMTP queue condition. - Recipient-server acceptance ends the SMTP delivery attempt, but does not guarantee inbox placement or reader visibility. ## What does the failure mean? The visible symptom is: ```text Queued ``` `Queued` alone does not identify the failure. It can mean an email client or application has not submitted a message to SMTP. It can also mean that a sending MTA accepted the message and retained it for a later delivery attempt. [SMTP defines replies beginning with `4` as transient negative completion replies](https://datatracker.ietf.org/doc/html/rfc5321#section-4.2.1). The sender should retain the message and retry because the condition may clear. Replies beginning with `5` are permanent negative completion replies, so retrying that same delivery attempt is not the normal remedy. Keep these states separate: - A local queue condition means the client or application has not handed the message to the sending SMTP service. There may be no queue ID, MX attempt, or recipient SMTP response. - A remote temporary response means the sending MTA reached a recipient system and recorded a `4xx` response. The MTA should retry according to its configured schedule. - Final recipient-server acceptance means the recipient SMTP server accepted the transaction. It does not prove later mailbox placement or reader visibility. Authentication evidence can matter in a separate failure investigation, but it does not replace SMTP queue evidence. [RFC 8601 defines the `Authentication-Results` header field](https://www.rfc-editor.org/rfc/rfc8601.html), while the queue entry records whether the sending system reached and completed the SMTP delivery attempt. ![Flow separating a local outbox, a temporary SMTP deferral, and recipient-server acceptance](/images/editorial/why-is-my-email-queued-and-how-do-i-fix-it/why-is-my-email-queued-and-how-do-i-fix-it-queue-state-flow.webp "1200x676") *Source: Palisade.* ## What usually causes it? ### The recipient server returned a temporary SMTP response This is the most likely cause when the queue log includes a `4xx` response. SMTP treats that response as a condition that may be corrected by retrying later. The full response text and any enhanced status code can distinguish a service issue from a response tied to a recipient policy. Do not infer the cause from `Queued` without the response. The response separates a remote delivery deferral from an unsent local message. ### The recipient system is temporarily unavailable A receiving server can defer delivery when it cannot complete the SMTP transaction. SMTP reserves transient replies for conditions that may clear, and the sending MTA should retain the message for later attempts. Treat this as recipient-side only when the response identifies a remote availability condition. Changing SPF, DKIM, DMARC, or sender DNS without supporting evidence does not repair a temporary recipient outage. ### The recipient is greylisting the sending path [Greylisting temporarily refuses a message and expects a legitimate sender to retry](https://datatracker.ietf.org/doc/html/rfc6647). A correctly configured sending MTA retries, and a later attempt may succeed. Greylisting is an inference unless the response itself or recipient documentation identifies it. Do not add aggressive retries or bypass retry controls based only on a queue label. ### The sender has a local transport or configuration failure A sending system can retain messages when it cannot reach its configured relay, resolve a required destination, establish the required connection, or submit mail from the application. This branch is more likely when the log names a local relay, connection, DNS-resolution, or configuration error rather than a response from the recipient system. A public MX lookup cannot diagnose local SMTP credentials, relay configuration, or an application that never submitted its message. ### The recipient repeatedly defers this sender or message class A recipient can defer traffic based on its own operational or policy decisions. The response may identify a published requirement, but a public DNS or reputation check cannot reveal the receiver's private decision process. If the queue response points to authentication, investigate it as a separate documented cause. The [email authentication failure guide](/learning/authentication-failed-email) covers mailbox and SMTP login failures. Do not assume an authentication problem caused one queued message without evidence from the recipient response, message headers, or the sending system. ## How do I diagnose the failure? ### 1. Identify where the message is queued Confirm whether the message has a server-side queue entry. If it has a queue ID and delivery-attempt record, follow the SMTP branch. If it has no server-side evidence, inspect the local outbox, account connection state, application logs, and submission settings. Do not use a recipient MX lookup to investigate a message that never reached the sending SMTP service. ### 2. Capture the complete queue evidence packet Collect the evidence before forcing a retry or changing controls. Redact recipient addresses, content, credentials, tokens, and customer data in shared tickets. Keep an access-controlled original for the incident. Record these fields: - Sending system or MTA: the application, relay, or MTA that owns the queue. - Queue ID: the identifier for this delivery attempt. - Timestamp and age: the latest attempt time in UTC and how long the message has been queued. - Recipient scope: the recipient domain, destination host, and whether one or many recipients are affected. - Exact SMTP response: the numeric reply, enhanced status code when present, and response text. - Retry state: attempts made, next attempt, expiry behavior, and whether the MTA is still retrying. - Source IP: the IP address used for the outbound SMTP attempt when the MTA records it. - TLS and authentication context: details from the log when available. - Message ID: the application or RFC message identifier that links the queue entry to the message. This is an illustrative redacted shape: ```text MTA: outbound-relay.example Queue ID: REDACTED-QUEUE-ID Message-ID: <REDACTED@yourdomain.com> Attempt time: 2026-08-12T11:34:00Z Queue age: 00:18:42 Recipient scope: recipient.example via mx.recipient.example Source IP: 192.0.2.25 TLS context: negotiated, details retained in MTA log SMTP response: 421 4.7.0 <copy the exact recipient response here> Retry state: deferred, next attempt scheduled by MTA ``` ### 3. Isolate the affected recipient scope Check whether the same sending path queues mail for one recipient, one recipient domain, or many domains. A single deferred domain points toward that destination's route or policy. A failure across unrelated domains points more strongly toward the sending application, relay, network path, or local configuration. Compare like with like. Use the same application, sender identity, relay, and message type where possible. A different application can use a different relay or authentication path and produce misleading results. ### 4. Check the published recipient route when the log names a destination When the queue entry identifies a recipient domain or destination hostname, compare it with that domain's current public MX records. The [Palisade DNS lookup tool](/tools/dns-lookup) can inspect the published DNS for the recipient domain. A public lookup does not prove that the recipient server was available at the failure time, reveal its private policy decision, or establish why an individual message was deferred. ### 5. Separate remote deferrals from local transport failures A temporary remote deferral has a recipient SMTP response, remote host, and retry state. Let the MTA retry when the response describes a transient condition. A local transport or configuration failure is different. Inspect relay configuration, application submission logs, local DNS resolution, connection errors, and credentials only within the system that owns the queue. Repair the documented local failure, then submit a new message through the same application and relay. ### 6. Check the next retry outcome Record whether the next scheduled attempt receives the same response, a new response, or final acceptance. Repeated identical `4xx` responses narrow the incident to the condition named by the recipient. A change in response can show that the original condition cleared or that another stage now blocks delivery. Do not convert a temporary response into a permanent diagnosis until the MTA reaches its configured expiry behavior or the recipient documents a persistent requirement. ![Checklist showing the evidence needed to diagnose a queued email before changing mail settings](/images/editorial/why-is-my-email-queued-and-how-do-i-fix-it/why-is-my-email-queued-and-how-do-i-fix-it-email-queue-diagnosis-checklist.webp "1200x639") *Source: Palisade.* ## How do I fix it? ### Let the MTA retry a confirmed temporary recipient condition When the queue entry records a `4xx` response and the MTA has a normal retry schedule, allow the scheduled retry to run. This addresses delivery timing only. It does not alter authentication, alignment, reporting, or DMARC enforcement. > Do not delete a queued message or force repeated manual sends before preserving the SMTP response. You can lose the evidence needed to distinguish a remote deferral from a local failure. ### Repair the documented local transport failure When the queue owner reports a local relay, DNS-resolution, connection, or submission failure, correct only that documented configuration or transport condition. Verify that the application can submit to its intended SMTP service, then send one controlled test through the same path. Keep a rollback path for any relay or routing change. A broad routing change can interrupt mail for applications that were not part of the incident. ### Correct an authentication requirement only when the response supports it If the recipient response or message evidence identifies an authentication requirement, repair the named sending identity or authentication path before retesting. Use the recipient's documented requirement where available. The [Gmail unauthenticated sender troubleshooting guide](/email-deliverability/gmail-blocked-sender-is-unauthenticated) applies when Gmail provides that specific failure. This repair changes authentication. It is separate from SMTP retry behavior, and it does not guarantee recipient acceptance or inbox placement. ### Escalate a persistent recipient-side deferral with the evidence packet When the same destination repeatedly defers mail and the response does not give a repair path, provide the recipient provider or internal mail team with the queue ID, timestamps, source IP, exact responses, and affected-recipient scope. Do not send unredacted message content or credentials. The recipient controls its own operational and policy decisions. A sender-side DNS check cannot override that decision. ## How do I validate the repair? Send a new controlled message through the same application, outbound relay, sender identity, and recipient domain that produced the queue entry. Confirm that the sending MTA records the new SMTP outcome. If the original problem was local, confirm the application now submits successfully before interpreting remote delivery results. Validate each applicable layer: - DNS: if the repair involved a public record or recipient route, check the authoritative DNS result and at least one public resolver. - Vendor or sending service: confirm the service's current status when the service provides an authentication or configuration result. - Message: inspect the receiver-side copy or trusted receiver-added headers for the exact test message when it is delivered. - DMARC: after data accumulates, review aggregate reports for the relevant production source. A passing test does not prove every future source or message path will authenticate. A recipient server's SMTP acceptance does not prove inbox placement. If the email is accepted but absent from the mailbox, use the recipient's message trace or provider tools and follow the evidence. The [bounce-back email guide](/learning/bounce-back-email) can help separate a completed SMTP response from a later reported delivery problem. ## Check the sender domain after a queue incident If a recipient response points to sender authentication, inspect the sending domain's published [DMARC record](/tools/dmarc) before changing policy. A record check is useful after you have queue evidence, but it cannot diagnose a local outbox, identify a recipient's private deferral reason, or prove why one queued message was delayed. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=email_deliverability&utm_content=why-is-my-email-queued-and-how-do-i-fix-it) Palisade is agentic DMARC software that analyzes DMARC aggregate-report data, identifies sending sources and authentication or alignment issues, and creates prioritized remediation tickets. It does not control a recipient server's temporary SMTP response, change a recipient's private policy decision, or guarantee future delivery. ## Sources and further reading - [RFC 5321 section 4.2.1: SMTP reply codes](https://datatracker.ietf.org/doc/html/rfc5321#section-4.2.1) - [RFC 6647: SMTP greylisting](https://datatracker.ietf.org/doc/html/rfc6647) - [RFC 8601: Authentication-Results header field](https://www.rfc-editor.org/rfc/rfc8601.html) - [Palisade DNS lookup tool](/tools/dns-lookup) ## Frequently asked questions ### Is a queued email the same as a bounced email? No. A queued email is still awaiting a delivery attempt or retry outcome. A bounce normally reports that a delivery attempt failed, often with an SMTP response that identifies whether the failure is temporary or permanent. ### Should I resend an email that is queued? Only after you capture the queue evidence and understand the queue owner. Resending can create duplicate messages if the original MTA later completes delivery. ### Can an MX lookup fix a queued email? No. An MX lookup shows published recipient routing. It cannot repair a local SMTP configuration, prove a recipient server was available, or reveal the recipient's private filtering decision. ### Does changing DMARC to p=none fix a queued email? No. Changing `p=` changes requested DMARC enforcement. It does not repair an SMTP connection, recipient deferral, local relay failure, or application submission problem. ### How long should an email remain queued? Only the sending MTA's configured retry and expiry behavior determines that period. Check its queue record for the next attempt and expiry state, then use the exact SMTP response to decide whether the condition needs a repair or escalation. --- # DKIM fail: body hash did not verify, and how to fix it Canonical: https://www.palisade.email/learning/dkim-fail-body-hash-did-not-verify > This error means the message body changed after it was signed. Here are the five things that alter it in transit, and how to find which one is yours. `DKIM fail body hash did not verify` means the receiver calculated a different hash for the canonicalized message body than the `bh=` value in the DKIM signature. Start with the raw message that failed, identify where DKIM signing happened, then compare it with the path after signing. Repair the confirmed body change, or sign after that change, and resend through the same production route. ## Quick takeaways - `bh=` contains the hash of the canonicalized message body, while `b=` contains the DKIM signature data. - `dkim=fail (body hash did not verify)` identifies a body-hash mismatch for one signature, not the system that caused it. - A valid DKIM public key does not repair a message body changed after signing. - Footers, MIME rewrites, transfer-encoding changes, and mailing-list processing are possible causes until raw-message evidence confirms one. - The receiver-added `Authentication-Results` field and the corresponding `DKIM-Signature` header are the strongest starting evidence. - Validate the repair with a new message through the same application, route, and content format. ## What does the failure mean? [RFC 6376 defines `bh=` as the hash of the canonicalized message body and requires a verifier to compare its calculated hash with that tag](https://www.rfc-editor.org/rfc/rfc6376.html). When the values differ, the DKIM signature does not verify. A [Microsoft Learn support discussion documents the exact `dkim=fail (body hash did not verify)` result](https://learn.microsoft.com/en-nz/answers/questions/2237197/dkim-fail-%28body-hash-did-not-verify%29). That thread is provider-context evidence for the symptom, not an explanation for every failed message. ```text Authentication-Results: mx.receiver.example; dkim=fail (body hash did not verify) header.d=example.com header.s=selector1; spf=pass smtp.mailfrom=example.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=example.com; s=selector1; h=from:to:subject:date; bh=BASE64_BODY_HASH_EXAMPLE=; b=BASE64_SIGNATURE_EXAMPLE= ``` This is illustrative and redacted. Do not publish live message headers, account-generated selector values, private keys, tokens, or customer content. The `bh=` and `b=` tags have different jobs. `bh=` is calculated from the canonicalized body. `b=` is signature data for selected headers. A body-hash mismatch means the verifier did not get the same canonicalized body that the signer hashed. It is separate from a DMARC alignment issue, where a valid DKIM signature's `d=` domain does not align with the visible From domain. For related protocol guidance, visit the [email authentication learning hub](/learning). ![Flow showing DKIM signing, a later body modification, and a receiver calculating a different body hash](/images/editorial/dkim-fail-body-hash-did-not-verify/dkim-fail-body-hash-did-not-verify-body-hash-flow.webp "1200x676") *Source: Palisade.* ## What usually causes it? ### Content changed after signing A body change after signing can create this failure because DKIM hashes the canonicalized body. A disclaimer, footer, tracking insertion, rewritten link, or template transformation can matter when it occurs after the signer. [RFC 6376 canonicalization and body-hash rules](https://www.rfc-editor.org/rfc/rfc6376.html) explain the mechanism. The conclusion that a specific hop changed a particular message is an inference. Confirm it by comparing raw messages before and after that hop. `Received` fields help map the route, but they do not prove a body modification. ### An intermediary rewrote MIME or encoding A gateway, mailing list, forwarding service, or content-scanning service can alter MIME boundaries, transfer encoding, line endings, or message content. Those changes can affect the bytes used for the body hash even when the rendered email looks unchanged. The Microsoft support discussion associates the failure with a disclaimer added after signing. Treat that as one documented scenario, not a universal diagnosis. ### The signer hashed different content from what it transmitted [RFC 6376 defines the `simple` and `relaxed` canonicalization algorithms and records the selected algorithm in `c=`](https://www.rfc-editor.org/rfc/rfc6376.html). If the signing system hashes one serialized message but sends another, the receiver calculates a different result. This cause becomes more likely when controlled captures show no later service changed the message. Review the signing implementation, MIME generation, line endings, and exact message bytes supplied to the signer. ### The signature uses a body-length limit The optional `l=` tag states how many canonicalized body octets are included in the hash. [RFC 6376 warns about the security consequences of limited body length](https://www.rfc-editor.org/rfc/rfc6376.html). Do not add `l=` to accommodate a footer or another rewrite. Remove the confirmed rewrite or place it before signing. ### The evidence came from another path A forwarded, resent, or list-modified copy can differ from the production message that first failed. Use the full raw source containing the exact result. Rendered mail views can hide whitespace, encoded content, and MIME structure that affect DKIM verification. ## How do I diagnose the failure? ### 1. Preserve the receiver's message evidence Save the raw source of the failed message. [RFC 8601 defines `Authentication-Results` as an authentication-service field within a trust boundary](https://www.rfc-editor.org/rfc/rfc8601.html), so prioritize the result added by the receiving system over an older copied header. Record the Message-ID, delivery time, sending application, outbound route, `d=`, `s=`, `c=`, `bh=`, and any `l=` tag. Keep the exact `dkim=fail (body hash did not verify)` result with the incident record. Redact recipients, message content, tokens, and customer data before sharing evidence outside the team. ### 2. Map the signing point and every later hop Identify the system that added the affected `DKIM-Signature`. Then list every service that handled the message afterward. ```text application -> outbound MTA -> disclaimer gateway -> recipient signs? changes body? verifies? ``` Read `Received` fields from bottom to top, then verify the route with mail logs and configuration records. A route-specific failure can indicate a later modification, but controlled raw-message comparison confirms the cause. ### 3. Send controlled same-path tests Send a new minimal message through the normal production path and retain the receiver's raw source. If operationally approved, send the same content through a route that bypasses one suspected modifier. Compare raw sources, not mail-client screenshots. Add production variables one at a time: HTML templates, disclaimers, rewritten links, attachments, and normal content encoding. A passing plain-text message does not prove the production template passes. ![Decision flow for comparing the normal message route with a controlled bypass and moving DKIM signing after a confirmed mutation](/images/editorial/dkim-fail-body-hash-did-not-verify/dkim-fail-body-hash-did-not-verify-diagnosis-flow.webp "1200x829") *Source: Palisade.* ### 4. Check the published selector separately Use the [Palisade DKIM checker](/tools/dkim) with the `d=` domain and `s=` selector from the failed signature. This checks whether a public DKIM record is available at that selector owner name. A missing or incorrect selector record is a separate DNS or key-configuration problem. It does not prove that a body-hash mismatch disappeared. A public DKIM lookup cannot inspect the delivered message body, private key, signing implementation, intermediary changes, a receiver's private filtering decision, or future delivery outcomes. ## How do I fix it? ### Sign after the final required body mutation When a required gateway adds a disclaimer, transforms links, or makes another confirmed body change, configure DKIM signing after that final change. The new `bh=` value then covers the message body sent onward. > Do not loosen the DMARC policy as a workaround. Changing `p=` changes requested DMARC enforcement. It does not change the message body or repair DKIM verification. Confirm that every intended outbound route reaches the final signer. Moving signing to one gateway can leave another application route unsigned if it bypasses that gateway. ### Remove the confirmed post-signing rewrite If the body modification is unnecessary, disable only the confirmed post-signing transformation. Retest with the production template, not only a plain-text test message. Keep the previous configuration available for rollback. If removing the transformation changes a legal disclaimer, security control, or customer-facing template, involve the control owner before making the change. ### Correct the signing implementation If the signer creates a mismatch before any downstream system handles the message, review its canonicalization, MIME generation, line endings, transfer encoding, and body-length behavior against [RFC 6376 DKIM signing and verification requirements](https://www.rfc-editor.org/rfc/rfc6376.html). Change one component at a time. A signer replacement or configuration change should have a rollback plan, especially where multiple outbound applications rely on the same service. ### Keep DMARC policy changes separate A change to `p=` affects DMARC enforcement requested by the domain owner. It does not repair the body mismatch or make the failed DKIM signature pass. Keep the technical repair focused on the signer or the confirmed post-signing transformation. ## How do I validate the repair? Repeat the same route that produced the failure. Use the same application, outbound gateway, recipient provider, and content format. Test the production template, including any footer, attachment, link rewriting, and encoding behavior that appeared on the failed message. Check four layers: - DNS: confirm the selector record resolves through the authoritative DNS service and at least one public resolver. - Vendor: confirm the sender or gateway reports its expected DKIM configuration state, where that status exists. - Message: inspect the newly received raw source and confirm the trusted receiver-added result reports `dkim=pass` for the intended signature. - DMARC: after reports accumulate, review aggregate data for the same sending source and confirm the passing signature can align with the visible From domain when DMARC depends on DKIM. A green vendor status is not proof that the delivered message was signed correctly. A public record lookup is not proof that the production application used that selector. Keep the passing message, path map, relevant logs, and change record with the incident. ## Check the DKIM selector after the same-path retest After repairing the body change, [check the published DKIM selector](/tools/dkim) used by the failed signature. This helps rule out a separate public-key or DNS issue while you compare the newly delivered message. A DKIM lookup cannot identify the system that changed this message body, inspect the private key, monitor every sending route, or guarantee future receiver behavior. If the production path has multiple senders or later DNS drift is a concern, Palisade is agentic DMARC software that analyzes DMARC aggregate-report data, identifies authentication and alignment issues, and creates prioritized remediation tickets for human review. Learn more about [DMARC monitoring and reporting](/learning/dmarc). [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=dmarc_troubleshooting&utm_content=dkim-fail-body-hash-did-not-verify) ## Sources and further reading - [RFC 6376: DomainKeys Identified Mail Signatures](https://www.rfc-editor.org/rfc/rfc6376.html) - [RFC 8601: Authentication-Results header field](https://www.rfc-editor.org/rfc/rfc8601.html) - [Microsoft Learn discussion of DKIM body-hash verification failure](https://learn.microsoft.com/en-nz/answers/questions/2237197/dkim-fail-%28body-hash-did-not-verify%29) - [Palisade DKIM checker](/tools/dkim) ## Frequently asked questions ### Can DNS propagation cause a body-hash failure? No. A missing or stale DKIM public key creates a key retrieval or signature verification issue. `body hash did not verify` describes a mismatch between the received canonicalized body and the `bh=` value. ### Will changing DMARC to `p=none` fix DKIM? No. Changing `p=` changes requested DMARC enforcement. It does not change the message body, DKIM signature, or body-hash verification result. ### Can a mailing-list footer break DKIM? Yes. A mailing-list footer can break DKIM when it changes content covered by the signature. Confirm that cause by comparing the raw message before and after the list processor. ### Should I regenerate the DKIM key first? No. Regenerating a key does not repair a confirmed body change. Rotate a key only when separate evidence shows that the key needs replacement. ### Can a passing DKIM record lookup prove the repair worked? No. A DKIM lookup can confirm that a public key is published for a selector. It cannot prove that the production sender used that selector or that the delivered message body remained unchanged after signing. --- # Check the Spamhaus blacklist: identify and fix a listing Canonical: https://www.palisade.email/learning/check-spamhaus-blacklist > Check the Spamhaus blacklist, identify the listed IP or domain, follow the correct remediation path, and validate a clean sending result safely. To check the Spamhaus blacklist, submit the exact public IP address or domain named in the delivery failure to [Spamhaus's IP and Domain Reputation Checker](https://check.spamhaus.org/). Record the named blocklist, the resource owner, and the result time before fixing the documented cause and following the list-specific removal route. A clean result is a point-in-time signal from Spamhaus. It does not prove all reputation status, inbox placement, or a receiver's private filtering decision. ## Quick takeaways - Spamhaus calls its datasets blocklists, although "blacklist" remains a common search term. - Check the public egress IP or domain named in the rejection, not only the visible From domain. - A ZEN result must be traced to its component list: SBL, CSS, XBL, or PBL. - A PBL listing can describe an IP range's mail-sending policy rather than spam activity. - The correct remediation owner may be your mail team, ISP, ESP, host, security team, or domain owner. - Recheck the same resource, then test a new message through the same production sending path. ## What this tool checks The official [Spamhaus IP and Domain Reputation Checker](https://check.spamhaus.org/) accepts public resources such as IP addresses and domains and returns the current Spamhaus result for the submitted resource. For a delivery incident, start with what the receiving server actually identified. If the rejection names an IP address, check the public IP that connected to the recipient. If it names a domain, check that domain. The Checker cannot inspect SMTP logs, determine which service sent a particular message, access a receiving provider's private filters, or prove that the IP or domain entered is on the production path. A public lookup also does not continuously monitor the resource or guarantee future delivery. For broader context on recipient-side failures, use the [email deliverability learning hub](/email-deliverability). Keep a labelled evidence record before changing anything: ```text Spamhaus lookup evidence, illustrative only Resource checked: 192.0.2.44 Resource type: Public sending IP Source/list: Spamhaus Checker, CSS Observed result: Listed Lookup time: 2026-08-12T16:00:00Z Sending service or host: Example outbound relay Mail-log or bounce fact: "550 5.7.1 [192.0.2.44] listed by Spamhaus" Owner to confirm: Mail operator or network provider ``` > Use values from your own incident only. Do not copy another organization's IP address, domain, HELO name, PTR hostname, verification code, ticket reference, account email, or mail-log content. This record separates observed evidence from conclusions. A listed result means Spamhaus reported that resource on the named list at lookup time. An unlisted result means that particular lookup did not report a Spamhaus issue then. Neither result proves the full reputation state of every sending path or recipient. ![Decision flow for recording a Spamhaus result and choosing the responsible owner](/images/editorial/check-spamhaus-blacklist/check-spamhaus-blacklist-listing-flow.webp "1200x676") *Source: Palisade.* ## How to run the check ### 1. Preserve the rejection and map the sending path Save the original delivery status notification or SMTP log before attempting a fix. Record the diagnostic text, time, sending application, relay, public egress IP, envelope sender, and visible From domain. The public IP can belong to an ESP, cloud host, security gateway, or shared relay rather than your organization. Confirm ownership before changing mail settings or contacting Spamhaus. A generic SMTP `550` response does not establish that Spamhaus caused the failure. ### 2. Identify the exact IP or domain to submit Use the connecting public IP when the rejection names an IP address. Use the named domain when the failure or Checker result identifies a domain. [Spamhaus's DBL documentation](https://www.spamhaus.org/blocklists/domain-blocklist/) explains that DBL can apply to domains used in message content, headers, the envelope sender, or HELO. For shared infrastructure, identify the provider and account path first. Do not change DNS or mail routing for a provider-owned IP range unless the provider directs you to do so. ### 3. Run one lookup in the Spamhaus Checker Open the [Spamhaus IP and Domain Reputation Checker](https://check.spamhaus.org/) and enter one exact resource. Save the result page with the named list, explanatory text, and official next action. ![Spamhaus IP and Domain Reputation Checker input state](/images/editorial/check-spamhaus-blacklist/spamhaus-checker-input-live.jpg "1728x940") *Source: [Spamhaus IP and Domain Reputation Checker](https://check.spamhaus.org/), checked 2026-07-27.* ### 4. Confirm public DNS evidence for an IP-list result For an IP-list incident, query the reverse-IP form used by Spamhaus ZEN. This is a repeatable public lookup, but the Checker remains the place to obtain the list-specific explanation and remediation route. ```bash dig +short 44.2.0.192.zen.spamhaus.org A ``` The command reverses the illustrative IP `192.0.2.44`. Replace it with the public IP from your own mail evidence. Do not publish customer IP addresses unless your organization has approved that disclosure. ## How to interpret the results ### The Checker reports no issues A clean result means Spamhaus did not report an issue for the submitted resource at that time. The public result below illustrates this state for `8.8.8.8`. It does not establish the result for another IP, domain, or later lookup. ![Spamhaus Checker result showing no issues for public IP 8.8.8.8](/images/editorial/check-spamhaus-blacklist/spamhaus-8-8-8-8-no-issues.jpg "1728x996") *Source: [Spamhaus IP and Domain Reputation Checker result for 8.8.8.8](https://check.spamhaus.org/results?query=8.8.8.8), checked 2026-07-27.* If the bounce continues, compare the exact rejection text with a new message sent through the same application, relay, public IP, and recipient path. The cause may be a different reputation source, a receiver policy, or a path mismatch. Inspect the recipient's available diagnostic evidence before concluding that Spamhaus cleared the incident. ### The result identifies PBL [Spamhaus's Policy Blocklist documentation](https://www.spamhaus.org/blocklists/policy-blocklist/) describes PBL as end-user IP ranges that should submit mail with authentication to an SMTP server that performs final delivery. Spamhaus states that a PBL-listed IP is not necessarily bad. The usual repair is to send through the authorized authenticated relay for that range. A static outbound server may qualify for a single-IP exclusion only when it meets Spamhaus's applicable requirements. ISP ranges and wider provider changes belong to the range owner. ### The result identifies CSS, SBL, or XBL [Spamhaus ZEN documentation](https://www.spamhaus.org/blocklists/zen-blocklist/) states that ZEN combines SBL, CSS, XBL, and PBL. Treat the returned component list as the diagnosis route. For CSS, use [Spamhaus's Checker troubleshooting guidance](https://www.spamhaus.org/resource-hub/ip-and-domain-reputation-checker/spamhaus-reputation-checker-troubleshoot-your-listing/). Its CSS workflow checks recent HELO, PTR, forward resolution, and whether those identities agree. Apply those checks to the affected IP only. For SBL, the controlling ISP, ESP, or network owner must stop the abuse and submit the removal request. Spamhaus directs end users who do not control the listed resource to their system administrator, ISP, or ESP in its [blocklist FAQ](https://www.spamhaus.org/faqs/spamhaus-blocklist/). For XBL, the owner must close the exploit or proxy condition before using the official remediation path. A removal request does not repair a compromised host. ### The result identifies DBL A DBL result concerns the submitted domain. It does not necessarily identify the IP that delivered the message. Investigate the domain-owner path: website content, redirects, DNS changes, account access, unexpected subdomains, and links in current campaigns. The published `dbltest.com` result illustrates a DBL test result and an SBL ownership warning. It is not a diagnosis template for your own domain. ![Spamhaus Checker DBL test result with SBL ISP-ownership warning](/images/editorial/check-spamhaus-blacklist/spamhaus-dbltest-listing-live.jpg "1728x971") *Source: [Spamhaus IP and Domain Reputation Checker result for dbltest.com](https://check.spamhaus.org/results?query=dbltest.com), checked 2026-07-27.* ## When this does not apply This workflow applies when the official Spamhaus Checker names the submitted IP address or domain and identifies a Spamhaus result. It does not apply when a bounce names another blocklist, a receiver's private reputation rule, a mailbox policy, or an authentication error. Use the evidence source named in the rejection instead of treating every reputation problem as a Spamhaus listing. Use a different path for a DBL result. [Spamhaus describes DBL as a domain blocklist](https://www.spamhaus.org/blocklists/domain-blocklist/), so a clean sending IP does not clear a domain finding. Preserve the domain named by the Checker and investigate how that domain appears in message content, headers, the envelope sender, or HELO. Check what a PBL result means before treating it as abuse. [Spamhaus states that PBL-listed addresses are not necessarily bad](https://www.spamhaus.org/blocklists/policy-blocklist/). First determine whether the IP belongs to an end-user range that should submit through an authenticated relay. Do not treat that policy classification as proof that the host sent spam. If the Checker reports no issue for the exact current resource, there is no Spamhaus removal action to submit from that result. Return to the rejection, confirm the production path, and investigate the provider or evidence source it actually names. ## How to act on the result ### A listed IP needs an owner-specific repair Record the exact list and identify who controls the public IP. For an organization-owned server, repair the condition identified in the list guidance, then use the Checker route for verification, removal, or a ticket where Spamhaus offers it. For a provider-owned or shared IP, open a support case with the provider. Include the exact IP, Spamhaus list, lookup time, complete bounce text, and the controlled sending-path evidence. Do not ask the provider to change DNS values that belong to another customer or tenant. ### An unlisted IP with a continuing bounce needs message evidence Run a new test through the same path. Preserve the receiver response and inspect the delivered message when one arrives. The receiver-added `Authentication-Results` field can show DMARC, SPF, and DKIM evaluation details, but it reflects that receiver's assessment under the rules described in [RFC 8601](https://www.rfc-editor.org/rfc/rfc8601.html). Use the original recipient's provider dashboard or support channel when the rejection identifies a provider-specific policy. A Spamhaus lookup cannot access that private decision. ### A domain listing needs domain-owner remediation For DBL, remove the underlying abusive or compromised domain use and follow the official Checker instructions for the listed domain. Check the actual links, redirect targets, and domains used in the affected production message. Do not assume that fixing an IP-list issue clears a DBL result. ## How to retest Repeat the same Spamhaus Checker lookup after the responsible owner completes the documented remediation. For an IP incident, repeat the reverse-IP DNS check and record both timestamps separately. Then send a fresh message through the exact application, relay, public egress IP, and recipient path that produced the incident. Confirm the new SMTP outcome and retain the raw evidence. After DMARC aggregate data has accumulated, review whether the production source remains visible and authenticated. DNS evidence, Spamhaus workflow state, delivered-message evidence, and DMARC aggregate reporting answer different questions. Use [Palisade's DMARC checker](/tools/dmarc) to review authentication evidence for the sending domain. ## Check the IP again after the Spamhaus removal For an IP-list incident, run the affected public IP through [Palisade's IP Reputation Check](/tools/ip-reputation) after the official Spamhaus Checker clears it, then compare that result with a fresh production-path test. [Check the IP reputation](/tools/ip-reputation) This public check cannot submit or speed up a Spamhaus removal, read a receiver's private reputation system, prove why one message was rejected, continuously monitor the IP, or guarantee delivery. ## Sources and further reading - [Spamhaus IP and Domain Reputation Checker](https://check.spamhaus.org/) - [Spamhaus ZEN Blocklist](https://www.spamhaus.org/blocklists/zen-blocklist/) - [Spamhaus Policy Blocklist](https://www.spamhaus.org/blocklists/policy-blocklist/) - [Spamhaus Domain Blocklist](https://www.spamhaus.org/blocklists/domain-blocklist/) - [Spamhaus Checker listing troubleshooting](https://www.spamhaus.org/resource-hub/ip-and-domain-reputation-checker/spamhaus-reputation-checker-troubleshoot-your-listing/) - [RFC 8601: Authentication-Results header field](https://www.rfc-editor.org/rfc/rfc8601.html) ## Frequently asked questions ### Does a clean Spamhaus result mean my email will reach the inbox? No. It means Spamhaus did not report an issue for the submitted resource at the time of the lookup. A receiving provider can use other reputation signals, authentication results, content analysis, and private policy decisions. ### Is a PBL listing proof that an IP sent spam? No. Spamhaus documents PBL as a policy list for end-user IP ranges that should send through an authenticated mail server. Check whether the affected host should use an authorized relay before seeking an exclusion. ### Should I request removal for an IP owned by my email provider? Only the provider or network owner should handle remediation for a shared or provider-owned IP. Send the provider the exact list, IP, result time, and delivery evidence, then follow its documented escalation process. ### What should I do when Spamhaus shows no issue but mail still bounces? No Spamhaus remediation is indicated by that lookup alone. Check that you looked up the IP or domain named in the current rejection, then repeat the test through the same production path. Use the receiver's diagnostic text and provider-side evidence because a clean Spamhaus result does not reveal a private receiver policy. ### Can a domain be listed even when the sending IP is clean? Yes. Spamhaus DBL evaluates domains used in mail-related contexts, including message content, headers, the envelope sender, or HELO. Check the domain named by the result and follow the domain-specific remediation path. --- # Does email warmup work? Canonical: https://www.palisade.email/learning/does-email-warmup-work > Does email warmup work? A gradual ramp of authenticated real mail can help, but it cannot prove inbox placement or replace direct sender evidence. Yes, email warmup can help when it means gradually increasing legitimate, authenticated mail from a new or inactive sending identity while measuring real outcomes. It does not prove that automated warmup activity earns inbox placement. Recipient consent, authentication, complaint rates, content, sending history, and each mailbox provider's filtering still affect where production mail lands. ## Quick takeaways - A controlled ramp is relevant for a new dedicated IP or a materially changed sending path. - Gmail advises large senders to begin with low volume, use engaged recipients, increase slowly, and avoid sudden bursts. - SPF, DKIM, and DMARC support an authenticated sending path, but they do not guarantee inbox placement. - Warmup-tool opens, replies, and scores do not establish how a production campaign will perform. - Use real SMTP responses, delivered-message authentication, complaints, and recipient outcomes to assess a volume increase. - A current spam or rejection problem needs diagnosis from its own production evidence. ## How email warmup works in the limited case Email warmup is useful when an operator uses it as a controlled sending ramp. [Google's email sender guidelines](https://support.google.com/mail/answer/81126?hl=en) tell large senders to start at a low volume with engaged users, increase volume slowly, avoid bursts, and monitor delivery, spam rate, and sending-[domain reputation](/tools/domain-reputation). Google also uses the term "warming up" for a sending domain or IP after a spam-related error in its [Postmaster Tools dashboard guidance](https://support.google.com/mail/answer/14668346?hl=en-GB). That supports a narrow operational conclusion. A steady increase gives a sender a way to observe what happens as real volume changes. It does not reveal a mailbox provider's private filtering rules or establish that inbox placement will improve. [Twilio SendGrid's dedicated-IP guidance](https://support.sendgrid.com/hc/en-us/articles/360041316874-Email-Delivery-Deferrals) recommends warming an IP by stepping up volume over time. Its guidance is specific to SendGrid's service and dedicated IP use. It should not be treated as evidence that every mailbox-account warmup product has the same effect. Authentication remains a prerequisite. Google's sender guidelines require SPF or DKIM for mail sent to personal Gmail accounts, and require SPF, DKIM, and DMARC for bulk senders. Review the protocol role in the [email authentication learning hub](/learning). A passing authentication result confirms part of the sending path. It does not determine a receiver's folder decision. ![Decision flow separating a controlled ramp of authenticated production mail from tool-only activity that cannot prove inbox placement](/images/editorial/does-email-warmup-work/does-email-warmup-work-decision-flow.svg "1200x689") *Source: [Google email sender guidelines](https://support.google.com/mail/answer/81126?hl=en), checked 2026-07-28.* ## When the answer changes Use a controlled ramp when all of these conditions are true: - The sending identity is new, inactive, or materially changed, such as a new dedicated IP or a changed production sending path. - The messages are real mail for opted-in recipients, with an audience that normally receives the program. - The actual production path has working authentication. - The sender can measure outcomes as volume changes. Google advises senders to contact only recipients who opted in to receive messages. It also says that low open rates alone do not accurately diagnose spam classification. That means an open-rate chart or a warmup score cannot settle the question. Do not treat warmup as the first repair when production mail already has clear filtering symptoms. An unaligned sender, a complaint increase, an unconsented list, or changed content can each require separate investigation. Use the evidence-led guide to [why emails go to spam](/learning/why-do-your-emails-go-to-spam-and-how-can-you-fix-it) when actual messages are filtering. Shared infrastructure changes the interpretation as well. Google states that activity from any sender using a shared IP can affect the reputation of all senders on that IP. A sender on shared infrastructure therefore cannot attribute every outcome to its own ramp activity. ## A practical warmup decision record Use one record for each controlled volume change. It keeps the decision tied to real mail rather than a generic warmup completion date. ```text WARMUP DECISION RECORD Sending identity: new dedicated IP, inactive domain, or changed production path Authentication: SPF, DKIM, and DMARC checked on a representative delivered message Audience: opted-in recipients from the normal sending program Volume change: small, steady increase with no sudden burst Observe: SMTP responses, delivery errors, complaints, Gmail sender data when available, and recipient outcomes Decision: continue only when the production evidence remains acceptable Boundary: tool-only opens, replies, or scores do not prove inbox placement ``` The decision rule is: - Authenticated real mail, gradual steady volume, and observable recipient and receiver outcomes: assess the ramp. - Missing authentication, a sudden burst, or only automated tool activity: make no inbox-placement conclusion. ![Checklist for deciding whether a controlled email ramp has enough production evidence to assess](/images/editorial/does-email-warmup-work/does-email-warmup-work-decision-record.webp "1200x582") *Source: Palisade.* ## What to do next with the evidence you have If you have a representative delivered message, inspect its SPF, DKIM, and DMARC results before changing volume. Compare those results with the visible From domain and the actual sending service. Authentication is one part of the evidence, not a placement guarantee. If you have Gmail-specific sender data, use [Google Postmaster Tools dashboard documentation](https://support.google.com/mail/answer/14668346?hl=en-GB) to understand the available data, including spam rate, reputation, authentication, and delivery errors. Google notes that low volume can limit what appears in the dashboards. Absence of a dashboard signal is not proof that all recipients received mail in the inbox. If the question is whether to purchase or compare warmup services, that is a separate buyer decision. See [Email warmup service: compare the evidence before choosing](/learning/email-warmup-service) or the vendor-specific [Instantly email warmup](/learning/instantly-email-warmup) guide. Neither replaces testing the exact production path, audience, and message type you intend to use. A controlled ramp cannot observe future campaigns, control a mailbox provider's private placement decision, or repair authentication and list-quality problems by itself. ## Sources and further reading - [Google email sender guidelines](https://support.google.com/mail/answer/81126?hl=en) - [Google Postmaster Tools dashboards](https://support.google.com/mail/answer/14668346?hl=en-GB) - [Twilio SendGrid dedicated-IP guidance](https://support.sendgrid.com/hc/en-us/articles/360041316874-Email-Delivery-Deferrals) ## Frequently asked questions ### Does email warmup guarantee inbox placement? No. A gradual ramp can avoid a sudden volume increase, but inbox placement remains a mailbox provider decision. Authentication, recipient consent, complaints, content, and sender reputation still affect the result. ### Is automated email warmup the same as IP warm-up? No. Twilio SendGrid documents IP warm-up as a gradual increase in mail volume for a dedicated IP. Automated mailbox activity is a different mechanism and does not, by itself, show how real production mail will be placed. ### How long should email warmup take? There is no universal duration. Increase volume only when the sending identity, real audience, authentication results, and observed outcomes support the next change. A separate infrastructure or audience change can require a new assessment. ### Can I warm up a sender without SPF, DKIM, and DMARC? No. Do not use a ramp as a substitute for authentication. Verify authentication on a representative production message before evaluating volume or placement outcomes. ### Should I reduce volume after deferrals or complaints? Yes. Reduce or pause the affected segment, inspect the SMTP responses and recent changes, then identify the cause before increasing volume again. Google recommends monitoring delivery, spam rate, and sender reputation as volume grows. --- # EasyDMARC vs dmarcian: how the two compare Canonical: https://www.palisade.email/learning/easydmarc-vs-dmarcian > EasyDMARC vs dmarcian: EasyDMARC publishes your DNS records, dmarcian stays read-only. Sourced comparison of pricing, domain ceilings and MSP fit. EasyDMARC publishes DNS records on your behalf and automates the work of getting to enforcement. dmarcian stays read-only by design and hands your team analysis plus guidance instead. That single architectural difference decides most shortlists, and it matters more than any price on either page. Pick EasyDMARC if you want the platform to do the configuration work across many domains. Pick dmarcian if you want deep report analysis and your team keeps control of every DNS change. ## Quick takeaways - dmarcian describes a "read-only design that safeguards your client's DNS integrity" and does not publish records for you, checked August 17, 2026. - EasyDMARC offers managed DMARC and managed BIMI on every plan including Free, managed DKIM on Enterprise, and hosted SPF with flattening from Premium, checked August 17, 2026. - dmarcian's highest published tier tops out at 15 active domains. Any MSP with a real client book is in a sales conversation immediately. - EasyDMARC's headline price is a floor that rises with volume. Plus is $35.99 per month billed annually at 100,000 emails and $111.99 per month at 1,000,000, checked August 17, 2026. - Neither vendor publishes MSP pricing. Both require a sales call for per-domain rates, so no public per-domain cost comparison is possible. - dmarcian declines to build SPF flattening on principle. EasyDMARC includes it. Neither position is wrong, but they produce very different amounts of manual work. ## Who this comparison is for This is for an IT owner or an MSP technician shortlisting the two platforms for a real domain estate. It compares what each vendor publishes about its own product on its own site, with the date each fact was checked. Two things it deliberately does not do. It does not rank the products on a score, because the public evidence bases are not comparable. It does not reproduce discussion threads about either vendor, because the ones commonly cited could not be retrieved and verified. ## The difference that decides most shortlists Start here, because it determines how much work lands on your team. **dmarcian is read-only.** Its managed service provider page describes a "read-only design that safeguards your client's DNS integrity and doesn't introduce critical path dependencies", checked August 17, 2026. dmarcian reads your aggregate reports, shows you what is failing, and gives you step-by-step remediation guidance. Your team makes every DNS change. dmarcian has also declined to build SPF flattening, stating that it "has resisted the urge to turn SPF Flattening into a product or service, mainly because the need for SPF Flattening goes away when an organization adopts best practices and segments their vendors and email streams." Its position is not absolute: the same page accepts flattening as a stop-gap for teams that lack the authority to make those wider changes, while warning that a stop-gap tends to become permanent. **EasyDMARC writes records for you.** Managed DMARC and managed BIMI appear on every plan including Free. EasyDMARC's SPF product monitors lookup counts in real time and manages SPF macros to stay under the 10-lookup limit. Managed DKIM is reserved for Enterprise, and hosted MTA-STS starts at Premium. Neither approach is a defect. A team with change-control discipline and DNS expertise may prefer that no vendor touches its zone. A team running dozens of client domains usually cannot absorb that much manual work. One nuance the table below flattens: dmarcian not offering managed BIMI does not mean it ignores BIMI. It ships free BIMI Inspector, Builder and SVG validation tools. The difference is who publishes the record, not who helps you build it. ## Comparison at a glance Every row below reflects what each vendor publishes for its self-serve plans, checked August 17, 2026. | Capability | dmarcian | EasyDMARC | | --- | --- | --- | | Aggregate (RUA) reporting | All plans | All plans | | Forensic (RUF) reporting | All paid plans | Plus and above | | Publishes DMARC records for you | Not offered | All plans including Free | | Hosted SPF and flattening | Declined by policy | Premium and above | | Managed DKIM | Not offered | Enterprise only | | Managed BIMI | Not offered | All plans including Free | | Hosted MTA-STS | Self-hosting guides only | Premium and above | | TLS reporting | All plans | Premium and above | | API and SSO | Enterprise only | Enterprise only | | Highest self-serve domain count | 15 active domains | 4 domains, unlimited on custom-priced Enterprise | | Free option | Non-business use only | 1 domain, 1,000 emails per month | ## Where each one fits an MSP book This is where the two diverge hardest, and where the published evidence is thinnest for one of them. **EasyDMARC publishes an MSP track.** Its MSP page names four PSA integrations by vendor: ConnectWise PSA, HaloPSA, Autotask PSA and SyncroMSP. It names four DNS providers for its Direct Connect onboarding, and puts a figure on what that buys: "Most MSP partners complete a 100-domain onboarding in a single day using Direct Connect for supported DNS providers (Cloudflare, GoDaddy, Route 53, Ionos) and bulk domain import. For clients using other DNS providers, records are published through your existing DNS change workflow in about 20 minutes per client." White label reporting appears on the MSP plan, described as co-branded or fully white-labeled depending on plan. All checked August 17, 2026. **dmarcian's MSP material is thinner.** It has an MSP portal, domain groups, and a partner program that offers "special partner pricing". Searching its public pages, no white labeling, no PSA integrations, and no bulk onboarding automation were found. Absence from a public page is not proof a capability does not exist, so treat this as a question to put to dmarcian rather than a settled fact. Two ceilings deserve attention before you shortlist either. dmarcian's published plans stop at 15 active domains on Enterprise, at $499 per month billed annually. An MSP with 40 client domains has no published plan to buy. EasyDMARC's self-serve plans carry a subtler trap. Plus covers two domains and Premium covers four, and on those self-serve tiers the API, SSO, audit logs, every DNS integration, Slack and Teams, and managed DKIM are all Enterprise-only. An MSP who signs up self-serve gets the dashboard without the automation that makes multi-tenant work viable. The MSP track exists precisely to solve that, and it is priced by sales. ## What each one costs Both vendors publish list pricing for business plans. Compare annual against annual, since both discount for the yearly commitment. **dmarcian**, from its [pricing page](https://dmarcian.com/pricing/), checked August 17, 2026: Basic at $19.99 per month billed annually covers up to 2 active domains and 100,000 DMARC-capable messages. Plus at $199 covers up to 8 domains and 1,000,000 messages. Enterprise at $499 covers up to 15 domains and 5,000,000 messages. A Personal plan at $0 is restricted to non-business domains sending fewer than 1,250 emails per month, and dmarcian states it audits those accounts. Trials run 30 days on any plan. dmarcian meters what it calls DMARC-capable messages, and explains the choice directly: "We base our pricing on the volume of legitimate traffic that is reported to dmarcian via DMARC reports. We don't want to charge our users for forwarded or fraudulent traffic." **EasyDMARC**, from its [pricing page](https://easydmarc.com/pricing), checked August 17, 2026: the advertised figure is a starting point, not the price. Plus at 100,000 emails per month is $35.99 billed annually, and the same plan at 1,000,000 emails is $111.99. Premium runs from $71.99 to $191.99 across the same range, and reaches $299.99 at 5,000,000. Plus includes 2 domains and Premium includes 4. Enterprise is custom priced. One EasyDMARC behavior is worth knowing before you size a plan. Exceeding your quota is not an overage charge. EasyDMARC states you "lose access to your reports/dashboard" until you upgrade, which makes volume estimation an availability question rather than only a billing one. ![Decision flow for comparing EasyDMARC and dmarcian by published price model, estate size, and unanswered operational requirements](/images/editorial/easydmarc-vs-dmarcian/easydmarc-vs-dmarcian-pricing-decision.webp "1200x829") *Source: Palisade.* ## What neither vendor publishes Both gaps fall on the same side, and they matter most to the buyer this page is written for. Neither dmarcian nor EasyDMARC publishes MSP pricing. dmarcian asks service providers to "get in touch for pricing options". EasyDMARC describes its MSP model as pay-as-you-go per client domain per month with volume pricing at MSP scale, then directs you to its MSP team for a package. No public per-domain rate exists for either, so any MSP cost comparison you read that quotes one is not sourced from the vendor. The units also differ in ways a table cannot fix. dmarcian bills active domains, meaning those that send legitimate mail, and counts parked domains separately. EasyDMARC's pricing page does not define what counts as a domain. dmarcian excludes forwarded and fraudulent traffic from its message count; EasyDMARC does not say. Setting 1,000,000 beside 1,000,000 implies an equivalence neither vendor claims. ## What the review data does and does not show The headline scores are the least useful thing here. On G2, EasyDMARC carries a review base in the hundreds while dmarcian's sits in the single digits. Those samples are not comparable, and a star rating drawn from five reviews cannot establish a product's quality in either direction. Treat any side-by-side score you see for these two, including on G2 itself, as a statement about how many customers left reviews rather than about which product is better. The tagged themes are more useful than the scores. EasyDMARC reviewers most often cite ease of use and customer support as strengths, and cost and limited functionality as weaknesses. On Capterra, reviewers praise fast setup and documentation while describing shallow drill-down and a slow interface. dmarcian's small Capterra sample praises report depth, with reviewers noting the reports "present more details than other solutions", and criticizes a confusing interface and steep prerequisite knowledge. G2's own comparison summary captures the split: reviewers felt EasyDMARC better meets their business needs, while preferring dmarcian's product direction. Read both sets of themes before either sales call, and weigh the ones that describe daily use over the ones that describe a score. ## How to choose **Choose dmarcian if** your team owns DNS change control and wants it to stay that way, you value depth of report analysis over automation, your estate fits inside 15 active sending domains, and you are willing to buy support sessions separately. dmarcian sells dedicated support in metered blocks of 5, 16 or 40 sessions, and its deployment services are quoted rather than listed. **Choose EasyDMARC if** you manage many domains and need the platform to publish and maintain records, you want PSA integration and white labeled client reporting, and you can either commit to the MSP track or accept that the self-serve tiers withhold the automation. Size your plan against real annual volume, not today's volume, because the price scales and the quota cuts off access. **Ask both for a quote if** you are an MSP. Neither published plan is built for a client book, and the published prices will not tell you what you would actually pay. ### Check the record behind the buying decision Before either sales call, inspect what a domain publishes today. Use the [DMARC checker](/tools/dmarc) to read the live record for a sending domain, then bring that to the conversation instead of a feature checklist. A record check shows the policy in place at one moment. It cannot list every production sender or prove how either vendor will handle your workflow. That evidence only arrives once aggregate reports accumulate. Buyers weighing a third option can read the [EasyDMARC alternative guide](/easydmarc-dmarc-alternative) and the [dmarcian alternative guide](/dmarcian-dmarc-alternative), or see the full set of [DMARC platform comparisons](/compare). The question worth carrying into any of those conversations is who does the work: a platform that hands your team a task list, or one that does the analysis and drafts the change for a person to review. ## Sources and further reading - [dmarcian pricing, plan allowances, and pricing FAQ](https://dmarcian.com/pricing/), checked August 17, 2026 - [dmarcian for managed service providers](https://dmarcian.com/managed-service-provider-dmarc/), checked August 17, 2026 - [dmarcian on SPF flattening](https://dmarcian.com/spf-flattening/), checked August 17, 2026 - [EasyDMARC pricing](https://easydmarc.com/pricing), checked August 17, 2026 - [EasyDMARC for MSPs](https://easydmarc.com/dmarc-for-msps), checked August 17, 2026 - [dmarcian dedicated support tiers](https://dmarcian.com/dedicated-support/), checked August 17, 2026 - [G2 comparison: EasyDMARC vs dmarcian](https://www.g2.com/compare/easydmarc-vs-dmarcian), checked August 17, 2026 ## Frequently asked questions ### Is EasyDMARC cheaper than dmarcian? At the entry point, no. dmarcian Basic is $19.99 per month billed annually against EasyDMARC Plus at $35.99, both checked August 17, 2026. The comparison inverts as you grow: dmarcian's next tier jumps to $199 per month for 8 domains, while EasyDMARC Plus at 1,000,000 emails is $111.99. Price the tier that matches your real domain count and volume rather than comparing the first number on each page. ### Does dmarcian publish DNS records for me? No. dmarcian describes a read-only design that leaves DNS integrity with the customer, and it does not offer hosted SPF, DKIM or DMARC records. It provides remediation guidance and your team applies the changes. EasyDMARC offers managed DMARC and BIMI on every plan, managed DKIM on Enterprise, and hosted SPF from Premium. ### Which one is better for an MSP with 40 client domains? Neither published plan covers that estate, so both routes lead to a sales conversation. On published evidence EasyDMARC is further along for MSP operations, naming PSA integrations, bulk onboarding and white labeled reporting on its MSP page. dmarcian's highest listed plan stops at 15 active domains and its public pages do not describe white labeling or PSA integration. Ask dmarcian directly rather than assuming the absence is definitive. ### Does dmarcian have a free plan for businesses? No. dmarcian's $0 Personal plan is for non-business domains, limited to two active domains sending fewer than 1,250 emails per month, and dmarcian states it audits those accounts. EasyDMARC's free tier does allow business use, covering one domain, 1,000 emails per month and 14 days of history. ### What happens if I exceed my plan's email volume? The two behave differently. EasyDMARC states you lose access to your reports and dashboard until you upgrade. dmarcian describes its tier volumes as default allowances with custom pricing available for overages, and does not describe cutting off access. Confirm the current behavior with each vendor before sizing a plan close to a limit. ### Do either of them publish MSP or partner pricing? No. dmarcian offers partner pricing and asks service providers to contact them. EasyDMARC describes per-domain monthly pricing that scales with client count, then directs MSPs to its team for a tailored package. Any per-domain figure quoted publicly for either vendor did not come from the vendor. --- # One-click unsubscribe law: what RFC 8058 actually requires Canonical: https://www.palisade.email/learning/one-click-unsubscribe-law > One-click unsubscribe law: RFC 8058 is an IETF technical standard that Gmail and Yahoo enforce as a bulk-sender requirement, not a US statute. There is no statute called the "one-click unsubscribe law." The term people search for usually points to [RFC 8058](https://www.rfc-editor.org/rfc/rfc8058), an IETF technical standard, which Gmail and Yahoo have each turned into a bulk-sender requirement. Gmail requires it for senders of more than 5,000 messages a day to Gmail accounts, effective February 1, 2024. Yahoo lists it as a requirement for bulk senders without publishing a numeric threshold on the same page. ## Quick takeaways - One-click unsubscribe is a protocol standard, RFC 8058, not a law passed by a legislature. - Gmail requires it for senders exceeding 5,000 messages a day to Gmail accounts, effective February 1, 2024. - Yahoo's Sender Best Practices list one-click unsubscribe as a requirement for bulk senders, with no published numeric threshold or effective date on that page. - The standard needs two headers, `List-Unsubscribe` and `List-Unsubscribe-Post`, and a valid DKIM signature covering both. - Consumer subscription-cancellation rules, sometimes called "click to cancel," are a separate legal subject from email one-click unsubscribe. Confirm those with counsel or the relevant regulator. ## Who is affected? RFC 8058 itself does not name a sending volume or a specific mailbox provider. It defines a signal that any list sender can add to outgoing mail, and a behavior any mail receiver can implement when it sees that signal. Mailbox providers decide who has to use it. Google's Email sender guidelines state that starting February 1, 2024, senders of more than 5,000 messages per day to Gmail accounts must meet its bulk-sender requirements, which include: "Marketing messages and subscribed messages must support one-click unsubscribe, and include a clearly visible unsubscribe link in the message body." Google's page does not give a separate processing-time window for one-click compliance beyond that threshold, so nothing here should be read into it. Yahoo's [Sender Best Practices](https://senders.yahooinc.com/best-practices/) require bulk senders to "Implement a functioning list-unsubscribe header, which supports one-click unsubscribe," and describes the RFC 8058 POST method as highly recommended. Yahoo also instructs senders to "Honor unsubscribes within 2 days" and keep spam complaint rates below 0.3%. The page does not define a specific numeric bulk-sender threshold, unlike Gmail's stated 5,000-message figure. Transactional-only senders with no marketing or subscribed messages are outside the scope both providers describe, since the requirement is written around "marketing messages and subscribed messages." A sender that only sends receipts or password resets, with no list mail, is not the audience this requirement targets, based on how Google phrases its own rule. ## What are the requirements? ### The message carries two headers RFC 8058 requires a `List-Unsubscribe` header containing an HTTPS URI, and a `List-Unsubscribe-Post` header with a fixed value. Google's page shows this same header pair and links both RFC 2369 and RFC 8058 as the underlying references. ```text List-Unsubscribe: <https://example.com/unsubscribe/opaque-id> List-Unsubscribe-Post: List-Unsubscribe=One-Click ``` The URI shown here is illustrative only. The real value is generated by the sending platform or ESP for each recipient, and it should not be published or shared outside that system. ![RFC 8058 required headers](/images/editorial/one-click-unsubscribe-law/one-click-unsubscribe-law-headers.webp "1200x600") *Source: Palisade.* ### The DKIM signature has to cover both headers RFC 8058 Section 4 requires a valid DKIM signature whose `h=` tag covers both `List-Unsubscribe` and `List-Unsubscribe-Post`. Without that coverage, receivers should not offer the one-click action at all. This is the point where one-click unsubscribe stops being a mail-client feature and becomes a DKIM configuration question: a signature that exists but does not list these two headers in its `h=` tag does not satisfy the standard, even if DKIM otherwise passes. ### The receiver's POST has no cookies, login, or redirect When a recipient clicks unsubscribe in their mail client, RFC 8058 says the mail receiver sends an HTTPS POST to the URI with `List-Unsubscribe=One-Click` as the body. The mailbox provider should send the POST as `multipart/form-data` and may send `application/x-www-form-urlencoded`. The endpoint must accept either encoding and complete the unsubscription from that request alone. The standard bans cookies, HTTP authorization, and redirects on that response, and recommends the URI carry an opaque, hard-to-forge token that the server verifies. A confirmation page or login wall on the other end breaks the one-click behavior, even if the headers themselves are correctly formatted. ### The visible unsubscribe link stays in the message body Google's requirement pairs one-click support with keeping "a clearly visible unsubscribe link in the message body." The header-based mechanism and the body link are not substitutes for each other under Google's stated rule. A sender that removes the visible link because the headers are present has not met the requirement as Google describes it. ## When does the requirement take effect? RFC 8058 itself was published as an IETF Standards Track document in January 2017. Publication of the RFC did not create an enforcement date on its own; that came later, from individual mailbox providers. Google's bulk-sender requirements, including the one-click and visible-link provisions, took effect February 1, 2024, for senders of more than 5,000 messages a day to Gmail accounts. Yahoo's Sender Best Practices page states the one-click requirement for bulk senders but does not publish a specific effective date or numeric threshold on that page, so treat it as an ongoing best-practice expectation rather than a dated rollout. ![Timeline comparing RFC 8058 publication with Gmail's and Yahoo's bulk-sender enforcement of one-click unsubscribe](/images/editorial/one-click-unsubscribe-law/one-click-unsubscribe-law-timeline.webp "1200x600") *Source: Palisade.* ## How do I implement the requirement? ### 1. Confirm your sending platform supports RFC 8058 headers Most major ESPs add `List-Unsubscribe` and `List-Unsubscribe-Post` automatically for list mail. Check your platform's documentation for whether it sets both headers, or only the older `List-Unsubscribe` field without the POST companion header, since the single-header form does not satisfy RFC 8058 on its own. ### 2. Verify DKIM signs both headers Check the `h=` tag on your DKIM signature. If your platform signs a fixed set of headers that predates your one-click setup, `List-Unsubscribe` and `List-Unsubscribe-Post` may not be included, which means receivers should not treat the message as one-click eligible even though the headers are present. ### 3. Keep the visible body link Do not remove the in-message unsubscribe link when you add header-based one-click support. Google's rule asks for both. ### 4. Honor unsubscribe requests promptly Yahoo's page asks senders to honor unsubscribes within two days. Update suppression lists across every system that can still send to that recipient, not only the platform that received the POST. ### 5. Watch your complaint rate Google's guidance sets 0.3% as the spam-rate ceiling in Postmaster Tools, and its separate monitoring guidance recommends staying below 0.10% rather than approaching that ceiling. A working one-click flow tends to lower complaint rates, since recipients who can unsubscribe in one step are less likely to click "report spam" instead. ## How do I validate compliance? Send a real message through your production list-sending path and inspect the raw headers, not a preview or test-mode copy. Confirm `List-Unsubscribe` contains an HTTPS URI and `List-Unsubscribe-Post` contains exactly `List-Unsubscribe=One-Click`. Confirm the DKIM signature's `h=` tag lists both header names. Trigger the unsubscribe action from a real or test mail client where possible, and confirm the recipient is actually suppressed in your source-of-truth list system afterward, not just that the request returned a success response. A green DKIM status in your sending platform is not the same check as a delivered message with both headers correctly signed; verify the delivered message itself. Public DNS and authentication checkers can confirm that your domain publishes valid SPF, DKIM, and DMARC records, which is the foundation DKIM signing depends on. The [email security score tool](/tools/email-security-score) checks that authentication posture from public DNS. It does not read message headers from a delivered email, and it cannot confirm whether your `List-Unsubscribe` headers exist, whether DKIM's `h=` tag covers them, or whether your unsubscribe endpoint behaves the way RFC 8058 requires. Those checks need a real delivered message and a test against your own endpoint. ## Check your domain's authentication posture A correctly signed one-click header pair depends on working DKIM in the first place. If you have not confirmed your domain's SPF, DKIM, and DMARC records are published correctly, that is worth checking before troubleshooting header coverage. [Check your domain's authentication setup](/tools/email-security-score) This check reads public DNS records. It cannot confirm that a specific delivered message carries the `List-Unsubscribe` and `List-Unsubscribe-Post` headers, or that your DKIM signature's `h=` tag covers them; that requires inspecting the message itself. For the fuller picture of what Gmail, Yahoo, and other mailbox providers currently require from bulk senders, see the [sender requirements guide](/email-deliverability), and for background on the header pair itself, see [one-click unsubscribe and RFC 8058](/learning/one-click-unsubscribe). ## Sources and further reading - [RFC 8058: Signaling One-Click Functionality for List Email Headers](https://www.rfc-editor.org/rfc/rfc8058) - [Google Email sender guidelines](https://support.google.com/a/answer/81126) - [Yahoo Sender Best Practices](https://senders.yahooinc.com/best-practices/) - [FTC CAN-SPAM Act: A Compliance Guide for Business](https://www.ftc.gov/business-guidance/resources/can-spam-act-compliance-guide-business) Where email deliverability and unsubscribe handling fit into a broader sender program, the [deliverability hub](/email-deliverability) covers the surrounding practices. Legal questions outside email, including subscription-cancellation rules, are a different subject from the material on this page; see the note on [data protection and business-owner obligations](/learning/threats) for that scope distinction, and confirm current legal requirements with counsel or the relevant regulator directly. ## Frequently asked questions ### Is one-click unsubscribe a law? No. One-click unsubscribe is RFC 8058, a technical standard published by the IETF in January 2017. Gmail and Yahoo each require it as part of their own bulk-sender rules, which is a mailbox-provider policy, not legislation. Separately, the FTC's CAN-SPAM guide requires commercial email to tell recipients how to opt out and to honor opt-out requests promptly, but that requirement does not itself specify the RFC 8058 header mechanism. ### What states have a click to cancel law? This page cannot confirm a specific list of states from the standards and mailbox-provider sources it covers. "Click to cancel" language typically refers to consumer subscription-cancellation rules, which are a separate legal subject from email one-click unsubscribe under RFC 8058. Check your state attorney general's office or the Federal Trade Commission's current guidance for the applicable rules, and confirm specifics with counsel. ### What is the new law about canceling subscriptions? This page covers the email one-click unsubscribe standard, RFC 8058, and mailbox-provider requirements built on it. Rules about canceling paid subscriptions are a different legal subject, governed by consumer-protection regulators rather than by email standards bodies. Confirm the current status of any subscription-cancellation rule with the FTC or your state regulator, and with counsel. ### What is the one click cancel rule? This term is not defined on the email standards and mailbox-provider pages this article draws from. If it refers to subscription cancellation rather than email unsubscribe mechanics, it falls under consumer-protection regulation, not RFC 8058. Confirm the exact scope with the relevant regulator's official page. ### Does CAN-SPAM require the RFC 8058 header pair? Not directly. The FTC's CAN-SPAM compliance guide requires commercial email to tell recipients how to opt out and to honor those requests promptly, but the guide does not itself mandate `List-Unsubscribe` or `List-Unsubscribe-Post`. The RFC 8058 header pair is a mailbox-provider requirement from Gmail and Yahoo, layered on top of, not substituting for, general CAN-SPAM opt-out obligations. ### Why does DKIM matter for one-click unsubscribe? RFC 8058 requires a valid DKIM signature that covers both the `List-Unsubscribe` and `List-Unsubscribe-Post` headers in its `h=` tag. Without that coverage, the standard says receivers should not offer the one-click action, even if the headers themselves are present and correctly formatted in the message. --- # What is quishing (QR code phishing) and how do you stop it? Canonical: https://www.palisade.email/learning/what-is-quishing-qr-code-phishing > Quishing is QR code phishing that hides a malicious link in a scannable image. Learn how to identify it and reduce the risk of credential theft. Quishing is phishing that uses a QR code to hide a destination URL from the person receiving it. A scan can open a fake sign-in page, payment page, or file-download prompt on a phone. Stop it by treating an unexpected QR code as an untrusted link, reaching important services through a known address or app, and using phishing-resistant MFA so a fake sign-in page cannot reuse credentials or a session. ## Quick takeaways - Quishing is phishing delivered through a QR code, also called QR code phishing. - A QR code can appear in an email, attachment, printed notice, sticker, or message. - Scanning a code opens a URL, but the risk usually comes from entering credentials, approving a request, or downloading a file afterward. - DMARC helps prevent exact-domain spoofing of your own domains, but it does not determine whether a QR code's destination is safe. - Phishing-resistant MFA can reduce the value of credentials collected on a lookalike sign-in page. - A public DNS check can show published email-authentication records, but it cannot prove that an inbound QR code is harmless. ## How quishing works A quishing attack gives a person a reason to scan a QR code. The code may claim to open a voicemail, review a document, reset an account, pay an invoice, or complete a security task. Instead of showing a clickable text link, the message puts the destination inside a scannable image. After the scan, the phone opens the encoded URL. The next page can imitate a legitimate service and request a password, MFA approval, payment details, or a download. The QR code is the delivery mechanism. The fraudulent page or follow-up action causes the compromise. The [FBI advisory on QR-code spearphishing](https://www.ic3.gov/CSA/2026/260108.pdf) describes state-sponsored actors using QR codes in spearphishing emails to direct targets to credential-harvesting infrastructure. It also describes adversary-in-the-middle activity that can capture session information after a victim completes a real-time sign-in flow. QR codes create an inspection problem because the destination is encoded as an image rather than presented as readable link text. A recipient may also scan on a mobile device, away from the browser, endpoint, or corporate-network controls used on a work computer. Those conditions do not make every QR code malicious. They mean the recipient needs a reliable way to establish where the code leads before providing information. ![Decision flow for an unexpected QR code, from checking its source to using a known service address or reporting the message](/images/editorial/what-is-quishing-qr-code-phishing/what-is-quishing-qr-code-phishing-decision-flow.webp "1200x676") *Source: Palisade.* ## When a QR code should change your response The practical decision rule is based on the requested action and the context, not on whether the QR code looks polished. Treat the code as suspicious when it arrives unexpectedly, asks you to sign in, asks for payment details, asks you to approve MFA, or appears as a sticker placed over another code. Do not use the code to reach a service in those cases. Open the service's official app, use a saved bookmark, or type the known address yourself. A QR code can also be legitimate, such as one printed by a service you deliberately chose to use. Even then, pause if the resulting page asks for credentials in a context where you did not expect to authenticate. The source of the code and the destination page both matter. Phishing-resistant MFA changes the outcome when an attacker tries to collect credentials through a lookalike site. [Phishing-resistant MFA](https://www.palisade.email/learning/phishing-resistant-mfa) is designed to bind authentication to the legitimate relying party, rather than treating any page that requests a code or approval as equivalent. It does not make a malicious QR code safe, but it can prevent a stolen password from completing the same sign-in path. DMARC addresses a separate problem. As explained in [Does DMARC stop phishing?](/learning/does-dmarc-stop-phishing), DMARC helps domain owners reduce unauthorized use of their exact visible From domain. An attacker can still send a QR-code phishing message from an attacker-controlled domain, a lookalike domain, or a compromised legitimate account. Authentication status is evidence about domain authorization, not a safety verdict on the QR code or its destination. ## Worked example: assess a QR-code request Suppose an email says that a voicemail is waiting and instructs you to scan a QR code to listen. The email arrived without a voicemail notification you expected, and the code opens a page asking for your work password. Use this decision rule: ```text Unexpected QR code + request to sign in or approve MFA = do not scan again or enter credentials Open the known voicemail or collaboration service directly. If the message claims to be from an internal team, report it through the team's established security process and preserve the original message for review. ``` The key evidence is the mismatch between the claimed task and the requested authentication. A genuine notice may still be worth checking, but check it through the service you already use. Do not let the QR code choose the destination for you. If you have already scanned a code, stop before entering credentials or downloading anything. If credentials, an MFA approval, or a session-related prompt were provided, follow your organization's incident process promptly. The affected identity provider, endpoint-management team, or security team has the evidence needed to review account activity and revoke sessions where appropriate. ## What to do next, based on the evidence you have If you only have a suspicious QR code, do not scan it to investigate. Preserve the email, attachment, image, or physical location details and send them to the security team or reporting channel your organization uses. A security team can inspect the original artifact without relying on the recipient's phone session. If you have the destination URL after scanning but have not opened it further, use the [Palisade phishing link checker](/tools/phishing-link-checker) to inspect the URL before visiting it. A URL check can provide a point-in-time signal. It cannot prove that a destination is safe, show what a page will request after login, or replace review of the original message and its sender context. If you manage domains, also check whether your organization has reduced exact-domain spoofing exposure. The [email security learning center](/learning) covers the broader controls around email-borne threats. Public DNS and authentication checks can show what a domain publishes today, but they do not show whether a particular inbound message is legitimate or whether a recipient's device is protected. ## Check the public email-security posture behind your domain A quishing email can arrive from a lookalike or attacker-owned domain, but attackers also benefit when they can impersonate a trusted brand. Check your domain's public email-security posture, then compare the result with the sending paths your team actually authorizes. [Check your email security score](/tools/email-security-score) A public score checks published DNS evidence. It cannot decode an inbound QR code, identify every production sender, monitor later changes, or prove how a mailbox provider handled a specific message. For ongoing DMARC work, Palisade is DMARC software that analyzes DMARC aggregate-report data, identifies sending sources and authentication or alignment issues, and creates prioritized remediation tickets. It can propose the next policy step when evidence supports it, while a human reviews the evidence and applies the DNS change. That work helps reduce exact-domain spoofing. It does not inspect QR images or guarantee that future phishing messages will be blocked. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=existing_content_migration&utm_content=what-is-quishing-qr-code-phishing) ## Sources and further reading - [FBI Internet Crime Complaint Center advisory on QR-code spearphishing](https://www.ic3.gov/CSA/2026/260108.pdf) - [Does DMARC stop phishing?](/learning/does-dmarc-stop-phishing) - [Phishing-resistant MFA: does it stop device code phishing?](/learning/phishing-resistant-mfa) - [Palisade phishing link checker](/tools/phishing-link-checker) - [RFC 9989: Domain-based Message Authentication, Reporting, and Conformance](https://www.rfc-editor.org/rfc/rfc9989.html) ## Frequently asked questions ### Is quishing only delivered by email? No. A quishing lure can appear in an email, document, message, poster, letter, or sticker. The defining feature is that the phishing destination is encoded in a QR code. ### Does scanning a malicious QR code infect a phone? No. Scanning a QR code usually opens its destination URL. Harm often occurs only after the person enters credentials, approves an authentication request, submits payment information, or downloads and opens a file. ### Can DMARC stop QR code phishing? No. DMARC helps receivers evaluate whether a message is authorized to use its visible From domain. It does not inspect a QR image or determine whether the encoded URL is malicious. ### Should I enter credentials after scanning a QR code? No, if the code was unexpected or the request to sign in is unusual. Open the relevant service through its known app, bookmark, or typed address instead. ### Does phishing-resistant MFA make QR codes safe? No. Phishing-resistant MFA does not validate a QR code or its destination. It can reduce the chance that credentials gathered through a lookalike site can be used to authenticate to the legitimate service. --- # What is spam email and how do you prevent it? Canonical: https://www.palisade.email/learning/what-is-spam-email-and-how-to-prevent-it > Spam email is unwanted bulk email that can carry scams or malware. Learn how filters, reporting, and email authentication help prevent it safely. Spam email is unwanted email, often sent at scale, that recipients did not request. It can be ordinary unsolicited advertising, but it can also deliver phishing links, fraudulent payment requests, or malicious attachments. Preventing it requires two different actions: recipients report and avoid suspicious messages, while domain owners authenticate legitimate mail so receivers can distinguish authorized messages from impersonation attempts. ## Quick takeaways - Spam is unwanted email, while phishing is a deceptive attempt to obtain information, money, or account access. - A spam report helps a mailbox provider classify similar mail for the reporting recipient and may affect broader filtering decisions. - SPF and DKIM provide authentication signals, but DMARC requires an aligned SPF or DKIM pass for the visible From domain. - A sender can publish correct DNS records and still have mail filtered because receivers use their own local policies and signals. - Do not use links, attachments, or unsubscribe controls in a suspicious message until you have independently verified the sender. - A public DNS check can inspect published authentication records, but it cannot prove delivery, inbox placement, or a receiver's private spam decision. ## How spam email prevention works Mailbox providers evaluate incoming mail before deciding where to place it. Their filtering decisions are local to each provider, and a sender cannot see every signal or rule that a recipient uses. For example, [Google's sender guidelines](https://support.google.com/a/answer/81126) require bulk senders to authenticate mail and describe spam-rate expectations, while [Microsoft's email authentication guidance](https://learn.microsoft.com/en-us/defender-office-365/email-authentication-about) explains how SPF, DKIM, and DMARC help protect domains from spoofing. For recipients, prevention begins with treating an unexpected message as untrusted until its request and sender make sense. A message that claims to be from a bank, supplier, executive, or software service can still use a convincing display name. Verify a payment, credential, or account-change request through a phone number, account portal, or contact method you already know. For senders, prevention is about reducing unauthorized use of the domain. SPF lets a domain publish authorized sending infrastructure. DKIM lets a receiving system validate a domain-associated cryptographic signature. [RFC 9989 defines DMARC](https://datatracker.ietf.org/doc/html/rfc9989) as the policy and reporting framework that evaluates whether SPF or DKIM passes with identifier alignment to the visible From domain. A DMARC pass does not guarantee inbox placement. It gives the receiver an authenticated, aligned signal about the From domain. The receiver still makes its own delivery and filtering decision. ## When the answer changes Spam prevention changes based on the evidence you have. If you are a recipient with a suspicious message, preserve the message and report it through your mailbox provider's spam or phishing controls. Do not forward an unredacted suspicious message outside your organization if it contains private information. If the message requests a payment or password reset, verify the request through an independent channel. If you are a sender whose legitimate mail lands in spam, start with the exact production sending path. Check the visible From domain, the envelope sender, DKIM signing domain, sending application, and delivery headers from a real delivered message. [RFC 8601 defines the Authentication-Results header field](https://www.rfc-editor.org/rfc/rfc8601.html), which can show a receiver's recorded SPF, DKIM, and DMARC evaluation. A domain's public DNS record is useful evidence, but it is only one layer: - DNS: confirm the published SPF, DKIM, and DMARC records through authoritative DNS and a public resolver. - Vendor: confirm the sending provider has verified the intended domain and is using its generated configuration. - Message: inspect a real message from the production path and its Authentication-Results header. - DMARC: review aggregate reports after they accumulate to identify sending sources and authentication or alignment failures. For Gmail-specific filtering questions, see [why emails go to spam in Gmail](/email-deliverability/why-are-my-emails-going-to-spam-in-gmail). If the affected recipients use Microsoft mailboxes, [how to stop emails going to spam in Outlook](/email-deliverability/how-to-stop-emails-going-to-spam-in-outlook) covers that narrower investigation. > Do not change a DMARC policy from monitoring to quarantine or rejection because a DNS lookup looks correct. Validate every important production sender first. A legitimate sender that still fails DMARC can be disrupted by a stronger policy. ## Worked example: checking whether a sender is authenticated A delivered message can contain an Authentication-Results field similar to this structural example: ```text Authentication-Results: mx.example.net; spf=pass smtp.mailfrom=mail.yourdomain.com; dkim=pass header.d=yourdomain.com; dmarc=pass header.from=yourdomain.com ``` This example shows a receiver recording SPF, DKIM, and DMARC passes. The important DMARC detail is alignment: the visible `header.from=yourdomain.com` aligns with the authenticated DKIM domain in this example. RFC 9989 specifies the relationship between the visible From domain, SPF, DKIM, and DMARC evaluation. ![Checklist showing the four evidence layers for investigating legitimate email classified as spam](/images/editorial/what-is-spam-email-and-how-to-prevent-it/what-is-spam-email-and-how-to-prevent-it-authentication-checklist.webp "1200x524") *Source: Palisade.* A passing result in one delivered message does not establish that every application using the domain is configured correctly. A different ESP, transactional service, forwarding path, or subdomain can use different authentication identifiers. ## What to do next with the evidence you have If you have only the domain name, inspect its published records. The [email deliverability learning center](/email-deliverability) provides the wider context for authentication and placement issues, and Palisade's [Email Security Score](/tools/email-security-score) can check public SPF, DKIM, and DMARC posture. If you have a suspicious message, use your provider's reporting controls and keep the original headers for your security team. A public DNS check cannot establish whether that specific message was fraudulent. If you have legitimate mail that is being filtered, collect a header from the exact sending path and compare its authentication results with the DNS records. New sending domains can need extra care because a clean configuration does not control a receiver's local filtering decision. See [why Gmail marks new-domain emails as spam](/email-deliverability/why-does-gmail-mark-new-domain-emails-as-spam) for that situation. ## Inspect the authentication records behind your sending domain Start with a public check of the SPF, DKIM, and DMARC records for the domain that appears in your legitimate mail's From address. Compare the result with a delivered message's Authentication-Results header before changing DNS. [Check your email security records](/tools/email-security-score) A public record check cannot prove that an application is using the intended signing domain, repair a sender configuration, monitor later changes, or guarantee inbox placement. If you need to inventory sending sources and resolve recurring DMARC alignment issues across domains, [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=existing_content_migration&utm_content=what-is-spam-email-and-how-to-prevent-it). Palisade is agentic DMARC software that analyzes DMARC aggregate-report data, identifies sending sources and authentication or alignment issues, and proposes prioritized remediation work. It does not autonomously change your DMARC policy or guarantee delivery. ## Sources and further reading - [RFC 9989: Domain-based Message Authentication, Reporting, and Conformance](https://datatracker.ietf.org/doc/html/rfc9989) - [RFC 8601: Authentication-Results header field](https://www.rfc-editor.org/rfc/rfc8601.html) - [Google Email sender guidelines](https://support.google.com/a/answer/81126) - [Microsoft 365 email authentication](https://learn.microsoft.com/en-us/defender-office-365/email-authentication-about) ## Frequently asked questions ### Is spam email always malicious? No. Some spam is unsolicited commercial advertising, while other messages attempt fraud, credential theft, or malware delivery. Treat unexpected messages cautiously because the sender's intent is not established by the message's appearance. ### Is spam the same as phishing? No. Spam is unwanted email, often distributed in bulk. Phishing is a deceptive message intended to obtain sensitive information, money, or access. A phishing message can be delivered through spam campaigns, but the terms describe different problems. ### Can SPF stop all spoofed email? No. SPF checks whether the sending infrastructure is authorized for the envelope sender domain. DMARC uses SPF and DKIM results with alignment to the visible From domain, which provides stronger protection against visible From impersonation. ### Does DKIM prove that an email is safe? No. DKIM can validate that a signature associated with a domain verified for the message. It does not establish that the content is trustworthy, that the sender's account was not compromised, or that the message should reach the inbox. ### Should I click unsubscribe in suspected spam? Not until you have verified the sender. A legitimate sender may offer a working unsubscribe control, but a suspicious message can use links to track activity or direct you to a harmful site. Use an independently verified account portal or report the message instead. --- # Why am I getting fake payment confirmation emails? Canonical: https://www.palisade.email/learning/why-am-i-getting-fake-payment-confirmation-emails > Why am I getting fake payment confirmation emails? Verify the charge outside the email, preserve evidence safely, report it, and protect exposed accounts. You are getting fake payment confirmation emails because scammers use an invented charge, renewal, invoice, or refund to make you act before checking the real account. Do not call a number, click a cancellation link, open an attachment, or reply. Open the payment provider, card issuer, or bank through an app or address you already trust, then verify whether the claimed transaction exists. ## Quick takeaways - A payment confirmation email does not prove that a payment occurred. - Verify a claimed charge in the official payment or banking account that you open yourself. - A phone number, QR code, attachment, cancellation link, or reply request can be the scam's intended next step. - Save a small, redacted incident evidence packet before reporting the message. - Message headers can identify technical delivery and authentication details, but they cannot prove sender intent or whether an attachment contains malware. - A legitimate payment platform can deliver a fraudulent invoice or money request created by a bad actor. ## What does the failure mean? The failure is an unexpected message that says, "Why am I getting fake payment confirmation emails?" It usually describes a charge or payment request that you cannot confirm through the real account. The claimed transaction is the lure. The requested action, such as calling a number to cancel, is the part that can expose your information. ```text Your payment has been confirmed. Call the number below immediately to cancel this charge. ``` The wording alone does not prove the message is fraudulent. It does establish an observable pattern: an unexpected financial claim followed by an urgent request to use a contact method supplied by the message. [CISA's phishing guidance](https://www.cisa.gov/secure-our-world/recognize-and-report-phishing) advises verifying unexpected requests through independently obtained contact details rather than links or information in the message. A sender can impersonate a bank, retailer, or payment provider through its display name, address, branding, or message content. [The Federal Trade Commission explains how phishing scams impersonate organizations to obtain money or personal information](https://consumer.ftc.gov/articles/how-recognize-and-avoid-phishing-scams). A technically delivered email is not proof that the payment request is honest. ![Checklist of the redacted incident evidence to capture from a suspicious payment confirmation email](/images/editorial/why-am-i-getting-fake-payment-confirmation-emails/why-am-i-getting-fake-payment-confirmation-emails-incident-evidence-packet.webp "1200x582") *Source: Palisade.* ![Decision flow for verifying and reporting a suspicious payment confirmation email](/images/editorial/why-am-i-getting-fake-payment-confirmation-emails/why-am-i-getting-fake-payment-confirmation-emails-payment-confirmation-email-response-flow.webp "1200x676") *Source: Palisade.* ## What usually causes it? ### A bulk phishing campaign used a familiar payment theme Scammers can send payment-themed messages to many addresses without knowing which services each recipient actually uses. A receipt from a service you have never used is a warning sign. It is not evidence that you opened an account or incurred a charge. The FTC recommends independently verifying unexpected messages that appear to come from known organizations. ### The email tries to move you to a phone call A fake confirmation may contain a support or cancellation number instead of a link. The number is part of the message evidence, not an independent support channel. CISA warns that phishing can use several communication methods to obtain sensitive information. Use the contact information in the official app, on the back of your payment card, or on a statement you already possess. ### A real payment platform delivered a fraudulent request A message can originate from a legitimate platform while an invoice or money request inside it is deceptive. [PayPal's guidance on invoice and money-request scams](https://www.paypal.com/us/cshelp/article/what-are-invoice-scams-and-money-request-scams-on-paypal-help1059) says users should review unexpected requests carefully and report suspicious activity through PayPal's official process. This differs from a forged sender address, but it needs the same independent account check. ### A known vendor's identifiers do not match A message may name a vendor you use but show a different merchant name, payment account, order number format, return address, reply-to address, or support process. Those inconsistencies are evidence to investigate. They do not, by themselves, prove fraud. Compare them with records in the vendor account you open directly. For another impersonation pattern, see [why you may receive fake law enforcement emails](/learning/why-am-i-getting-fake-law-enforcement-emails). ## How do I diagnose the failure? ### 1. Check the payment source of truth Open the payment provider's official app, type its known address into your browser, or open your card issuer's app. Review account activity, invoices, subscriptions, and order history. If the email claims a card charge, review the card statement or account activity. Do not use an email button, QR code, phone number, attachment, or reply address to reach the account. If no matching transaction or request appears in the official account, the email has not established a real charge. ### 2. Capture a labelled incident evidence packet Before deleting the email, record only the information needed for reporting or escalation. Do not open URLs or attachments to collect it. - **Visible sender details:** Display name, visible From address, and Reply-To address if available. - **Message timing and claim:** Received time, exact subject, claimed merchant, amount, renewal, refund, or invoice statement. - **Unopened artifacts:** URLs as displayed, attachment names, and file extensions. Do not download, preview, or execute them. - **Technical message evidence:** Full headers or trusted receiver-added `Authentication-Results`, if you can safely export them. - **Payment channel:** The account, card issuer, bank, or payment platform the message claims to involve. - **Report reference:** The ticket, abuse report, security-case number, or provider report confirmation. Use a redacted record such as this: ```text Incident evidence packet, illustrative only Visible From: Billing Notice <notice@unrelated-example.com> Reply-To: help@different-example.net Received: 2026-08-12 14:10 EDT Subject: Payment confirmation: $249.99 Claim: Call the listed number to cancel an annual renewal. Unopened artifact: hxxps://example.invalid/cancel Payment channel checked: card issuer mobile app Trusted receiver result: dmarc=fail header.from=payment-example.com Report reference: security-ticket-12345 ``` [Authentication-Results is a receiver-added field for communicating message authentication status](https://www.rfc-editor.org/rfc/rfc8601.html). It can help establish what the receiving system evaluated for the delivered message. It cannot prove a sender's intent, confirm that an attachment is safe or malicious, establish the legitimacy of an invoice, or explain a receiver's private filtering decision. ### 3. Choose the safe next action for the evidence you have If the message contains a suspicious link or attachment, do not interact with it. Report the message through your mailbox provider or organizational security process, then delete it. If you opened an attachment, entered information, or installed software, tell your security team exactly what happened and follow its incident process. If the notice relates to your bank, card, or payment account, verify it in the official account. For a confirmed unauthorized transaction, contact the issuer or payment platform through its independently verified dispute or fraud channel. If the message names a vendor you know but its identifiers conflict with your records, use the vendor account or established support channel to ask about the transaction. Do not engage the sender directly. ### 4. Inspect a sender domain only when it is relevant If you administer the domain named in the message, or need to document its publicly visible DNS posture, use the [DNS lookup tool](/tools/dns-lookup) to inspect its published records. A public DNS result can establish what record is visible at the time of the check. A DNS lookup cannot determine whether this email is phishing, inspect a private sending path, prove that a particular message came from the visible domain, detect malware, or predict a recipient's future inbox decision. ### 5. Escalate based on what was exposed If you only viewed the message and did not interact with it, report and delete it. If you entered a password, change that password through the official service and review recent account activity, recovery options, and payment settings. If you shared card details, bank credentials, or a one-time code, contact the issuer through the number on the card or its official app. If you granted remote access or installed software, disconnect the device from the network and contact your organization's IT or security team. Preserve the incident evidence packet for the responder, but do not include passwords, card numbers, private keys, or unredacted customer data. ## How do I fix it? ### Report the message through an official channel Use the provider's account, your mail service's reporting control, or your organization's phishing-reporting process. For a suspicious PayPal invoice or money request, follow [PayPal's official reporting guidance](https://www.paypal.com/us/cshelp/article/what-are-invoice-scams-and-money-request-scams-on-paypal-help1059). Reporting helps the relevant provider investigate the account or message. It does not reverse a confirmed charge. Use the card issuer's or payment provider's official dispute process for a real unauthorized transaction. ### Repair an exposed account through a known-good path If you entered credentials after following the email, open the affected service independently and change the password. Review sign-ins, recovery methods, forwarding settings, and payment settings that the service provides. > Do not reuse a password when resetting it. If the exposed password was used elsewhere, those accounts may also need separate password changes. ### Treat a business-domain impersonation problem as a separate issue If your organization is receiving reports that messages impersonate its own domain, preserve examples and review the exact domains and authentication results involved. The [email security learning center](/learning) covers the controls and evidence used to assess domain impersonation. Do not weaken a DMARC policy to address one recipient's suspicious email. A DMARC policy changes requested handling for mail that claims to be from your domain. It does not validate a payment request or repair an external sender's scam. ## How do I validate the repair? Repeat the same account check through the official payment, bank, or vendor channel. Confirm whether the original claimed transaction exists, whether any account changes or unauthorized activity occurred, and whether the official report or incident ticket has a reference number. For a work mailbox, verify that the security team received the original message or the approved evidence packet. If a payment provider confirms the notice was legitimate, compare the official transaction details with the message before taking further action. If it confirms the request is fraudulent, retain the report reference and delete the message. For a domain your organization controls, record the DNS result separately from the message evidence. Public DNS can show the record published during the check. It cannot prove the production sending path or resolve the legitimacy of this payment notice. ## Check public DNS evidence behind a claimed sender domain When the sender domain is relevant to an internal impersonation investigation, inspect its published DNS records before drawing conclusions from a display name or visible address. [Look up the sender domain's DNS records](/tools/dns-lookup) A DNS lookup cannot determine sender intent, inspect the original message, repair a phishing incident, monitor future changes, or guarantee why a receiving mailbox accepted the email. If your team needs to identify legitimate sending sources and authentication or alignment issues across domains it controls, [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=security&utm_content=why-am-i-getting-fake-payment-confirmation-emails). Palisade analyzes DMARC aggregate-report data, identifies sending sources and authentication or alignment issues, and proposes next policy steps for human review. It does not determine whether an external payment email is fraudulent or automatically change your DMARC policy. ## Sources and further reading - [CISA: Recognize and report phishing](https://www.cisa.gov/secure-our-world/recognize-and-report-phishing) - [Federal Trade Commission: How to recognize and avoid phishing scams](https://consumer.ftc.gov/articles/how-recognize-and-avoid-phishing-scams) - [PayPal: Invoice scams and money-request scams](https://www.paypal.com/us/cshelp/article/what-are-invoice-scams-and-money-request-scams-on-paypal-help1059) - [RFC 8601: Authentication-Results message header field](https://www.rfc-editor.org/rfc/rfc8601.html) - [Palisade DNS lookup tool](/tools/dns-lookup) ## Frequently asked questions ### Is a payment confirmation email proof that I was charged? No. Confirm the transaction in the official payment account, banking app, or card issuer account that you open independently. ### Should I call the cancellation number in the email? No. Use contact information from the official account, the back of your card, or an existing statement. A number in a suspicious message is part of the untrusted message. ### Can a real payment service send a scam invoice? Yes. A legitimate platform can deliver an invoice or money request created by a bad actor. Check the request in the official account and use the provider's official reporting process if it is suspicious. ### Can email headers prove that a payment confirmation is fake? No. Headers can provide delivery and authentication evidence for a received message. They cannot prove sender intent, validate an invoice, detect malware, or explain a receiver's private decision. ### What should I do if I entered my card details? Contact the card issuer or bank through an independently verified number or official app. Explain what information you shared, review account activity, and follow its fraud or dispute process. --- # Email authentication service: choose the right operating model Canonical: https://www.palisade.email/learning/email-authentication-service > Email authentication service options: choose self-management, a DMARC platform, or managed help based on sender ownership and report work for your domains. An email authentication service is any arrangement that keeps SPF, DKIM, and DMARC correct for the domains you send from, and it comes in three operating models. Choose self-management when a named internal owner can maintain a verified sender inventory, review DMARC evidence, and approve DNS changes. Choose a DMARC platform when recurring reports and multiple sending sources need an organized workflow. Choose a managed service when implementation and remediation ownership are missing. In every model, the domain owner should keep approval for DNS records and DMARC policy changes. ## Quick takeaways - SPF, DKIM, and DMARC are open standards, so a paid service does not replace the domain configuration or message validation they require. - A public DNS check can show a published DMARC record, but it cannot prove every production sender aligns. - DMARC reports help identify sending sources, yet receivers are not required to send every requested report. - A platform fits recurring evidence review and remediation coordination, while a managed service fits teams that need defined delivery of that work. - A DMARC pass supports authentication decisions but does not guarantee inbox placement at a receiver. - Provider scope, sender coverage, record ownership, retention, and change approval should remain open questions until confirmed in writing. ## Who this comparison is for This comparison is for IT, security, deliverability, and MSP operators choosing who will operate email authentication for domains that send legitimate mail. It compares operating models, not named vendors or email delivery services. The decision is broader than publishing a record. The ongoing work can include maintaining a sender inventory, inspecting SPF, DKIM, and DMARC evidence, investigating unknown sources, coordinating with sender owners, and deciding when a DMARC policy can advance. If the protocols themselves are unfamiliar, begin with [what email authentication is and why it matters](/learning/what-is-email-authentication-and-why-does-it-matter). This article does not evaluate inbound filtering, consumer account authentication, or an individual ESP setup. Buyers comparing broader platforms can use the [Palisade comparison hub](/compare) alongside this operating-model decision. ## How the options were evaluated The criteria below were defined before selecting a model and checked against current primary sources on August 12, 2026: - Sender and domain complexity: How many visible From domains, subdomains, ESPs, CRMs, support platforms, transactional systems, and relays need to be accounted for? - Report evidence and ownership: Who receives and interprets DMARC aggregate-report evidence, and who investigates an unrecognized source? - Remediation capacity: Who can work with the sender owner to correct SPF, DKIM, or alignment failures without disrupting legitimate mail? - Policy authority: Who can approve changes to DNS and the DMARC policy? - Documented scope: Does the proposed service explicitly state the domains, senders, reporting work, implementation work, and approvals it covers? [RFC 9989's DMARC deployment guidance](https://www.rfc-editor.org/rfc/rfc9989.html) places report collection and analysis, stream remediation, and enforcement decisions with the domain owner. A service can support that work, but it does not remove the need for an accountable owner. For senders that send more than 5,000 messages per day to personal Gmail accounts, [Google's email sender guidelines](https://support.google.com/mail/answer/81126) require SPF, DKIM, DMARC, and alignment for DMARC. Those requirements make production evidence more useful than a category label. A green setup indicator or a published DNS record is not proof that a real message from every sender uses the intended authenticated path. ## Self-managed email authentication - Best fit: One or a few domains, a short and verified sender inventory, and an internal operator who can coordinate DNS and sender-platform changes. - Relevant evidence: [RFC 7208](https://www.rfc-editor.org/rfc/rfc7208.html) defines SPF evaluation, while [RFC 6376](https://www.rfc-editor.org/rfc/rfc6376.html) defines DKIM signing and verification. Validate both with a delivered message from the production sending path, not only with DNS. - Tradeoff: The standards do not provide an operating queue. An internal owner still needs to inspect reports, document legitimate sources, resolve failures, and decide when policy changes are safe. Self-management works when the workload is understood and stays small enough to review. It becomes harder when a marketing platform, ticketing system, invoice sender, or new business unit begins using the domain without a clear handoff. Use four layers to validate a self-managed implementation. Check DNS through the authoritative server and a public resolver. Confirm the sender vendor's verification status. Inspect `Authentication-Results` from a real message sent through the exact production path. Then review DMARC aggregate reports as data accumulates. > Do not move a DMARC policy toward enforcement based only on a DNS lookup. A published policy cannot show whether every legitimate source is signing or aligned. ## DMARC monitoring platform - Best fit: Multiple sending systems or domains, recurring DMARC report review, or a need to convert source evidence into assigned remediation work before changing policy. - Relevant evidence: [RFC 9989's reporting model](https://www.rfc-editor.org/rfc/rfc9989.html) lets domain owners request reports, but receivers are not obligated to send every requested report. A platform should therefore make its evidence and unresolved gaps visible. - Tradeoff: A platform can organize evidence and remediation work, but it cannot make an unconfigured sender authenticate, control a receiver's mailbox decision, or safely approve DNS changes on behalf of the domain owner. A platform is an operating choice when the issue is recurring work, rather than lack of a DMARC record. Evaluate the platform with the same questions used for self-management: which sources appear in reports, who owns each finding, how are changes reviewed, and what happens when a new sender appears? Confirm the service's scope directly. Pricing, report retention, supported integrations, portfolio controls, exports, implementation services, and approval workflows vary by provider and should not be inferred from the phrase "DMARC platform." A point-in-time public check still has a role. Run the domain through the [DMARC checker](/tools/dmarc) before making a buying decision to inspect the published record and policy. That result does not prove the production sending path, continuous state, a receiver's private filtering decision, or future delivery. ## Managed email authentication service - Best fit: A team that lacks practical ownership for sender inventory, cross-team remediation, phased DMARC policy work, or multi-domain coordination. - Relevant evidence: [RFC 9989](https://www.rfc-editor.org/rfc/rfc9989.html) treats remediation and enforcement decisions as domain-owner responsibilities. A managed provider's statement of work should therefore identify its delivery scope and the domain owner's approval role. - Tradeoff: A managed service may cover advice, implementation, reporting, remediation coordination, or some combination. Do not assume it covers every ESP, DNS zone, sender, mailbox provider issue, or policy change unless the agreement says so. A managed model can reduce the internal effort required to coordinate work, but it should make ownership more explicit, not less. Ask who maintains the sender inventory, who requests access to a DNS provider, who reviews a proposed record, who validates a real delivered message, and who authorizes the DMARC policy. For an MSP, also establish the client boundary. Each customer domain needs a named approver, a record of its legitimate senders, and a process for handling sources that are unknown or not yet aligned. A managed engagement without those decisions can produce reports without resolving the operational gap. ## How to choose ### 1. Inventory the real sending paths List each visible From domain and the systems that send mail for it. Include marketing ESPs, CRMs, support platforms, transaction services, internal relays, and subdomains. Record who owns each system and whether a delivered production message is available for validation. If a legitimate sender fails DMARC, use [email authentication failure guidance](/learning/email-authentication-failure) to separate DNS, sender-vendor, message, and report evidence before changing a record. ### 2. Name the recurring owner Choose self-management if an internal owner can review evidence and coordinate fixes. Choose a platform if source evidence and remediation need a continuing workflow. Choose a managed service if the missing capability is accountable implementation or coordination. Do not treat a provider label as evidence of policy authority. The domain owner should approve any DNS or DMARC policy change after the relevant sending path has been validated. ### 3. Validate before changing the DMARC policy For each legitimate source, confirm the published DNS state, the sender vendor's status, a delivered message's authentication results, and DMARC report evidence once available. [RFC 9989 explains DMARC alignment and receiver discretion](https://www.rfc-editor.org/rfc/rfc9989.html). A passing DMARC result does not require every receiver to make the same inbox decision. ![Decision flow for assigning self-managed, platform, or managed email authentication operations](/images/editorial/email-authentication-service/email-authentication-service-operating-model-flow.webp "1200x767") *Source: Palisade.* ![Email authentication service ownership checklist for sender inventory, report review, remediation, and policy approval](/images/editorial/email-authentication-service/email-authentication-service-ownership-checklist.webp "1200x524") *Source: Palisade.* Use this decision record to make the remaining evidence gap visible: ```yaml email_authentication_service_decision: checked_on: "2026-08-12" domains_in_scope: - "yourdomain.com" sender_inventory: "verified | incomplete" report_review_owner: "named person or team | unassigned" remediation_owner: "named person or provider | unassigned" policy_approval: "domain owner" preferred_model: "self-managed | platform | managed service" open_question: "Which legitimate sending path still lacks aligned SPF or DKIM?" ``` The record is incomplete until the owner confirms the sender list with message evidence. A DNS record can be correct while an application uses a different return path or does not sign with the expected DKIM domain. ## Turn report evidence into an owned authentication plan If recurring report review and sender remediation are the reason for the purchase, evaluate a platform on the evidence it can organize and the approval boundary it preserves. [Palisade's pricing page](https://www.palisade.email/pricing) describes DMARC report parsing, sender classification, notifications, reporting, and MSP portfolio features. Its [DMARC Agent guidance](https://docs.palisade.email/guides/fixing-authentication-issues/) describes identifying source-specific authentication findings and recommended actions from report evidence. Palisade is agentic DMARC software for teams that want help doing the report-analysis and remediation-planning work. A human reviews the evidence and applies any DNS or policy change. Start with the public DMARC record, then use an ongoing workflow only when the decision record shows recurring evidence and ownership work. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=compare&utm_content=email-authentication-service) Palisade does not control a receiver's inbox decision, authenticate an unconfigured sender automatically, or apply DNS and policy changes without human review. ## Sources and further reading - [RFC 9989: Domain-based Message Authentication, Reporting, and Conformance](https://www.rfc-editor.org/rfc/rfc9989.html) - [RFC 7208: Sender Policy Framework](https://www.rfc-editor.org/rfc/rfc7208.html) - [RFC 6376: DomainKeys Identified Mail](https://www.rfc-editor.org/rfc/rfc6376.html) - [Google email sender guidelines](https://support.google.com/mail/answer/81126) - [Palisade pricing and plan comparison](https://www.palisade.email/pricing) - [Palisade guidance for fixing authentication issues](https://docs.palisade.email/guides/fixing-authentication-issues/) ## Frequently asked questions ### Do I need an email authentication service for one domain? Not always. One domain can be self-managed when its sender inventory is short, the internal owner can maintain DNS and sender settings, and the team can validate real messages and review DMARC evidence. Reassess the model when new senders appear or report review becomes unowned work. ### Is a DMARC platform the same as a managed email authentication service? No. A DMARC platform organizes evidence, reporting, and remediation workflow. A managed service adds a defined delivery commitment, such as implementation help or remediation coordination. Confirm the provider's exact scope, sender coverage, and approval process before treating either model as a substitute for the other. ### Does a published DMARC record prove my email authentication works? No. A published DMARC record proves only that public DNS returns that record at the time of the lookup. Validate the sender vendor, a delivered production message's authentication results, and DMARC report evidence to determine whether a legitimate sender aligns. ### Can a DMARC pass guarantee Gmail inbox placement? No. DMARC validation supports authentication and policy handling, but mailbox providers retain their own delivery and filtering decisions. [RFC 9989](https://www.rfc-editor.org/rfc/rfc9989.html) states that a DMARC pass does not guarantee delivery to the inbox. ### Who should approve a DMARC policy change? The domain owner should approve it. A provider or platform can supply evidence and recommend a next policy step, but the owner should confirm that legitimate production sources have been validated before applying a DNS or policy change. --- # How many SPF records can a domain have and why do multiple records cause PermError? Canonical: https://www.palisade.email/learning/how-many-spf-records-per-domain > Multiple SPF records at one DNS name cause PermError. Learn why receivers do not merge them, how to combine legitimate senders, and how to retest. Multiple SPF records at one exact domain or subdomain cause SPF `permerror`. A receiver does not merge the policies or choose one. Build one replacement that keeps every approved sender mechanism, publish it as the only `v=spf1` TXT value at that name, and retest each production sending path. Leave unrelated TXT records in place. ## Quick takeaways - One exact DNS owner name can have one selected `v=spf1` policy. - Two or more SPF policy records at the same name produce `permerror`. - Other TXT values, including domain-verification values, can coexist with an SPF record. - A subdomain is a different DNS name and can publish its own SPF policy. - Combine authorized mechanisms into one reviewed record before removing duplicates. - A consolidated record can still fail if it exceeds SPF's DNS-querying-term limit. ## Why SPF permits one policy at an exact name [SPF record selection in RFC 7208](https://www.rfc-editor.org/rfc/rfc7208.html#section-4.5) applies to the exact DNS name SPF evaluates. When selection finds one matching SPF record, evaluation can continue. When it finds two or more matching records, the result is `permerror`. The count is per DNS owner name, not per company or registered domain. For example, `yourdomain.com` and `mail.yourdomain.com` are separate names. Microsoft also states in its [SPF configuration guidance](https://learn.microsoft.com/en-us/defender-office-365/email-authentication-spf-configure) that each domain or subdomain needs its own SPF TXT record, with one SPF record at that name. SPF evaluates the envelope sender domain or, when needed, the HELO or EHLO identity. The visible From address can be different. Read [what DNS records a business email domain needs](/learning/dns-records-for-business-email) alongside this rule when you are checking the wider DNS configuration for a sending domain. ## When the answer changes The answer changes only when the DNS name changes. A policy at `yourdomain.com` does not automatically become an SPF policy at `news.yourdomain.com`. If a service sends with `news.yourdomain.com` as its envelope domain, SPF can query that subdomain as its own exact name. That subdomain may publish one `v=spf1` policy. Ordinary TXT records do not count as extra SPF policies. RFC 7208 selects records that begin with the SPF version prefix, `v=spf1`. These can coexist at one name: ```text yourdomain.com. TXT "v=spf1 include:mail.example.net -all" yourdomain.com. TXT "service-verification=example-value" ``` Only the first illustrative TXT value is an SPF policy. The second is unrelated TXT data. > Do not add a vendor's new `v=spf1` value beside an existing SPF policy as a temporary measure. The duplicate state itself can cause SPF `permerror` for mail using that name. Review each sender mechanism before consolidation. An `a` mechanism, for example, authorizes a domain's address records under SPF rules. See [what the SPF a mechanism does](/learning/glossary/spf-a-mechanism) before retaining or adding it to a production policy. ## Common duplicate-record cases ### A provider wizard added a second policy A mailbox or marketing provider may show a complete `v=spf1` example even when the domain already has SPF. Publishing that example beside the existing record creates the duplicate. Extract the new provider's authorization mechanism, place it before the existing final `all` term, and keep one version token. Do not copy an `include`, IP range, or qualifier until the provider's current instructions and the actual envelope-sender domain agree. Some services authenticate a dedicated return-path subdomain and do not need a new mechanism at the root domain. ### A DNS interface displays one TXT value as several strings A long TXT value may appear as adjacent quoted strings in a DNS interface or lookup result. Those strings can belong to one TXT record and are concatenated for SPF evaluation. They are not automatically multiple SPF records. The failure occurs when DNS returns two or more independently selectable TXT records beginning with `v=spf1` at the same owner name. Preserve the raw DNS answer in the change record so the reviewer can distinguish a split value from two policies. ### The records are at different owner names An SPF policy at `yourdomain.com` and another at `news.yourdomain.com` are not duplicates. SPF selects a policy for the exact MAIL FROM or HELO identity under evaluation. Check the domain shown in the receiver's SPF result before merging anything across the parent and subdomain. ## Worked example: merging duplicate SPF policies These two SPF records at the same exact owner name are invalid together: ```text yourdomain.com. TXT "v=spf1 include:mail.example.net -all" yourdomain.com. TXT "v=spf1 ip4:192.0.2.44 -all" ``` If both sending sources are current and authorized, replace both with one reviewed policy: ```text yourdomain.com. TXT "v=spf1 include:mail.example.net ip4:192.0.2.44 -all" ``` The domain, service name, and IP address are illustrative only. Do not copy them into production. Obtain each real mechanism from the sender's current documentation and confirm that the sender still uses the envelope domain you are editing. ![Record-selection example showing two conflicting SPF policies replaced by one combined policy](/images/editorial/how-many-spf-records-per-domain/how-many-spf-records-per-domain-spf-record-selection.webp "1200x533") *Source: Palisade.* Use this decision rule: - If two TXT values at the same name start with `v=spf1`, inventory the senders and create one replacement policy. - If one TXT value starts with `v=spf1` and another is a verification token, retain both. - If the policies are at different names, assess each name separately instead of merging them. - If the replacement contains `include`, `a`, `mx`, `ptr`, `exists`, or `redirect` mechanisms, count SPF DNS-querying terms before publishing. [RFC 7208's SPF processing limits](https://www.rfc-editor.org/rfc/rfc7208.html#section-4.6.4) require SPF implementations to limit DNS-querying terms to 10. Exceeding that limit also returns `permerror`. Nested `include:` records count toward the limit, so a short-looking policy can still exceed it. ## How to diagnose multiple SPF records ### Confirm the exact SPF identity Start with a delivered message or rejection that identifies the SPF domain. In a trusted receiver-added `Authentication-Results` field, that identity commonly appears beside `smtp.mailfrom` or `smtp.helo`. Do not assume the visible `From` domain is the DNS name SPF checked. Record the message path, application, envelope domain, and result before making a DNS change. This baseline gives you a same-path test after the repair. ### List every selected SPF value Query TXT records at the exact owner name and copy every separate value beginning with `v=spf1`. Keep unrelated verification and service TXT values out of the merge. If a provider splits one long TXT value into quoted chunks, preserve their order and treat them as one logical record. Compare the authoritative DNS answer with at least one public resolver. A resolver can retain an older duplicate while cached data remains valid, so capture which server returned each result and when. ### Map each mechanism to an approved sender For every `include`, `ip4`, `ip6`, `a`, `mx`, `exists`, or `redirect` term, identify the sender and owner that still needs it. Mark an unfamiliar term as unresolved instead of deleting it. A duplicate-record repair that removes an active sender replaces one authentication failure with another. Keep the original final qualifier as the default unless the change owner separately approves a policy change. Combining duplicate records fixes record selection. Changing `~all` to `-all`, or the reverse, changes the result returned for unmatched senders and should be reviewed as a different decision. ### Build and review one replacement Create one candidate with a single `v=spf1` token, all confirmed authorization mechanisms, and one final `all` term. Count the full reachable DNS-querying path, including nested includes, before publication. The [SPF record format guide](/learning/spf-record-syntax-explained-mechanisms-qualifiers) explains how those terms are evaluated. Have the sender owners review the candidate against their current configurations. Then publish the replacement in one controlled change so the domain does not remain with two policies while an obsolete record waits for a later cleanup. ## Check the published result before changing mail flow Start with the affected exact DNS name, then list every TXT value returned for it. Identify every value beginning with `v=spf1`, map each mechanism to an active sender, and prepare one replacement record. Keep unrelated TXT values unchanged. After publishing, check authoritative DNS and at least one public resolver. Then inspect the one published SPF policy and its lookup path. Microsoft documents the same operational approach: keep authorized senders in one SPF record rather than publishing separate policies for each sender. Next, send mail through every active production platform. Inspect receiver-added `Authentication-Results` fields in delivered-message headers. [RFC 8601](https://www.rfc-editor.org/rfc/rfc8601.html) defines that field for communicating authentication results. Finally, use DMARC aggregate reports when available to find sources that still fail authentication or alignment after the DNS repair. For more email-authentication context, visit the [email authentication learning hub](/learning). ## Check the published SPF policy Use the [Palisade SPF checker](/tools/spf) after the consolidated TXT value resolves publicly. Enter the affected domain to inspect the published SPF policy and identify an obvious duplicate-record result before you test production mail. [Check the SPF record](/tools/spf) A public DNS check cannot prove that every production sender uses the expected envelope domain, that a delivered message passed SPF, or that a receiver will accept the message. ## Sources and further reading - [RFC 7208: Sender Policy Framework](https://www.rfc-editor.org/rfc/rfc7208.html) - [RFC 7208 section 4.5: SPF record selection](https://www.rfc-editor.org/rfc/rfc7208.html#section-4.5) - [RFC 7208 section 4.6.4: SPF DNS-querying-term limit](https://www.rfc-editor.org/rfc/rfc7208.html#section-4.6.4) - [Microsoft guidance for SPF TXT records](https://learn.microsoft.com/en-us/defender-office-365/email-authentication-spf-configure) - [RFC 8601: Authentication-Results header field](https://www.rfc-editor.org/rfc/rfc8601.html) ## Frequently asked questions ### Can a domain have several TXT records? Yes. A DNS name can publish several TXT values. The one-record restriction applies to selected records beginning with `v=spf1`, not to verification tokens or other non-SPF TXT data. ### Can a subdomain have its own SPF record? Yes. A subdomain is a separate DNS owner name and can publish one SPF policy. The parent domain's SPF policy does not automatically authorize mail that SPF evaluates against the subdomain. ### Will receivers merge two SPF records? No. RFC 7208 specifies `permerror` when two or more SPF records are selected for the same name. Consolidate authorized mechanisms into one policy. ### Should I remove duplicate SPF records before I know every sender? Only after you have a reviewed replacement policy that retains each legitimate sender. Leaving duplicate policies live causes its own SPF error, while removing an active sender can break that sender's authentication. ### Does one SPF record guarantee an SPF pass? No. The connecting sender must match an authorized mechanism, SPF evaluation must complete within its processing limits, and the message must use the envelope or HELO identity you expected. --- # AI powered email security: what the label actually covers Canonical: https://www.palisade.email/learning/ai-powered-email-security > AI powered email security covers content and behavior models, not domain authentication. See what vendors document, and how to test any AI claim. AI powered email security is a marketing label, not a product category. Under it sit two documented mechanisms: statistical models that score message content and sender patterns, and learned baselines of who normally emails whom. Both operate on inbound mail, and both sit above authentication rather than replacing it. No model changes what SPF, DKIM, and DMARC cover. Judge any claim by the layer it works in, the data it reads, the action it takes, and who approves that action. ## Quick takeaways - **The label covers two jobs.** Scoring content and sender behavior on inbound mail, and impersonation checks built on learned contact history. - **Authentication is a separate layer.** RFC 9989 puts lookalike domains and display name abuse outside DMARC's scope, and Microsoft documents that a lookalike domain with valid records passes SPF, DKIM, and DMARC. - **Deployment mode is not detection method.** Gateway or API is a mail flow decision, and vendors document both routes for one product. - **Accuracy comes with a direction, not a number.** Microsoft states that raising its phishing threshold increases false positives, and publishes no rate. - **Test a claim by rewriting it.** A capability fits in one sentence naming the plan, the inputs, the verdict, and the action. Marketing language does not. ## What the term means Vendors apply the label to statistical models running at different points in mail handling, and the documentation is more specific than the marketing. Microsoft calls one of these mechanisms implicit email authentication. Its inbound checks add sender reputation, sender history, recipient history, behavioral analysis, and other techniques on top of SPF, DKIM, and DMARC in order to identify forged senders. [Microsoft's anti-phishing protection overview](https://learn.microsoft.com/en-us/defender-office-365/anti-phishing-protection-about) lists it among the protections present for every cloud mailbox, names the signal categories, and publishes no model details. Google describes Gmail's filters as machine learning powered by user feedback, and names the inputs: characteristics of the IP address, domains and subdomains, whether bulk senders are authenticated, and user input. The same [Google Workspace post on Gmail's spam filters](https://workspace.google.com/blog/identity-and-security/an-overview-of-gmails-spam-filters) states that more than 99.9 percent of spam, phishing, and malware never reaches inboxes, with no published methodology or denominator behind it. Abnormal describes a third shape. Its [inbound email security page](https://abnormal.ai/products/inbound-email-security) describes a behavioral baseline for every employee and vendor, scored against signals it says a gateway cannot access: authentication events, calendar activity, and internal threads. It connects by API with no MX changes. All three share one shape: a model reads signals the protocol layer never looks at, then returns a verdict on one message for one recipient. It aims at the [social engineering half of phishing](/learning/what-is-phishing), which authentication was never designed to judge. ![Where AI claims apply across the email security stack, and what no layer stops](/images/editorial/ai-powered-email-security/ai-powered-email-security-layers.webp "1200x488") *Source: Palisade.* ## What it does and does not do What it does, in documented terms, is decide about content and sender behavior one recipient at a time. Mailbox intelligence in Defender for Office 365 is the clearest published example. Microsoft states that it uses artificial intelligence to determine user email patterns with their frequent contacts. The same [anti-phishing policies reference](https://learn.microsoft.com/en-us/defender-office-365/anti-phishing-policies-about) documents the failure mode: mailbox intelligence protection does not act when the sender and recipient have exchanged mail before. Two toggles control it, and the second one, which lets it act on impersonation, is off by default. Deployment mode is a separate axis. Proofpoint documents the same protection [through a secure email gateway or through an API integration](https://www.proofpoint.com/us/products/email-security-and-protection/email-protection), and calls the API route the low touch rollout. Where a product sits in mail flow changes your rollback plan, not the quality of its verdicts. Buyers lose that distinction when weighing an API product against a [secure email gateway](/learning/email-security-gateway). What it does not do is change what authentication covers. [RFC 9989 section 2.2](https://www.rfc-editor.org/rfc/rfc9989.html#section-2.2) states that DMARC can only combat specific forms of exact-domain spoofing directly, and places visually similar domain names (cousin domains) and abuse of the human readable display name outside its scope. Alignment is evaluated against the domain in the From header, exactly in strict mode and at the organizational domain in relaxed mode, so nothing in [the DMARC mechanism](/learning/what-is-dmarc) reads the display name a person sees. Microsoft states the same boundary from the other side: impersonation can pass SPF, DKIM, and DMARC when the attacker registers a lookalike domain and publishes valid records for it. So the layers answer different questions. Authentication decides whether a message may claim your domain. Content filtering decides whether this message is trying to defraud this person. An AI claim in one layer is not evidence about the other. ![How to evaluate an AI email security claim by layer, inputs, verdict, and action](/images/editorial/ai-powered-email-security/ai-powered-email-security-evaluation-flow.webp "1200x885") *Source: Palisade.* ## How to evaluate an AI claim Rewrite the claim as one sentence with four blanks, filled from published documentation rather than a slide: > On plan [name], this feature reads [inputs], decides [verdict], and then [action] without a human. - **Plan.** Microsoft's own split shows why this blank comes first. Impersonation settings and phishing email thresholds appear only in the Defender for Office 365 column of its feature comparison, and protection for all cloud mailboxes excludes impersonation protection. Several impersonation features are also unconfigured in the default policy, so an admin has to turn them on. - **Inputs.** Named signals beat named intelligence. [Proofpoint's Nexus page](https://www.proofpoint.com/us/platform/nexus) names separate components with separate jobs: a text model aimed at business email compromise wording, a relationship graph for deviations in normal user communication, computer vision for threats in images and QR codes, a threat intelligence component, and machine learning using supervised and unsupervised methods. Each name is a question you can ask in a demo. - **Verdict.** Ask which way the errors go. Microsoft ties its four phishing email thresholds, labelled Standard, Aggressive, More aggressive, and Most aggressive, to the sensitivity of applying machine learning models, and states that the chance of good messages marked as bad rises as you raise the setting. That is a direction, not a rate, and the rate comes from a pilot in your tenant. - **Action.** Google's [advanced phishing and malware settings](https://knowledge.workspace.google.com/admin/gmail/advanced/advanced-phishing-and-malware-protection) show what an operator configures: discrete settings for encrypted attachments, attachments carrying scripts, unusual attachment types, shortened links, similar domain names, employee name spoofing, and unauthenticated mail. Each offers three outcomes: a warning banner, move to spam, or quarantine for review. The page describes no model, which does not prove none runs, but the surface you operate is policy. Where a page mixes both registers, take the named half. [Mimecast's email security page](https://www.mimecast.com/products/email-security/) names anomaly detection with social graphing, sandboxing for evasive payloads, and computer vision for imitated branding and fake login pages, and states both deployment modes. Beside those it uses broad wording about pairing AI and machine learning with large mail volumes, which specifies nothing a buyer can test. Both registers on one page is the normal case, not a vendor flaw. [NIST's AI Risk Management Framework](https://www.nist.gov/itl/ai-risk-management-framework) supplies neutral vocabulary for the governance half. It is voluntary, was released on 26 January 2023 with a generative AI profile added on 26 July 2024, and rests on four functions: Govern, Map, Measure, and Manage. NIST certifies no product, so nothing is compliant with it. Measure gives you a defensible reason to ask how a claim was evaluated, and Manage one to ask who reviews a wrong verdict. ## Decision rule Start from the attack you have, not the label on the box. - **A person is being deceived by a message.** Invoice fraud, a cousin domain, a display name copied from your finance lead. The fix belongs in the content layer, so the AI claim matters. Run the four blank rewrite against every shortlisted vendor and get the missing answers in writing before the pilot. - **Other people are receiving mail that claims your domain.** The fix is authentication: SPF and DKIM aligned with the From domain, then a DMARC policy telling receivers what to do with the rest. No inbound model changes that, in your tenant or anyone else's. The second case is the layer Palisade works in, and the boundary is worth stating out loud. Palisade is agentic DMARC software. Its [documented scope](https://docs.palisade.email/) is DMARC, SPF, DKIM, BIMI, and MTA-STS record management plus deliverability monitoring, and nothing in it inspects, classifies, or filters message content. The agent investigates every sender, drafts every fix, and proposes each policy step, and you approve before anything ships. To measure the authentication half before comparing inbound vendors, run the domain through Palisade's [email security score](/tools/email-security-score). It reads public DNS and reports what your domain publishes today for SPF, DKIM, and DMARC. It cannot tell you how well an inbound filter performs, and it never sees your mail. For a provider-specific implementation of these authentication checks, see [Barracuda email security](/learning/barracuda-email-security). ## Sources and further reading - [Microsoft, anti-phishing protection in Microsoft 365](https://learn.microsoft.com/en-us/defender-office-365/anti-phishing-protection-about) - [Microsoft, anti-phishing policies](https://learn.microsoft.com/en-us/defender-office-365/anti-phishing-policies-about) - [RFC 9989](https://www.rfc-editor.org/rfc/rfc9989.html): scope limits and alignment modes. - [Google Workspace, an overview of Gmail's spam filters](https://workspace.google.com/blog/identity-and-security/an-overview-of-gmails-spam-filters) - [Google Workspace admin help, advanced phishing and malware protection](https://knowledge.workspace.google.com/admin/gmail/advanced/advanced-phishing-and-malware-protection) - [Proofpoint, the Nexus AI platform](https://www.proofpoint.com/us/platform/nexus) - [Proofpoint, email protection deployment](https://www.proofpoint.com/us/products/email-security-and-protection/email-protection) - [Abnormal, inbound email security](https://abnormal.ai/products/inbound-email-security) - [Mimecast, advanced email security](https://www.mimecast.com/products/email-security/) - [NIST, AI Risk Management Framework](https://www.nist.gov/itl/ai-risk-management-framework) - [Palisade documentation](https://docs.palisade.email/) ## Frequently asked questions ### Does AI powered email security replace DMARC? No. They work on different layers. DMARC decides whether a message may claim your domain, using SPF and DKIM results aligned against the From domain. An inbound AI product decides whether a message reaching one recipient looks like fraud. RFC 9989 places cousin domains and display name abuse outside DMARC's scope, so each layer leaves work the other has to do. ### Is an AI email security product different from a secure email gateway? Not necessarily, and the label does not settle it. Gateway and API describe where a product sits in mail flow, which is a routing and rollback question. Proofpoint and Mimecast both document the same protection through either route, so ask about the signals and the model independently of the deployment diagram. ### Can AI stop lookalike domain attacks? Only in the content layer, and only for cases its baseline covers. Microsoft's mailbox intelligence learns contact history and can flag a sender who never corresponded with the recipient, but it takes no action once the two parties have exchanged mail. Authentication cannot help here, because the attacker owns the lookalike domain. ### What should I ask a vendor about its AI detection? Ask them to complete one sentence: on this plan, the feature reads these inputs, decides this verdict, and then takes this action without a human. Then ask which plan carries it, whether it is on by default, which way the errors move as sensitivity rises, and who reviews a wrong verdict. ### How do I tell a documented capability from a marketing claim? A documented capability names the mechanism, the signals it reads, and the action it takes, so a pilot can test it. Marketing language pairs an adjective with a technology noun and leaves nothing to test. Most vendor pages carry both registers, so take the named half into your evaluation and treat the rest as a demo question. --- # How should MSPs price DMARC management services? Canonical: https://www.palisade.email/learning/how-should-msps-price-dmarc-management-services > How should MSPs price DMARC management services? Scope onboarding, evidence review, remediation ownership, exceptions, approvals, and reporting separately. MSPs should price DMARC management around the work they agree to own, not the act of publishing one DNS record. Quote onboarding separately for discovery and sender inventory, then define recurring scope by domain portfolio, evidence reviews, remediation coordination, approvals, exception handling, and reporting. Keep client, sender, DNS host, and MSP responsibilities explicit before assigning a package. ## Quick takeaways - Separate uneven onboarding work from the recurring operational service. - Domain count helps define portfolio scope, but it does not measure sender complexity or approval effort. - Price recurring work around dated evidence reviews, change intake, exceptions, and client reporting. - Put DNS authority and sender-platform ownership in the service record before promising remediation work. - Treat urgent delivery incidents and unidentified senders as visible exceptions with a decision owner. - A public DNS check can inspect a published record, but it cannot prove every production sender or future receiver outcome. ## Operating context and ownership DMARC management becomes a different service when an MSP operates it for multiple clients. Each client can have different domains, DNS hosts, sender platforms, business-critical sending periods, contacts, and approval rules. The commercial scope needs to reflect the workflow needed to manage those differences consistently. The MSP can collect evidence, maintain an operating record, coordinate remediation, prepare recommendations, and report open work. The client retains business approval and any authority it has not delegated. The DNS host publishes DNS records. Each sender owner controls configuration in its platform. Receiving mailbox providers apply their own message-handling decisions. [DMARC policy and identifier alignment are specified in RFC 9989](https://datatracker.ietf.org/doc/html/rfc9989). The service-design framework below is Palisade guidance for MSP operations, not an RFC requirement or evidence of market pricing. Define the handoff points before the quote: - The client approves business risk, policy changes, and any work not delegated to the MSP. - The MSP owns the agreed evidence review, coordination, operational record, and reporting artifact. - The DNS host owner publishes or approves DNS changes according to the agreed change process. - The sender owner enables and validates authentication settings in the relevant platform. - The mailbox provider controls its own local treatment of received mail. This boundary matters when pricing remediation. An MSP can identify an unaligned sender and prepare a ticket, but the platform owner may need to enable custom DKIM or configure a return path. A managed-service scope should state whether that coordination is included and who has authority to make the change. ![Pricing decision framework showing portfolio scope, evidence, remediation ownership, exceptions, approvals, and reporting cadence](/images/editorial/how-should-msps-price-dmarc-management-services/how-should-msps-price-dmarc-management-services-pricing-framework.webp "1200x582") *Source: Palisade.* ## Evidence to collect Collect enough information to estimate review and coordination work before placing a client in a service package. Keep client-reported senders separate from sources observed in DMARC aggregate reports or in a delivered production message. A known marketing platform with a named owner is different from an unexplained source that needs investigation. Use one portable service-design record for each client-domain combination. This is a Palisade-authored pricing-decision framework, not market data. ```yaml client: example-client domain: yourdomain.com portfolio_scope: included_domains: 3 subdomains_in_scope: false sender_inventory: known_senders: client-supplied change_rate: occasional evidence_and_reporting: public_dns_review: monthly delivered_message_evidence: requested-for-changes aggregate_report_review: monthly remediation_boundary: msp: coordinate-and-propose client_or_sender_owner: approve-and-configure escalation_expectations: active_mail_flow_incident: separate-approved-work reporting_cadence: monthly-client-summary excluded_work: sender-platform-configuration-not-delegated assumptions_approval_reference: client-change-policy-2026-08 owner: msp-service-owner next_action: confirm-sender-owners-and-approval-path review_on: 2026-09-01 ``` ![Four evidence layers for pricing DMARC management: DNS, sender platform, delivered message, and aggregate reports](/images/editorial/how-should-msps-price-dmarc-management-services/how-should-msps-price-dmarc-management-services-evidence-layers.webp "1200x699") *Source: Palisade.* The fields make pricing assumptions reviewable. They also prevent a quote from treating a missing sender inventory, unclear DNS authority, or frequent platform changes as invisible work. For each client-domain record, collect: - Portfolio scope, including domains, subdomains, and excluded domains. - Known senders, their owners, and the expected rate of sender additions or changes. - Public DNS evidence, sender-platform status where available, delivered-message evidence, and aggregate-report evidence. - The client approver, technical contact, DNS change owner, and MSP service owner. - Remediation boundaries, including whether the MSP only coordinates or may make delegated changes after approval. - Escalation expectations for business-critical mail and active delivery incidents. - Reporting audience, cadence, and the client artifact required. - Excluded work, assumptions, approval reference, and the next review date. Use the [DMARC checker](/tools/dmarc) when the question is whether a public DMARC record is currently published. A public check does not prove that the production sender uses the intended authentication configuration, that reports continue to arrive, or that a mailbox provider will accept a particular message. A working service needs evidence at four layers: authoritative and public DNS, the sender platform's current status, a real delivered message from the exact production path, and aggregate-report evidence after data accumulates. An `Authentication-Results` field records an evaluator's authentication assessment, but it is not a universal promise about every receiver's decision. Its syntax and trust boundary are defined in [RFC 8601](https://www.rfc-editor.org/rfc/rfc8601.html). ## How to run the workflow ### 1. Define the quoteable service unit Owner: MSP service lead. Input: client domain list, intended service outcome, and available contacts. Output: a documented service unit. Choose a unit technicians can administer consistently. It can be a domain with a specified review cadence, a client portfolio with an agreed domain allowance, or a recurring package with separately approved exception work. Do not quote undefined "DMARC management" before defining the evidence reviews, reporting, and sender-change responsibilities included. ### 2. Separate onboarding from recurring management Owner: commercial owner and service lead. Input: service-design record and identified evidence gaps. Output: an onboarding statement and recurring service boundary. Onboarding may include sender-inventory collection, DNS review, ownership mapping, report-destination coordination, remediation planning, and an initial policy recommendation. Recurring work may include scheduled evidence review, sender-change intake, exception tracking, and a client reporting artifact. Setup effort is uneven. A client with missing access, unknown sources, or urgent remediation may require more coordination before it reaches normal operations. Describe that work in the onboarding scope instead of absorbing it into an unspecified recurring fee. ### 3. Set package boundaries by operating complexity Owner: MSP service designer. Input: normalized client-domain records. Output: technician-usable package rules. Use boundaries based on repeatable operational work. This is a Palisade framework, not a statement about what other providers charge. - Baseline scope includes defined domains, a client-supplied sender inventory, scheduled public-record checks, and a fixed review cadence. - Managed scope includes baseline work plus aggregate-evidence review, remediation coordination, an exception register, and a recurring client artifact. - Custom scope covers multi-domain portfolios, varied ownership, frequent sender changes, additional reporting needs, or client-specific approval and escalation requirements. Domain count may be a useful starting measure, but it should not be the only boundary. The record's sender-change rate, unresolved ownership, review cadence, and exception volume show where recurring work actually sits. ### 4. Put change authority in the quote Owner: client approver and MSP service owner. Input: package scope and client authorization. Output: a responsibility record. State whether the MSP can prepare a DNS change, submit it for approval, publish it after documented approval, or only provide a recommended value. Apply the same distinction to sender-platform work. This keeps the service scope aligned with the authority the client has granted. > Do not change DNS or a sender configuration during an active mail-flow incident without documented client authority and a rollback path. A rushed change can interrupt legitimate mail. For a broader discussion of the operational tradeoff between internal work and ongoing service, see [Should you DIY DMARC or use an automated service?](/learning/should-you-diy-dmarc-or-use-an-automated-service). ### 5. Price exceptions as visible work Owner: MSP service lead. Input: exception register. Output: an included-action rule or separately approved statement of work. Exceptions are conditions outside the agreed steady-state service. They can include an unknown sender, an unavailable client owner, an unsupported platform, disputed domain ownership, missing DNS access, or an active delivery incident. For each exception, retain the evidence, owner, requested decision, business impact, and review date. Then classify it as included work, work that uses a defined allowance, or work requiring separate approval. The client can see why the work is different from routine evidence review. ### 6. Review service economics against completed work Owner: MSP operations lead. Input: closed onboarding records, completed recurring reviews, and exception history. Output: revised package assumptions. Review completed work by operational category rather than by an invented protection score. Look for assumptions that repeatedly fail, such as clients with a high sender-change rate, approvals that delay routine work, or domains without reliable sender ownership. Update future scope definitions to name those conditions. [Which MSP tools should every managed service provider have in 2025?](/learning/which-msp-tools-are-essential-2025) can help place DMARC operations within the wider tooling decisions that affect service delivery. ## Exceptions and escalation Use a simple escalation tree for every portfolio: - If the sender is known and the owner can act, assign a dated remediation action to that owner. - If the sender is known but the MSP lacks authority, request client approval or delegated access before changing the scope. - If the sender is unknown, retain the evidence and ask the client to confirm its business purpose before any enforcement recommendation. - If a business-critical production path is failing, follow the agreed incident route and pause unrelated policy changes. - If DNS ownership, sender ownership, or approval authority remains unclear, mark the item blocked and set a review date. The MSP should report the blocked condition and requested decision. The client should accept any remaining business or delivery risk before a policy change. A DNS host cannot establish whether a sender is legitimate, and a sender platform cannot approve the client's business risk. ## Reporting and success measures Use a recurring operational review and client summary that show work and decisions rather than implying that one metric proves complete protection. Include: - Domains and subdomains in scope, added, removed, or awaiting confirmation. - Current sender inventory state, including confirmed, unknown, and owner-pending sources. - Evidence reviewed during the reporting period and evidence still missing. - Remediation actions by owner, approval state, and next review date. - Exceptions opened, closed, accepted, or blocked. - DNS and policy changes with their approval and rollback references. Track service health separately from message outcomes. Useful internal measures include records missing an owner, exceptions past review date, completed reviews without a client decision, and sender changes that arrived outside the agreed intake process. These measures identify operating gaps. They do not prove that every future message will authenticate or reach a recipient inbox. ## Build a repeatable portfolio scope before quoting For recurring multi-client DMARC work, [Palisade's MSP workflow](/for-managed-service-providers) can support a discussion about organizing domain evidence, sender review, remediation work, and policy recommendations across the portfolio. Palisade is agentic DMARC software that analyzes aggregate-report data, identifies authentication or alignment issues, and proposes the next policy step for human review. [Book a demo](https://calendly.com/sam-palisade/30min) to map the service-design record to your client portfolio before standardizing a package. A product discussion does not establish client authority, repair a sender configuration, publish DNS, or guarantee how receiving mailbox providers will handle mail. ## Sources and further reading - [RFC 9989: Domain-based Message Authentication, Reporting, and Conformance](https://datatracker.ietf.org/doc/html/rfc9989) - [RFC 8601: Authentication-Results header field](https://www.rfc-editor.org/rfc/rfc8601.html) - [Palisade MSP workflow](/for-managed-service-providers) - [Palisade DMARC checker](/tools/dmarc) ## Frequently asked questions ### Should MSPs charge a one-time DMARC onboarding fee? Yes. Onboarding work is often uneven because it includes sender discovery, ownership mapping, DNS review, approval planning, and remediation planning. Price that defined work separately from the recurring review and reporting service. ### Should MSPs price DMARC management only by domain count? No. Domain count can define portfolio scope, but it does not show sender-change rate, missing ownership, approval cycles, reporting requirements, or exception work. Use a domain allowance alongside documented complexity boundaries. ### Can a public DMARC checker validate an MSP's managed service? No. A public checker can inspect a published DMARC record. It cannot prove that every production sender authenticates, that sender-platform configuration is current, or that a receiving mailbox provider will accept a specific message. ### Who should approve a DMARC policy change for a client? The client should approve the business risk unless it has explicitly delegated that authority. The MSP can prepare evidence and a recommendation, while the DNS host or authorized MSP publishes the approved record. ### Should an active delivery incident be included in recurring DMARC management? Only if the service definition explicitly includes incident response. Otherwise, record the incident as an exception with its business impact, owner, authorization requirements, and rollback condition before work begins. --- # How can you check and improve your email domain reputation? Canonical: https://www.palisade.email/learning/how-can-you-check-and-improve-your-email-domain-reputation > How to check email domain reputation: assess public signals, authentication, provider evidence, and DMARC reports before making safe delivery changes. You cannot check one universal email domain reputation score. Start with a public [domain reputation check](/tools/domain-reputation), then validate the mail path with delivered-message headers, provider evidence you can access, and DMARC aggregate reports. Improve the signals you control by fixing authentication and alignment failures, stopping unwanted mail, honoring unsubscribes, and investigating every sender that uses the domain. None of those checks exposes a mailbox provider's private reputation decision or guarantees inbox placement. ## Quick takeaways - Email domain reputation is a receiver-specific delivery decision, not a universal public score. - A public reputation check can identify listed public signals, but cannot explain a private Gmail, Outlook.com, or Yahoo filtering decision. - DNS and authentication checks show configuration hygiene, while a delivered message shows what the production path actually used. - Google asks bulk senders to keep Postmaster Tools spam rates below 0.10% and avoid reaching 0.30%. - DMARC aggregate reports help identify sending sources and authentication outcomes that public reputation checks cannot see. - Record each observation, its source, and its time before changing DNS, sending volume, or list practices. ## What this tool checks The [Palisade domain reputation checker](/tools/domain-reputation) checks a submitted domain against public reputation and blocklist data. Enter the domain in the visible From address, or the domain you need to investigate after reviewing message evidence. The result is public, point-in-time evidence. It can help identify an externally visible listing or signal that warrants investigation. It cannot inspect a mailing list, recipient consent, private provider reputation data, message content, the exact production route, or why one recipient received mail in spam. Keep three evidence types separate: - Observable DNS and authentication hygiene: published SPF, DKIM, and DMARC records, plus the authentication results on a delivered message. - Third-party public signals: a public listing or reputation result returned by a source checked during the lookup. - Private mailbox-provider decisions: inbox, spam, rejection, complaints, and reputation data held by Gmail, Outlook.com, Yahoo, or another receiver. A clean public result does not establish that the next message will inbox. A public listing does not prove every receiver uses that source. ## How to run the check ### 1. Identify the exact sending domain and path Start with the visible From domain, then collect a recent message sent through the same application, sender identity, recipient type, and routing path involved in the issue. The visible From domain may differ from the SPF envelope domain and DKIM signing domain. [RFC 8601 defines the `Authentication-Results` header field](https://www.rfc-editor.org/rfc/rfc8601.html), which records authentication results added by a receiving system. ### 2. Run the public domain lookup Submit the domain to the Palisade domain reputation checker. Record the result, the source named by the result if available, and the date and time you checked it. Preserve that evidence before requesting removal from a list operator or changing mail configuration. Some domain-based blocklists use DNS queries. This is an illustrative structure only. Use the list operator's documented query format, never another organization's domain or zone. ```bash dig +short yourdomain.com.<published-dbl-zone> ``` A DNS answer shows what the queried public source returned at that time. It does not establish the cause of a listing, the receiver's filtering logic, or future inbox placement. ### 3. Build an evidence packet before changing anything Create one record for the affected domain and sending path. This prevents unrelated mail streams from being combined into one diagnosis. - Sending domain: the visible From domain and any related envelope or DKIM domain. - Sending IPs: only IPs you lawfully administer or can see in authorized message, provider, or log evidence. - Authentication: SPF and DKIM pass or fail results from the delivered message. - DMARC alignment: whether the visible From domain aligns with a passing SPF or DKIM identifier. - Mailbox evidence: inbox, spam, bounce, complaint, or provider-dashboard evidence you are authorized to access. - Public lookup: result, source, and time of the check. - Sending-service ownership: the accountable application, ESP, business unit, or MSP customer. - Change and retest date: what changed, who approved it, and when the same path was retested. An illustrative redacted record might look like this: ```text Sending domain: yourdomain.com Sending IPs: 192.0.2.25 (redacted example) Authentication: spf=pass smtp.mailfrom=mail.yourdomain.com; dkim=pass header.d=yourdomain.com DMARC alignment: pass, DKIM aligns with From: yourdomain.com Mailbox evidence: Gmail recipient reported spam placement, 2026-08-12 Public lookup: no listed public signal returned, checked 2026-08-12 13:00 UTC Sending-service ownership: transactional-email service, owned by operations team Change and retest date: pending approval, no DNS change made ``` Do not place credentials, private keys, full message headers, customer addresses, or unredacted recipient data in the packet. ![Evidence packet fields for separating public domain signals from delivered-message and provider evidence](/images/editorial/how-can-you-check-and-improve-your-email-domain-reputation/how-can-you-check-and-improve-your-email-domain-reputation-evidence-packet.webp "1200x524") *Source: Palisade.* ### 4. Check provider evidence separately If you are eligible to use Google Postmaster Tools, review the spam rate for the authenticated domain. Google's [Email sender guidelines](https://support.google.com/a/answer/81126) tell bulk senders to keep reported spam rates below 0.10% and avoid reaching 0.30%. Microsoft and Yahoo publish their own sender expectations separately: Microsoft documents the [services external senders can use to manage reputation and delivery to Microsoft 365 recipients](https://learn.microsoft.com/en-us/defender-office-365/external-senders-microsoft-365-services), and Yahoo publishes its [Sender Best Practices](https://senders.yahooinc.com/best-practices/). A low spam rate is Gmail-specific evidence, not a universal reputation grade. It does not prove that every production source authenticates correctly or that another provider will make the same placement decision. ![Provider evidence checklist for reviewing spam rates, message authentication, and DMARC reports](/images/editorial/how-can-you-check-and-improve-your-email-domain-reputation/how-can-you-check-and-improve-your-email-domain-reputation-provider-evidence-checklist.webp "1200x524") *Source: Palisade.* ### 5. Inspect a delivered message Send a fresh message through the affected production path. Open the raw message and find `Authentication-Results`. Check SPF and DKIM independently, then determine whether a passing SPF or DKIM identifier aligns with the visible From domain for DMARC. [DMARC policy processing is defined in RFC 9989](https://www.rfc-editor.org/rfc/rfc9989.html). A valid public DMARC record does not prove that an application is using aligned identifiers in a delivered message. ### 6. Review DMARC aggregate reports After reports accumulate, review the sources that send using the domain and their SPF, DKIM, and alignment outcomes. This can reveal a forgotten marketing platform, a newly added transactional service, or unauthorized traffic that a public reputation lookup cannot identify. For the relationship between authentication and delivery, see [how DMARC protects your domain and supports email delivery](/learning/how-does-a-dmarc-record-protect-my-domain-and-improve-email-delivery). ## How to interpret the results ### No public issue is returned A clean result means the public sources checked by the tool did not return a listed signal during that run. It does not mean the domain has a positive reputation at every receiver or that the production path is authenticated. If placement problems continue, prioritize the delivered message, the provider-specific dashboard where available, and DMARC aggregate reports. Compare the evidence packet with the exact sender that produced the affected mail. ### A public listing or signal is returned A returned listing means a public source matched the submitted domain. First confirm that the queried domain is relevant. The visible From domain, redirect domain, link-tracking domain, SPF envelope domain, and DKIM signing domain can differ. Read the named list operator's current removal guidance. Investigate the source, recipient-consent evidence, complaint pattern, authentication results, and account security before requesting removal. A removal request does not repair compromised credentials, unwanted acquisition practices, or unexpected mail from an application. ### Authentication or alignment fails An SPF or DKIM failure in a delivered message is evidence about that message path. A DMARC failure can occur when neither passing SPF nor passing DKIM aligns with the visible From domain. Return to the sending service that owns the path and obtain the records it generated for your domain. Publish only those account-specific values at the required DNS owner names. Do not copy selectors, CNAME targets, or SPF values from another tenant. > Changing SPF, DKIM, or DMARC records without confirming the sender's current configuration can interrupt legitimate mail. Keep the prior record, the approved change, and a rollback path before publishing DNS. Retest with a new message from the same application and recipient path. Public DNS evidence is useful, but it does not prove that the application signs mail or uses the intended envelope sender. ### No public issue exists, but messages still reach spam This pattern points away from a public listing as the sole explanation. Review provider-specific evidence, authentication and alignment, audience permission, complaint trends, unsubscribe processing, and changes in mail volume or source ownership. Google's sender guidelines require applicable bulk senders to support one-click unsubscribe for marketing and subscribed messages, and to process unsubscribe requests within two days. Follow the [Google bulk-sender requirements](https://support.google.com/a/answer/81126) for the affected stream rather than applying a generic DNS change. ## How to act on the result ### Correct the exact authentication failure Fix the sender that failed in the delivered-message evidence. SPF authorizes the envelope sender, DKIM signs with a selected domain and key, and DMARC evaluates alignment with the visible From domain. Use a DNS lookup or authentication checker only for the public input it can inspect. A passing public record cannot confirm the production signing path, continuous state, private receiver reputation, or future placement. ### Investigate a returned public signal Identify the accountable sending service in the evidence packet. Pause or contain suspicious traffic if your incident process requires it, then correct the underlying account, list, or configuration issue before following the public source's removal process. Do not treat the listing as a universal diagnosis. Compare it with the actual affected recipient provider and message path. ### Improve sending practices where placement remains poor Confirm that recipients gave appropriate permission, unsubscribe requests are processed, and hard bounces are suppressed. Review abrupt volume changes and imported or inactive audiences before resending campaigns. Keep transactional and marketing mail operationally distinguishable when your setup supports it. This can make evidence easier to interpret, but it does not isolate a domain from every delivery issue. For Gmail-specific placement questions, see [why Gmail marks new-domain emails as spam](/email-deliverability/why-does-gmail-mark-new-domain-emails-as-spam). ## How to retest Repeat the same public domain lookup after the underlying issue is corrected, and record the new source and timestamp in the evidence packet. Then send a fresh message through the same application, sender identity, routing path, and recipient provider. Validate the four applicable layers separately: - DNS: query the authoritative record and at least one public resolver. - Vendor: check the sending service's current authentication or domain status. - Message: inspect `Authentication-Results` on a newly delivered message. - DMARC: review aggregate reports after data accumulates. A green vendor status is not proof of a delivered message. A clean public lookup is not proof of inbox placement. ## Track the sending sources behind repeated reputation issues A public lookup can reveal an external signal, but it cannot show which production sources later fail SPF, DKIM, or DMARC alignment. Palisade is DMARC software that analyzes DMARC aggregate-report data, identifies sending sources and authentication or alignment issues, and creates prioritized remediation tickets. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=email_deliverability&utm_content=how-can-you-check-and-improve-your-email-domain-reputation) Palisade can propose the next DMARC policy step after a human reviews the evidence and applies the change. It does not access a receiver's private reputation decision, delist a domain, or guarantee delivery or inbox placement. ## Sources and further reading - [Palisade domain reputation checker](/tools/domain-reputation) - [Google Email sender guidelines](https://support.google.com/a/answer/81126) - [Microsoft: Services for external senders to Microsoft 365](https://learn.microsoft.com/en-us/defender-office-365/external-senders-microsoft-365-services) - [Yahoo Sender Best Practices](https://senders.yahooinc.com/best-practices/) - [RFC 8601: Message Authentication Status](https://www.rfc-editor.org/rfc/rfc8601.html) - [RFC 9989: Domain-based Message Authentication, Reporting, and Conformance](https://www.rfc-editor.org/rfc/rfc9989.html) ## Frequently asked questions ### Can I see my email domain reputation score? No. Mailbox providers use their own private delivery and reputation systems. Public checks can identify visible blocklist or reputation signals, while provider dashboards, delivered-message evidence, and DMARC reports answer different parts of the diagnosis. ### Does a clean public reputation check mean my messages will inbox? No. It means the checked public sources did not return a listed signal at that time. It does not prove the sending application authenticates mail correctly or reveal a receiver's private placement decision. ### What should I check first when a domain has a public listing? First confirm that the listed domain belongs to the affected mail path. Then identify the responsible sending service, inspect recent authentication results, investigate the underlying cause, and follow the list operator's documented removal process only after correction. ### Can SPF, DKIM, and DMARC improve email reputation? Yes. SPF, DKIM, and DMARC support email reputation because stronger authentication helps receivers identify authorized mail and detect impersonation. It does not guarantee inbox placement, because providers also consider their own signals and recipient interactions. ### Why do emails still go to spam when authentication passes? Authentication is one layer of evidence. A message can pass SPF, DKIM, and DMARC while a provider still considers recipient complaints, engagement, list practices, volume patterns, or other private signals when deciding placement. ### How long should I keep evidence after a reputation issue? Keep the evidence packet through the investigation, change approval, and same-path retest. Retain the public lookup time, message results, provider evidence you are authorized to access, sending-service owner, and rollback information according to your organization's mail and incident records policy. --- # GoDaddy DKIM Record: How to Add and Verify It Canonical: https://www.palisade.email/learning/add-dkim-record-godaddy > Add a GoDaddy DKIM record: publish your sender's exact TXT or CNAME values, verify public DNS, enable signing, and confirm a delivered message is signed. To add a DKIM record in GoDaddy DNS, copy the exact record type, host, and value generated by the email service that sends your mail. In GoDaddy Domain Portfolio, select the domain, open **DNS**, choose **Add New Record**, enter every required TXT or CNAME record, and save. The selector, public key, and CNAME target are specific to your sender account and domain, so do not reuse values from another account or an online example. ## Quick takeaways - GoDaddy publishes DKIM DNS records, but the sending service generates the required record type and values. - A DKIM configuration can require a TXT public-key record or one or more CNAME records. - TXT and CNAME are sender-specific alternatives. Do not replace one type with the other. - A required pair of CNAME records must both be published before sender verification can succeed. - Public DNS proves that a record can be queried. It does not prove the sender enabled DKIM or signed a delivered message. - DKIM can satisfy DMARC only when the DKIM `d=` domain aligns with the visible From domain. ## What should I check before configuring GoDaddy? Confirm that GoDaddy is authoritative for the domain. GoDaddy's [DNS record management guidance](https://www.godaddy.com/en-uk/help/manage-dns-records-680?isc=gtnieu114) distinguishes domains using GoDaddy nameservers from domains whose DNS is managed elsewhere. If another provider hosts the authoritative zone, add the DKIM record there instead. Identify the sending path before editing DNS. A marketing platform, transactional sender, hosted mailbox provider, and Microsoft 365 tenant can each use different DKIM selectors and records for the same visible From domain. GoDaddy is the DNS interface, not necessarily the system that signs the mail. You need access to the sender's domain-authentication settings and permission to edit the DNS zone. Collect the sender-provided record type, Name or Host field, Value or Target field, record count, TTL guidance, and any sender-side verification or enable action. For DKIM record anatomy, see [how to check a DKIM record and interpret the result](/tools/dkim). Read [what DKIM is](/learning/what-is-dkim) first if the difference between a selector, public key, and signing domain is unclear, and DKIM for subdomains if the sending domain is a subdomain of the zone you are editing. > Copy DNS values from the account and domain you are configuring. Do not publish selectors, targets, tokens, or hostnames from another account or from an online example. ## Which setup method should I use? Use the method required by the sending service. GoDaddy's [hosting email authentication instructions](https://www.godaddy.com/en-uk/help/set-up-spf-dkim-or-dmarc-records-for-my-hosting-email-40810) document a TXT-record workflow. Its [Microsoft 365 DKIM instructions](https://www.godaddy.com/nl/help/enable-and-add-dkim-to-my-domain-for-microsoft-365-41748?lc=en-US) document two CNAME records followed by a separate sender-side enable action. Choose TXT only when the sender supplies a DKIM public-key value. Choose CNAME only when the sender supplies a target hostname. The sender determines the selector, record type, record count, and target. The GoDaddy path below was verified from official documentation. It shows selecting the domain before opening its DNS controls. ![GoDaddy Domain Portfolio showing a selected domain before opening DNS controls](/images/editorial/add-dkim-record-godaddy/godaddy-select-domain.png "300x293") _Source: [Add or edit an A record](https://www.godaddy.com/help/add-or-edit-an-a-record-42546), checked 2026-08-12._ ![GoDaddy domain settings showing the DNS tab used to manage records](/images/editorial/add-dkim-record-godaddy/godaddy-select-dns-tab.png "300x209") _Source: [Add or edit an A record](https://www.godaddy.com/help/add-or-edit-an-a-record-42546), checked 2026-08-12._ ## How do I configure SPF and DKIM for GoDaddy? SPF and DKIM are separate DNS changes. This procedure covers sender-generated DKIM records. Do not add another SPF policy or replace an existing SPF TXT value unless the sending service provides a specific SPF update and instructions for merging it with the existing policy. ### 1. Open the sender's domain-authentication settings Open the service that sends the messages and find its domain, sender, or authentication settings. Select the exact domain that appears in the visible From address, then copy the DKIM instructions generated for that account. [DKIM key records in RFC 6376](https://www.rfc-editor.org/rfc/rfc6376) use the `s=` selector and `d=` signing domain to locate a public key below `_domainkey`. GoDaddy does not generate those values. ### 2. Select the sending domain in GoDaddy Sign in to GoDaddy Domain Portfolio, select the sending domain, then open **DNS**. GoDaddy documents this Domain Portfolio DNS path in its [hosting email record setup guide](https://www.godaddy.com/en-uk/help/set-up-spf-dkim-or-dmarc-records-for-my-hosting-email-40810). Check the selected domain before adding records. The parent domain, a subdomain, and another brand domain can use different zones and sender configurations. ### 3. Publish each sender-generated DKIM record Select **Add New Record**, choose the exact type the sender supplied, enter its Name and Value fields, choose the sender-required or GoDaddy-accepted TTL, and save. GoDaddy's documented workflow uses these DNS record fields. Use these record shapes only to identify the fields. **Record type:** `TXT` or `CNAME`, exactly as required by the sender **Host (illustrative only):** ```text selector1._domainkey ``` **Value (illustrative only):** ```text TXT: v=DKIM1; k=rsa; p=<sender-generated-public-key> CNAME: selector1._domainkey.yourdomain.com.sender-example.net ``` > Do not publish these examples. Copy the complete record type, host, and value generated by the sending service for your domain. Some DNS interfaces append the zone name automatically. If GoDaddy appends `yourdomain.com`, entering `selector1._domainkey.yourdomain.com` can create a duplicated owner name. Compare the final fully qualified record name with the sender's requirement before saving. Do not overwrite an active selector to match an example. Use the sender's rotation procedure if the selector already exists. A CNAME cannot coexist with other DNS data at the same owner name. ![Illustrative DKIM record shapes showing a selector host with either a TXT public-key value or CNAME target](/images/editorial/add-dkim-record-godaddy/add-dkim-record-godaddy-records.webp "1200x466") _Source: Palisade._ ### 4. Save every required record before returning to the sender Save every record the sender requires. GoDaddy's Microsoft 365 procedure requires two generated CNAME records, then a sender-side DKIM enable action. Adding one record from a required pair does not complete that configuration. If a saved record does not appear in the DNS list, stop before retrying sender verification. Reopen the zone and compare the record type, owner name, and complete value with the sender-generated values. ### 5. Verify in the sending service and send a real test message Wait until a [public DNS lookup returns the record](/tools/dns-lookup), then return to the sending service and use its verification or enable control. GoDaddy's [Microsoft 365 DKIM process](https://www.godaddy.com/nl/help/enable-and-add-dkim-to-my-domain-for-microsoft-365-41748?lc=en-US) separates DNS publication from enabling DKIM. Send a new message through the exact production path to a mailbox where you can inspect full headers. Do not use a message sent before sender verification completed. A green sender indicator shows what the sender detected. It does not prove that the delivered message was signed. ## GoDaddy hosting email DKIM in cPanel If the domain sends through GoDaddy cPanel hosting email rather than an external platform, the record comes from cPanel itself. Open **cPanel > Email Deliverability**, find the domain, and use the suggested DKIM record shown for that account. GoDaddy documents this path in [Set up SPF, DKIM, or DMARC records for my hosting email](https://www.godaddy.com/en-uk/help/set-up-spf-dkim-or-dmarc-records-for-my-hosting-email-40810). Use the value currently shown in cPanel for that account and domain. Do not reuse a selector or public key from another hosting account, and do not paste an example key. If cPanel offers to install the record for you, that action writes into the same zone you would edit by hand, so check afterwards that only one DKIM selector exists for the owner name. ## Microsoft 365 DKIM in GoDaddy Microsoft 365 custom domains use two CNAME records, not a TXT public-key record. In the Microsoft Defender portal, open **Email authentication**, choose the custom domain on the **DKIM** tab, and copy the two exact CNAME values Microsoft provides for `selector1._domainkey` and `selector2._domainkey`. Add both records in GoDaddy before enabling signing in Microsoft 365. Do not construct the CNAME targets from an online example. Microsoft assigns values per tenant and changed its new-domain CNAME format in 2025, so the values displayed for your own domain are the only ones to publish. Microsoft documents that the second selector is used for future key rotation, which is why both records are required even though only one selector is active at a time. [Microsoft's DKIM guide](https://learn.microsoft.com/en-us/defender-office-365/email-authentication-dkim-configure) has the current path and record requirements. In GoDaddy, enter only the selector host (`selector1._domainkey` or `selector2._domainkey`) if the DNS form appends the domain automatically. After Microsoft detects both public CNAME records, return to the DKIM settings and enable signing. A public CNAME answer alone does not complete that final sender-side action. ## Google Workspace DKIM in GoDaddy Google Workspace uses a sender-generated TXT record. In the Google Admin console, generate the DKIM record for the sending domain, copy its selector and TXT value, then add that exact TXT record in GoDaddy. The selector is commonly `google._domainkey`, but treat it as an example: publish the selector your own Workspace account generates. After the TXT record resolves publicly, return to Google Workspace and start authentication. Do not reuse a TXT record from Microsoft 365, another Workspace tenant, or a blog post. Google publishes the current DKIM setup sequence in its [Admin Help documentation](https://support.google.com/a/answer/174124). This section covers the GoDaddy side of the publish; see [the full Google Workspace DKIM setup](/learning/dkim-google-workspace) for the Admin console steps and key-length options. ## How does this setup affect DMARC? Publishing a DKIM record makes the selector's public key or sender-managed key location available to receivers. It does not sign mail by itself. For DKIM to satisfy DMARC, the receiver must validate the signature and the DKIM `d=` domain must align with the visible From domain. A DKIM pass from an unrelated signing domain can leave DMARC without an aligned DKIM result. If your sender supplied targets rather than a public key, see [what a DKIM CNAME record is and how to set it up](/learning/dkim-cname). Use the [DMARC checker](/tools/dmarc) to inspect the published DMARC policy before changing enforcement. A public policy lookup cannot show every production sender, a receiver's private decision, or whether one message was accepted. ## How do I validate the setup? ### Check public DNS Query the complete selector name supplied by the sender. For a TXT setup, confirm the TXT answer. For a CNAME setup, confirm the CNAME answer and follow the destination as the sender requires. Check the authoritative DNS answer and at least one public resolver. ```bash dig +short TXT selector1._domainkey.yourdomain.com dig +short CNAME selector1._domainkey.yourdomain.com ``` Use the [DKIM checker](/tools/dkim) to inspect the public selector record after publishing it. Keep the direct query for the exact selector because public DNS checks do not access the private key or prove a message was signed. ### Check the sender's verification or enable status Return to the sender's domain-authentication page and confirm that it reports the selected domain as verified or DKIM as enabled, where the sender provides that status. For Microsoft 365 from GoDaddy, this is a separate step after the required CNAME records are detected. This confirms that the sender accepted the current public DNS configuration. It does not prove that every production route signs mail with the same selector. ### Inspect a delivered message Open the raw source of a new message sent through the path you configured. Confirm the expected `d=` domain and `s=` selector in `DKIM-Signature`, then inspect the trusted receiver-added authentication result. [RFC 8601 defines the Authentication-Results field and its trust boundary](https://www.rfc-editor.org/rfc/rfc8601.html). Accept the configuration only when the expected selector and signing domain are present, a trusted result reports `dkim=pass`, and the signing domain aligns with the visible From domain when DKIM is expected to satisfy DMARC. Save a redacted header copy with the DNS change record. ### Review DMARC reports After DMARC aggregate reports arrive, check whether traffic from this sender passes DKIM and aligns with the From domain. Keep this sender separate from other sources that use the domain. A valid selector record today does not identify a different sender that later fails alignment. ## Troubleshooting ### No DKIM selector appears in public DNS Compare the full owner name in GoDaddy with the sender's required host. A duplicated domain suffix, a missing `_domainkey` label, or an unsaved record can prevent the expected answer. Confirm the authoritative answer before changing the sender configuration again. For more diagnosis, see [how to check a DKIM record and interpret the result](/tools/dkim) and [what to do when no DKIM record is found](/learning/no-dkim-record-found). ### GoDaddy cPanel shows a different suggested record Use the value currently shown in cPanel Email Deliverability for that account and domain. Do not reuse a prior selector or public key from another hosting account. If the old selector still signs mail in transit, follow the sender's rotation guidance before removing it. ### The sender expects CNAME but GoDaddy has a TXT record Delete nothing until you compare the sender's current generated instructions with the existing record. A public-key TXT record and a CNAME delegation are different DKIM designs. Publish the type required by the active sender configuration, then remove or rotate a conflicting old record only through the sender's documented process. ### The final record name contains the domain twice GoDaddy may append the zone name when you enter a relative host. If the sender supplied `selector1._domainkey.yourdomain.com`, determine whether GoDaddy expects only `selector1._domainkey`. Compare the saved fully qualified owner name with the sender requirement, then correct the host field if it was duplicated. ### Sender verification is still pending Confirm every required record answers publicly and matches the generated type, host, and value exactly. A Microsoft 365 setup that requires two CNAME records remains incomplete when either record is absent. If DNS is correct but the sender still reports pending status, use that sender's documented verification path rather than changing a working record repeatedly. ### DKIM passes but DMARC does not Compare the DKIM `d=` domain in the delivered message with the visible From domain. A receiver can report `dkim=pass` while DMARC does not receive an aligned DKIM result. Check the sender's configured signing domain and the From-domain design before changing the DMARC policy. ## Keep sender changes visible after the DNS check Use the DKIM checker to inspect the public selector before retrying sender verification. A single selector check does not reveal later DNS drift or other sending services that still fail authentication or alignment. When recurring DMARC reports show additional sources or alignment issues, Palisade can analyze aggregate-report data, create source-specific authentication tickets, and propose recommended actions for human review. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=vendor_setup&utm_content=add-dkim-record-godaddy) if you need that ongoing evidence workflow. Records you approve can be written into your own GoDaddy zone once you authorize the connection in GoDaddy's own window, so no credentials are shared with Palisade and access stays scoped to email-authentication records. Palisade does not enable a sender or guarantee delivery. ## Sources and further reading - [GoDaddy: Manage DNS records](https://www.godaddy.com/en-uk/help/manage-dns-records-680?isc=gtnieu114) - [GoDaddy: Set up SPF, DKIM, or DMARC records for hosting email](https://www.godaddy.com/en-uk/help/set-up-spf-dkim-or-dmarc-records-for-my-hosting-email-40810) - [GoDaddy: Enable and add DKIM to my domain for Microsoft 365](https://www.godaddy.com/nl/help/enable-and-add-dkim-to-my-domain-for-microsoft-365-41748?lc=en-US) - [Microsoft: Set up DKIM for a custom domain](https://learn.microsoft.com/en-us/defender-office-365/email-authentication-dkim-configure) - [Google Workspace Admin Help: Set up DKIM](https://support.google.com/a/answer/174124) - [RFC 6376: DomainKeys Identified Mail](https://www.rfc-editor.org/rfc/rfc6376) - [RFC 8601: Authentication-Results](https://www.rfc-editor.org/rfc/rfc8601.html) - [Palisade guide to fixing authentication issues](https://docs.palisade.email/guides/fixing-authentication-issues/) ## Frequently asked questions ### Can I use the same DKIM record for every email sender? No. Each sender can generate different selectors, public keys, CNAME targets, and record counts. Publish the records generated for the sender account and domain in scope. ### Does GoDaddy create my DKIM public key? No. GoDaddy publishes the DNS record. The sending service creates the DKIM configuration and supplies the TXT public-key value or CNAME target. ### Should I add a TXT record or a CNAME record for DKIM? Only use the type supplied by the sending service. A TXT record normally contains a DKIM public key, while a CNAME record points the selector to a sender-managed location. ### Does a visible DKIM record prove that my mail is signed? No. A public DNS answer proves that the record can be queried. Check the sender's status and inspect a newly delivered message for the expected `DKIM-Signature` and trusted `dkim=pass` result. ### Can DKIM pass while DMARC fails? Yes. DKIM can pass for a signing domain that does not align with the visible From domain. DMARC needs an aligned SPF or DKIM result. ### What is DKIM status in GoDaddy? GoDaddy DNS can show that a record was saved, but DKIM signing status belongs to the mail sender that generated the record. Check the sender's authentication page for its verification state, then inspect a delivered message to confirm the receiver reports `dkim=pass`. ### Does GoDaddy support the 2048 DKIM key? Yes. GoDaddy DNS can publish a DKIM TXT record containing the public key supplied by a sender. Use the key length and complete value the sender generates. GoDaddy does not choose the key size or create the matching private key for an external mail platform. ### Can I add more than one DKIM record in GoDaddy? Yes. Different senders can use different selectors under the same domain, each with its own owner name such as `selector1._domainkey`. Do not publish conflicting TXT and CNAME data at the same selector, and do not remove a selector until you know no active sender uses it. --- # Apple two-factor authentication email Canonical: https://www.palisade.email/learning/apple-two-factor-authentication-email > Apple Account two-factor sign-in normally sends its code to a trusted device or phone number. Learn when an Apple email can be relevant. An Apple two-factor authentication email is not the normal place to expect a sign-in code. For a new device or browser, Apple says Apple Account two-factor authentication uses your password plus a six-digit code shown on a trusted device or sent to a trusted phone number. Email can instead relate to verifying an email address or, in qualified recovery or password-reset cases, a code sent to the primary email address. Do not share an unexpected code or use the message's link. ## Quick takeaways - Apple documents trusted devices and trusted phone numbers as the ordinary ways to receive a six-digit sign-in code. - An email-address verification message is a different task from entering a code for a new-device sign-in. - In some qualified recovery or password-reset cases, Apple may send a six-digit code to the primary email address. - An unexpected code does not by itself prove that someone accessed your account, but it is a reason not to approve a prompt or disclose the code. ## How Apple Account two-factor sign-in works Apple describes two-factor authentication as an added layer for Apple Account access. When you sign in for the first time on a new device or on the web, Apple says you need the account password and a six-digit verification code. Its [two-factor authentication overview](https://support.apple.com/en-us/102660) and [verification-code guidance](https://support.apple.com/en-ie/102606) identify the normal code routes: a trusted device displays the code, or a trusted phone number receives it by text message or phone call. That distinction matters when an email arrives. A message about a code is not, by itself, proof that the code was delivered through the routine sign-in flow. Apple also notes that a trusted phone number can sometimes be verified in the background, so not every valid sign-in produces a code-entry step. ## When an Apple email is relevant An email can still be relevant, but it can mean something different. Apple says it sends a [verification email for a new or updated Apple Account email address](https://support.apple.com/en-us/102529). It also says that, in some qualified recovery or password-reset cases, a six-digit code can go to the primary email address. Those are separate contexts, so an email code should not be assumed to be the routine second factor for a new-device sign-in. ![Apple Account code routes and email-related contexts.](/images/editorial/apple-two-factor-authentication-email/apple-two-factor-authentication-email-decision.svg "1200x535") *Source: Original Palisade decision card summarizing [Apple's verification-code guidance](https://support.apple.com/en-ie/102606) and [Apple Account email-address guidance](https://support.apple.com/en-us/102529). It is not an Apple interface or a way to judge whether an individual message is genuine.* ## What to do with an unexpected prompt Use the code only when you started the Apple Account sign-in yourself and the prompt on your trusted device matches that activity. As a precaution, do not give a code to another person and do not use a link in an unexpected email to investigate the account. Open an Apple route you already know independently, or use a trusted device or phone number already on the account. ### 1. Stop before approving or sharing a code If you did not start the sign-in, do not tap Allow on a prompt and do not relay the six-digit code. This prevents an unsolicited contact from turning a code request into a completed sign-in. ### 2. Check through an independently opened Apple route Use a trusted device or type `account.apple.com` yourself rather than following the message's link. Apple directs people who lack both trusted-device and trusted-phone access to the account-recovery path, which is separate from the ordinary code flow in its [verification-code instructions](https://support.apple.com/en-ie/102606). ### 3. Treat recovery as a separate case If you no longer have access to trusted devices or trusted phone numbers, follow Apple's recovery process from an independently opened Apple page. Apple says recovery can take days or longer, so a surprise email does not create a safe shortcut around that process. ```text New device or browser sign-in Normal code route: trusted device or trusted phone number Email-related route: address verification or qualified recovery or reset Unexpected prompt: do not approve, share a code, or use the message link ``` ## Keep sender authentication separate from account sign-in Apple Account two-factor authentication protects access to an Apple Account. It is different from sender authentication, where SPF, DKIM, and DMARC help a receiving server evaluate whether a domain is authorized to send a message. Our guide to [email authentication and why it matters](/learning/what-is-email-authentication-and-why-does-it-matter) explains that sender-side distinction. It cannot establish that a specific Apple email is genuine or reveal activity inside an Apple Account. For Apple's masked forwarding-address feature, use the separate guide to [Private Relay Apple ID email addresses](/learning/private-relay-apple-id). If the message itself looks deceptive, use the [Apple phishing email guide](/learning/apple-phishing-email) for current Apple-specific verification and reporting, or see the broader signs in [what is phishing](/learning/what-is-phishing). If you have independent evidence of account compromise, the broader account-hijacking prevention guide covers the next protective steps. Those pages address the wider incident, while this page only explains the Apple Account code and email boundary. ## Sources and further reading - [Apple Support: Get sent a verification code and sign in with two-factor authentication](https://support.apple.com/en-ie/102606) - [Apple Support: Two-factor authentication for Apple Account](https://support.apple.com/en-us/102660) - [Apple Support: About your Apple Account email addresses](https://support.apple.com/en-us/102529) ## Frequently asked questions ### Can an Apple verification code be sent to an email? Yes, but that is not the ordinary code-delivery route for a new-device Apple Account sign-in. Apple documents trusted devices and trusted phone numbers for that flow, while it describes email-address verification and some recovery or password-reset cases separately. ### Why did I get an Apple verification code that I did not request? An unexpected code does not establish from the message alone why it was sent. Do not approve a prompt, share the code, or use a link in the message. Check only through an independently opened Apple route. ### Is an Apple email-address verification the same as two-factor authentication? No. Email-address verification confirms control of a new or updated email address. Apple Account two-factor authentication normally adds a six-digit code to a password when signing in on a new device or browser. ### Can I use an email to recover an Apple Account? Only in qualified cases described by Apple. Apple says some accounts using two-factor authentication may verify a code sent to the primary email address to shorten recovery or reset a password. That does not make email the normal second-factor destination. ### Does sender authentication prove an Apple email is safe? No. Sender authentication can help a receiving server evaluate domain authorization, but it does not prove that an individual email is genuine or show whether an Apple Account sign-in attempt was authorized. Keep message-authentication evidence separate from account activity. --- # Best email deliverability service: choose the right category first Canonical: https://www.palisade.email/learning/best-email-deliverability-service > Best email deliverability service options depend on the problem: compare DMARC, inbox placement, list validation, consulting, and ESP categories. The best email deliverability service depends on the failure you can observe. Choose DMARC operations software when sender authentication or DMARC policy is the issue, inbox-placement monitoring when authenticated messages still filter, list validation when address quality is damaging campaigns, and consulting when several problems lack an owner. A sending platform is a separate decision. No category can replace the evidence collected by another. ## Quick takeaways - DMARC, SPF, and DKIM failures point to domain-side authentication and DMARC operations. - Inbox-placement monitoring measures representative delivery outcomes. It cannot require Gmail or Outlook to place a message in the inbox. - List-validation services assess address quality and risk signals. They do not repair sender authentication. - Deliverability consulting fits cross-functional recovery work where the team needs an accountable operating plan. - Published vendor prices and plan limits can change, so confirm the live vendor page before purchasing. - A public DNS check is a point-in-time result. It does not prove a production message path or future inbox placement. ## Who this comparison is for This comparison is for IT teams, marketing operations teams, deliverability owners, and MSPs who need to buy help for a real sending problem but have been asked for an "email deliverability service" without a defined category. Start with the symptom. A domain that has unknown senders, failed SPF or DKIM alignment, or an unfinished DMARC policy rollout needs a different service from a campaign with high invalid-address rates. A sender whose authentication passes but whose test messages reach spam needs different evidence again. This is not an ESP migration guide or a warmup-service ranking. If you are comparing recurring DMARC operating platforms after selecting the authentication category, see Palisade's [DMARC platform comparisons](/compare). For a broader view of email-deliverability concepts, visit [email deliverability](/email-deliverability). ## How the options were evaluated The categories below are an editorial framework. They separate products by the operational question they answer: - Evidence input: domain and DNS records, DMARC reports, seed-list results, addresses, or a wider operational audit. - Evidence output: authentication status, placement measurements, list-risk findings, or a remediation plan. - Time model: a one-time diagnostic, recurring monitoring, or a managed engagement. - Operator fit: whether an internal team or MSP can act on the findings. - Boundary: the specific question the service cannot answer. For senders that send more than 5,000 messages per day to personal Gmail accounts, [Google's bulk-sender guidelines](https://support.google.com/a/answer/81126) require SPF and DKIM authentication, a DMARC record, alignment with SPF or DKIM, and a Postmaster Tools spam rate below 0.30%. These requirements make authentication a necessary area to investigate. They do not guarantee inbox placement at Gmail or any other receiver. A documented capability is treated as available. If a vendor page does not document an exact limit, feature, or price, it remains an open question rather than evidence of absence. ![Framework comparing email deliverability service categories by evidence input, output, time model, operator fit, and boundary.](/images/editorial/best-email-deliverability-service/best-email-deliverability-service-service-category-framework.webp "1200x533") *Source: Palisade.* ## Email authentication and DMARC operations software This category fits a domain-side problem: unknown senders, authentication failures, alignment failures, incomplete DNS configuration, or a staged move toward DMARC enforcement. It does not measure where a representative marketing message lands at a named mailbox provider. EasyDMARC, dmarcian, Valimail, Red Sift OnDMARC, and Palisade all belong in this category, but their pricing, operating models, and portfolio fit require a direct comparison after you confirm that authentication is the actual problem. ### EasyDMARC - Best fit: Teams that want to review EasyDMARC's published DMARC platform tiers, domain allowances, and data-history allowances. - Relevant evidence: [EasyDMARC pricing](https://www.easydmarc.com/pricing) publishes Free, Plus, Premium, and Enterprise plan options. Check the live page for current regional pricing, limits, and included capabilities. - Tradeoff: A DMARC platform does not establish inbox placement or clean a mailing list. ### dmarcian - Best fit: Buyers who want a DMARC service with publicly described plan levels based on domains and DMARC-capable message volume. - Relevant evidence: [dmarcian pricing](https://dmarcian.com/pricing/) publishes Personal, Basic, Plus, and Enterprise options and describes plan limits on its pricing page. - Tradeoff: The correct plan depends on current domain and message-volume needs. Confirm service-provider requirements directly with dmarcian. ### Valimail - Best fit: Organizations evaluating a free monitoring entry point and an enforcement-focused DMARC offering. - Relevant evidence: [Valimail pricing](https://www.valimail.com/pricing/) publishes Free Monitor and describes paid enforcement offerings, with some plans requiring a quote. - Tradeoff: A published starting price or quote-based plan does not answer an inbox-placement or list-quality question. ### Red Sift OnDMARC - Best fit: Buyers assessing a security-oriented DMARC product for SPF, DKIM, and DMARC configuration across legitimate sending sources. - Relevant evidence: [Red Sift pricing](https://redsift.com/pricing) publishes an OnDMARC offer and directs buyers to contact Red Sift for higher-tier scope. - Tradeoff: Confirm the applicable commercial scope for a larger domain portfolio before treating an entry offer as a complete cost model. ### Palisade - Best fit: IT teams and MSPs that want an agent to investigate sending sources, draft authentication fixes, and propose policy steps for review. - Relevant evidence: [Palisade's Domain Overview documentation](https://docs.palisade.email/page-breakdowns/domain-overview/) describes DMARC report analysis, known-sender and sending-source views, and tickets for authentication, alignment, DNS, and enforcement milestones. [Palisade pricing](https://www.palisade.email/palisade-pricing) publishes current plan information. - Tradeoff: Palisade does not provide seed-list inbox-placement measurement at Gmail or Outlook, address validation or list cleaning, IP warmup, ESP migration, campaign consulting, or sending infrastructure. It is agentic DMARC software for the domain-side authentication workflow, and each proposed change requires approval. For a closer look at the operating-model decision, read [how to choose an email authentication service](/learning/email-authentication-service). ## Inbox-placement and reputation monitoring Choose this category when DMARC, SPF, and DKIM are in place, but the question is where representative messages land or whether reputation signals require investigation. ### Validity Engage and GlockApps - Best fit: Deliverability teams that need inbox-placement testing or reputation-oriented evidence alongside campaign investigation. - Relevant evidence: [Validity's product portfolio](https://www.validity.com/products/) describes Validity Engage deliverability capabilities. [GlockApps](https://glockapps.com/) describes Inbox Insight for spam testing and inbox placement, plus DMARC and uptime-monitoring products. - Tradeoff: These services measure signals and test outcomes. They cannot control a receiver's private filtering decision or require inbox placement. A clean result from a reputation dashboard is limited to the data and test performed at that time. It is not proof that every receiver will accept or place future messages. ## List validation and hygiene Choose this category when bounces, risky addresses, disposable mailboxes, spam traps, or questionable list acquisition are the primary concern. ### ZeroBounce - Best fit: Teams that need to assess email-address quality before sending or before importing a list into a campaign workflow. - Relevant evidence: [ZeroBounce Email Validation](https://www.zerobounce.net/services/email-validation/) describes checks for bounce, abuse, spam-trap, disposable, catch-all, toxic-domain, and MX-related signals. - Tradeoff: Address validation does not authenticate a domain, repair a broken DMARC record, or restore inbox placement after a reputation problem. > Do not remove addresses solely because one signal appears risky without considering consent records, customer lifecycle data, and the provider's documented result type. ## Managed deliverability consulting Choose consulting when the incident crosses authentication, infrastructure, campaign practices, list quality, and internal ownership. The service is the operating work, not a replacement for technical evidence. ### InboxArmy - Best fit: Organizations that need a scoped assessment, remediation plan, implementation support, and ongoing operational guidance. - Relevant evidence: [InboxArmy's deliverability consulting service](https://www.inboxarmy.com/email-deliverability-consulting/) describes audits, prioritized plans, implementation, monitoring, and ISP remediation support. - Tradeoff: Consulting outcomes still depend on the sender's practices, receiving providers, and the evidence available from production mail flows. ## Sending infrastructure with deliverability analytics An ESP or transactional-email API is the right category when the unresolved decision is how messages are sent, authenticated, routed, and observed from the sending platform itself. It is not interchangeable with DMARC operations software or a list-validation product. ### Mailtrap - Best fit: Teams evaluating sending infrastructure with deliverability-related analytics as part of their email-delivery stack. - Relevant evidence: [Mailtrap's product site](https://mailtrap.io/) describes email delivery and testing products for teams that send application or transactional email. - Tradeoff: A sending platform does not remove the need to validate domain authentication, list quality, or receiver-specific placement evidence. ## How to choose Use the narrowest category that matches the evidence you already have. - Authentication failure or unknown sender: evaluate DMARC operations software. - Authentication passes, but campaigns filter: evaluate inbox-placement and reputation monitoring. - High bounces or questionable addresses: evaluate list validation. - Several failures with no accountable owner: scope a consulting engagement. - Need to send application or transactional email: evaluate sending infrastructure separately. ![Decision map linking an observable email symptom to the appropriate deliverability-service category.](/images/editorial/best-email-deliverability-service/best-email-deliverability-service-category-map.webp "1200x980") *Source: Palisade.* Before paying for a DMARC platform, inspect the public DMARC record for the actual sending domain with the [DMARC checker](/tools/dmarc). Compare the result with a delivered production message's authentication results and, once reports accumulate, DMARC aggregate-report evidence. A public lookup can show the currently resolvable record. It cannot prove which production sources send mail, whether a message was signed, a receiver's private filtering decision, or future placement. ```yaml option: DMARC operations software checked_on: 2026-08-12 best_fit: Unknown sending sources, authentication failures, or DMARC policy rollout verified_evidence: - Published DMARC, SPF, and DKIM DNS records - Authentication results from a delivered production message - DMARC aggregate-report findings open_question: Which sending sources still fail alignment in production? ``` ```yaml option: Inbox-placement monitoring checked_on: 2026-08-12 best_fit: Authentication passes but representative campaigns filter verified_evidence: - Seed-list placement result for the exact message tested - Relevant reputation or blocklist signal open_question: Does the receiver's private filtering decision generalize to future sends? ``` ```yaml option: List validation checked_on: 2026-08-12 best_fit: High bounces or address-quality risk verified_evidence: - Validation result for the current list - Sending and consent records held by the organization open_question: Which addresses should be suppressed under the organization's policy? ``` ```yaml option: Deliverability consulting checked_on: 2026-08-12 best_fit: Multi-factor issue without a clear operational owner verified_evidence: - Scope of the audit and implementation work - Access to the affected sending-path evidence open_question: Which work remains with the sender after the engagement? ``` ```yaml option: Sending infrastructure checked_on: 2026-08-12 best_fit: Application or transactional sending-platform selection verified_evidence: - Sending-path requirements - Authentication configuration and delivered-message results open_question: Which deliverability controls remain outside the platform? ``` ## Check the DMARC evidence behind a domain-side problem Run the sending domain through the [DMARC checker](/tools/dmarc) before comparing recurring DMARC services. It shows the published record you need to inspect and gives you a starting point for a production-path investigation. If DMARC reports show recurring unknown sources, failed alignment, or policy milestones across domains, [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=existing_content_migration&utm_content=best-email-deliverability-service). Palisade's agent investigates sending sources, drafts authentication fixes, and proposes policy steps. You approve before anything ships. When a DNS change is approved, [Smart DNS Deployment](/features/dns-deployment) writes the record into your own zone at your own provider. The checker and Palisade's DMARC workflow do not prove inbox placement, clean a mailing list, act as an ESP, or control a mailbox provider's private filtering decision. ## Sources and further reading - [Google bulk-sender guidelines](https://support.google.com/a/answer/81126) - [Palisade Domain Overview documentation](https://docs.palisade.email/page-breakdowns/domain-overview/) - [EasyDMARC pricing](https://www.easydmarc.com/pricing), [dmarcian pricing](https://dmarcian.com/pricing/), [Valimail pricing](https://www.valimail.com/pricing/), and [Red Sift pricing](https://redsift.com/pricing) - [Validity products](https://www.validity.com/products/) and [GlockApps](https://glockapps.com/) - [ZeroBounce Email Validation](https://www.zerobounce.net/services/email-validation/) - [InboxArmy deliverability consulting](https://www.inboxarmy.com/email-deliverability-consulting/) ## Frequently asked questions ### What is the best email deliverability service? The best service is the one that matches the observable problem. Use DMARC operations software for domain authentication and policy work, placement monitoring for filtering evidence, validation for address-quality risk, and consulting for multi-factor recovery work. ### Can a DMARC service improve email deliverability? Yes, stronger SPF, DKIM, and DMARC authentication can support deliverability by helping receivers verify sender identity. A DMARC service does not guarantee inbox placement because each receiver makes its own filtering decision. ### Do inbox-placement tools guarantee Gmail inbox placement? No. Inbox-placement tools report the outcome of their test messages at the time of the test. Gmail's inbox decision can differ by recipient, message, sending history, and other private receiver signals. ### Is email validation enough to fix high bounce rates? Only if invalid or risky addresses are the leading cause. Validation can identify address-quality signals, but it does not repair broken authentication, poor sending practices, or a receiver's reputation decision. ### When should an MSP choose a DMARC platform? An MSP should choose a DMARC platform when it needs recurring visibility into client domains, sending sources, authentication failures, and enforcement readiness. The MSP still needs human review before DNS or DMARC policy changes. --- # Cisco advanced phishing protection Canonical: https://www.palisade.email/learning/cisco-advanced-phishing-protection > Understand Cisco Advanced Phishing Protection, its gateway sensor flow, current support limits, and the tenant evidence needed to verify coverage. Cisco Advanced Phishing Protection is Cisco's cloud service for business-email-compromise and phishing detection based on identity-deception signals. In Cisco's documented gateway integration, a registered email gateway acts as a sensor and forwards message metadata for cloud analysis. Whether it protects a particular recipient depends on the release, license, active service, sensor mode, configured policy, recipient scope, and message evidence. It is not a generic guarantee that every phishing message is blocked. ## Quick takeaways - Cisco documents the service as a BEC and phishing-detection capability focused on identity-deception threats. - A Cisco email gateway can operate as a sensor that forwards message metadata to the cloud service for analysis. - The documented workflow requires licensing, account activation, sensor registration, and policy configuration. - Cisco's AsyncOS 14.3 Cloud Gateway documentation says the renamed feature is not supported from that release onward, except for active users with a valid license. - A tenant must verify its own service status, forwarding, enforcement configuration, and message evidence before relying on the protection. ## How Cisco Advanced Phishing Protection works Cisco's [AsyncOS 16.0 integration guide](https://www.cisco.com/c/en/us/td/docs/security/esa/esa16-0/user_guide/b_ESA_Admin_Guide_16-0/m_advanced_phishing_protection.pdf) describes Cisco Advanced Phishing Protection as providing BEC and phishing-detection capabilities. It says the cloud service uses the email gateway as a sensor engine, receiving a copy of inbound message metadata, including headers, for analysis. That makes this a specific layer in an email-security design, not the same task as a general [secure email gateway explanation](/learning/email-security-gateway) or a definition of [phishing](/learning/what-is-phishing). Cisco's documentation describes an integration path that begins with service access and a registered sensor, then makes metadata available for analysis. It does not make the product name alone evidence that a tenant is protected. Cisco also documents policy-dependent enforcement. Its integration guide says that preconfigured cloud-service policies, when configured with an Enforcement sensor, can block or redirect a message for investigation. Treat that as documentation of a configured path, not as proof of how a specific message was handled in a particular tenant. ## When the answer changes Product naming and support status matter here. Cisco's [AsyncOS 14.3 Cloud Gateway documentation](https://docs.ces.cisco.com/docs/asyncos-143) calls the feature Cisco Secure Email Phishing Defense, formerly Cisco Advanced Phishing Protection. It says the feature is no longer supported from Secure Email Cloud Gateway 14.3 onward, while noting that the statement does not apply to existing users with a valid license who are actively using it. So do not infer coverage from an old design diagram, a feature list, or the presence of a Cisco gateway. Verify the exact release and service status with Cisco for the deployment in question. Sender-domain controls are a separate layer: [DMARC](/learning/what-is-dmarc) helps receivers evaluate mail that claims to use a domain, but it does not prove that this Cisco service is enabled, licensed, or enforcing a tenant policy. ## A tenant-evidence map for the Cisco service Cisco documents a flow from gateway metadata to cloud analysis and then to configured enforcement. The final step below is an operational inference: service architecture cannot by itself establish what happened to one message. ![Evidence map separating Cisco gateway metadata, cloud analysis, configured enforcement, and tenant-specific message evidence.](/images/editorial/cisco-advanced-phishing-protection/cisco-advanced-phishing-protection-evidence-map.svg "1200x662") *Source: Original Palisade evidence map based on Cisco's [AsyncOS 16.0 integration guide](https://www.cisco.com/c/en/us/td/docs/security/esa/esa16-0/user_guide/b_ESA_Admin_Guide_16-0/m_advanced_phishing_protection.pdf). It organizes documented stages and does not depict a Cisco interface or prove a message outcome.* Use this short record during an authorized tenant review: ```text Release and license: confirmed for this deployment Service and sensor: active, registered, and connected Forwarding and policy: reviewed for the intended recipient scope Message evidence: permitted tracking, investigation, or controlled-test record reviewed Conclusion: state only what the evidence supports ``` ## What to verify before relying on the protection ### 1. Confirm the release, license, and active service Start with the gateway release and the service's current entitlement. Cisco's 16.0 guide lists a license and account activation among its prerequisites. The 14.3 Cloud Gateway support statement adds an important qualification for that release line. A product label in an inventory is not enough to establish current support. ### 2. Confirm the gateway is an active sensor Cisco's guide describes registering the email gateway as a sensor and enabling the service on that gateway. In a tenant review, establish that the intended gateway and the relevant mail path are actually connected. Do not infer sensor coverage for every route, cluster, or recipient merely because one gateway was once registered. ### 3. Confirm metadata forwarding and the enforcement policy The integration guide describes forwarding inbound message metadata and says configured policies can block or redirect messages when an Enforcement sensor is used. Review the scope and behavior that are actually configured for the mail flow under investigation. This is the point where a design can differ materially from a tenant's active controls. ### 4. Review permitted message evidence Cisco documents monitoring forwarded metadata and reporting successful or unsuccessful forwarding. Use authorized tracking, investigation records, or a controlled test appropriate to the organization. Do not declare a message safe, malicious, blocked, or remediated without evidence for that message and recipient path. ## Compare the documented gap before adding or changing a layer If you need to decide whether this Cisco layer fits your environment, compare its deployment and operating evidence with the native and dedicated options you are actually considering. [Compare anti-phishing software and deployment models](/learning/anti-phishing-software) A comparison framework cannot inspect a Cisco tenant or prove how a specific message was handled. ## Sources and further reading - [Cisco AsyncOS 16.0: Integrating the Email Gateway with Cisco Advanced Phishing Protection](https://www.cisco.com/c/en/us/td/docs/security/esa/esa16-0/user_guide/b_ESA_Admin_Guide_16-0/m_advanced_phishing_protection.pdf) - [Cisco Secure Email Cloud Gateway: AsyncOS 14.3](https://docs.ces.cisco.com/docs/asyncos-143) ## Frequently asked questions ### Is Cisco Advanced Phishing Protection the same as a secure email gateway? No. Cisco documents it as a cloud service that can use an email gateway as a sensor for message metadata. A secure email gateway is a broader mail-flow layer, and a gateway's presence does not by itself prove that the Cisco service is licensed, connected, configured, or active for a given recipient path. ### Does Cisco Advanced Phishing Protection block every phishing message? No. Cisco documents policy-dependent blocking or redirection when an Enforcement sensor is configured. That does not establish coverage for every tenant, recipient, route, or message. Confirm the active service, sensor, policy scope, and permitted message evidence before making a message-specific conclusion. ### Is Cisco Advanced Phishing Protection supported on AsyncOS 14.3 Cloud Gateway? Only with an important qualification. Cisco says the renamed Cisco Secure Email Phishing Defense feature is no longer supported from Secure Email Cloud Gateway 14.3 onward, but says that statement does not apply to existing users with a valid license who are actively using the feature. Verify the deployment with Cisco. ### Does DMARC verify Cisco Advanced Phishing Protection? No. DMARC provides sender-domain authentication and receiver policy information. It does not expose a Cisco tenant's license, sensor registration, metadata forwarding, enforcement policy, recipient scope, or the handling of an individual inbound message. ### What evidence should an administrator collect first? Collect the exact gateway release, license and service status, sensor registration and connection evidence, metadata-forwarding and enforcement-policy scope, and a permitted tracking or controlled-test record. Keep the final conclusion limited to what those tenant-specific records actually show. --- # Dig DKIM record Canonical: https://www.palisade.email/learning/dig-dkim-record > Use dig to query a DKIM record by selector, interpret TXT or CNAME results, and know when DNS evidence is not a message pass. To dig a DKIM record, query the selector and signing domain from `DKIM-Signature`: `dig +short TXT <selector>._domainkey.<domain>`. For example, `s=mail2026` and `d=example.com` become `mail2026._domainkey.example.com`. A non-empty `p=` value shows public key material at that name. An empty `p=` revokes the key and cannot verify a signature. Neither result proves that a receiving mailbox passed a specific message. [RFC 6376](https://www.rfc-editor.org/rfc/rfc6376.html) defines the selector-based lookup. ## Quick takeaways - Start with the `s=` selector and `d=` signing domain, not the visible From address. - Query the selector-scoped name for a TXT answer. - Treat a non-empty `p=` value as DNS-publication evidence only; an empty `p=` revokes the key. - If the selector is a CNAME, verify the target before judging the key path. - Use receiver-added `Authentication-Results` to check whether a delivered message passed DKIM. ## Build the DKIM DNS name A DKIM signature identifies a signing domain with `d=` and a selector with `s=`. A verifier combines them as `<selector>._domainkey.<signing-domain>` when retrieving the public key. That selector lets one domain publish separate keys for different senders or key rotations. [RFC 6376 section 3.1](https://www.rfc-editor.org/rfc/rfc6376.html#section-3.1) describes selectors, while [DNSimple's DKIM record guide](https://support.dnsimple.com/articles/dkim-record/) shows the same selector-scoped DNS pattern. Use an actual delivered message when possible. Copy the values from its `DKIM-Signature` field instead of guessing a selector from a provider name or querying the root domain. This is an illustrative header, not a record to publish: ```text DKIM-Signature: v=1; d=example.com; s=mail2026; ... ``` Those values produce this lookup name: ```text mail2026._domainkey.example.com ``` ## Run the dig command Run the TXT query against the full selector-scoped name: ```bash dig +short TXT mail2026._domainkey.example.com ``` Replace both example values with the `s=` and `d=` values for the message or the exact provider-generated selector. Cisco's [DNS lookup guide for DKIM](https://www.cisco.com/c/en/us/support/docs/security/secure-email-gateway/217073-how-to-use-dig-nslookup-to-find-spf-dki.pdf) documents the same `dig` approach for DKIM-related DNS records. If that command does not show a TXT public key, ask DNS specifically whether the selector is delegated: ```bash dig +short CNAME mail2026._domainkey.example.com ``` Then query the returned target for TXT. Do not replace the target with a guessed provider hostname. A [CNAME record](https://www.rfc-editor.org/rfc/rfc1034.html) can be a valid delegation path, but the target must still return usable DKIM key material for the lookup to reach a public key. ## Read the result A TXT result with a non-empty `p=` value contains public key material for the exact name you queried. It supports the limited conclusion that the selector's public DNS path is published. An empty `p=` means the key is revoked and cannot verify a signature. Neither result reveals a private key, proves that a sender is currently signing, or establishes the result at a receiving mailbox. [RFC 6376 section 3.6.1](https://www.rfc-editor.org/rfc/rfc6376.html#section-3.6.1) defines the DKIM key record and its `p=` tag. A CNAME result means the selector name delegates elsewhere. Follow that target and inspect its TXT result. A no-answer or `NXDOMAIN` result means the queried name did not provide a usable answer. It can reflect a wrong selector, wrong signing domain, unpublished record, or resolver view. It is not evidence that the entire domain has no DKIM configuration. ![Decision flow for interpreting a selector-scoped DKIM dig lookup, including TXT key, CNAME, no-answer, and message-pass boundaries.](/images/editorial/dig-dkim-record/dkim-dig-decision.png "1600x900") *Source: Original deterministic diagram based on [RFC 6376](https://www.rfc-editor.org/rfc/rfc6376.html).* ## What to do after the DNS lookup When the TXT record is present, send a fresh message through the same production path and inspect the receiver's `Authentication-Results`. A `dkim=pass` result there is message-level evidence, whereas the DNS query only checked the public lookup path. [RFC 8601](https://www.rfc-editor.org/rfc/rfc8601.html) specifies the `Authentication-Results` field and its trust boundary. When the selector does not resolve, compare the exact `s=` and `d=` values with the sender's generated settings and the authoritative DNS zone. Do not create a new key just to make a lookup return something: a working DKIM signer also needs the matching private key. For a focused missing-record workflow, see [why a DKIM checker says no record found](/learning/no-dkim-record-found). If the record resolves but a message still fails, move to message evidence rather than changing DNS blindly. The [DKIM record-check workflow](/tools/dkim) explains that distinction, and the [DKIM alignment guide](/learning/why-does-my-dkim-signature-fail-alignment) covers the separate case where DKIM can pass but DMARC does not align. For the protocol background, read [what DKIM is](/learning/what-is-dkim). ## Check the selector without the terminal If you have the selector and signing domain but need a browser-based public-DNS check, use Palisade's [DKIM checker](/tools/dkim) after the command result. Its [public tool page](https://www.palisade.email/tools/dkim) describes a public DKIM lookup. It cannot validate an unseen message, access a private key, change DNS, or control a receiver's DKIM verdict. ## Sources and further reading - [RFC 6376: DomainKeys Identified Mail](https://www.rfc-editor.org/rfc/rfc6376.html) - [RFC 8601: Authentication-Results](https://www.rfc-editor.org/rfc/rfc8601.html) - [RFC 1034: Domain names and concepts](https://www.rfc-editor.org/rfc/rfc1034.html) - [Cisco: Use dig or nslookup to find SPF, DKIM, and DMARC records](https://www.cisco.com/c/en/us/support/docs/security/secure-email-gateway/217073-how-to-use-dig-nslookup-to-find-spf-dki.pdf) - [DNSimple: What is a DKIM record?](https://support.dnsimple.com/articles/dkim-record/) ## Frequently asked questions ### Where do I find the DKIM selector? Find it in the `s=` tag of a delivered message's `DKIM-Signature` header or in the sending provider's generated DKIM settings. A DNS lookup cannot reliably enumerate every selector a domain might use. ### Why does dig show a CNAME instead of a DKIM key? A CNAME can delegate the selector to another DNS name, often operated by the sending service. Query the returned target for TXT and confirm that its answer contains usable DKIM key material before treating the lookup path as complete. ### Does a public DKIM record mean DKIM passes? No. A public record establishes that a key is published at the queried DNS name. A pass also depends on a message being signed with the matching private key and surviving verification by the receiver. ### What does an empty p= value mean? An empty `p=` value means the DKIM key is revoked. It is not usable public key material, so a verifier cannot use it to verify a signature. Check the sender's current selector and its published key before replacing DNS records. ### What does no answer mean for a DKIM dig lookup? It means the exact selector-scoped name did not return usable key material to that query. Recheck the selector, signing domain, authoritative DNS zone, and any CNAME delegation before concluding that DKIM is absent. --- # What is a DKIM CNAME record and how do you set it up? Canonical: https://www.palisade.email/learning/dkim-cname > DKIM CNAME records delegate a DKIM public-key lookup to a provider. Learn how they work, how to publish them, and how to validate DKIM safely. A DKIM CNAME record is a DNS alias at `selector._domainkey.yourdomain.com` that directs receivers to a DKIM public key hosted by your email provider. It affects organizations that send through a provider offering delegated DKIM. You publish the provider's CNAME values in your domain's DNS, then confirm both the provider and a real delivered message recognize the configured key. ## Quick takeaways - A DKIM verifier looks up a public key using the selector in the message's DKIM signature. - A DKIM CNAME record aliases that selector hostname to a provider-controlled hostname. - The provider gives you the exact CNAME names and targets. Do not invent or reuse values from another account. - A CNAME node should not contain other DNS data, so an existing DKIM TXT record at the same hostname must be assessed before migration. - Provider verification confirms DNS visibility, but a delivered message is required to confirm the production path signs with the expected domain and selector. - Learn the surrounding protocol in the [email authentication learning hub](/learning). ## Who is affected? A DKIM CNAME setup applies when the system that sends mail for your domain gives you CNAME records for DKIM domain authentication. This is common when a sending platform hosts the DKIM public key and expects your domain to delegate the selector hostname to it. DKIM itself defines a signing domain in the `d=` tag and a selector in the `s=` tag. A verifier combines those values to find the public key at a DNS name shaped like `selector._domainkey.example.com`, as described in [RFC 6376](https://www.rfc-editor.org/rfc/rfc6376.html). The key record can be reached after following a CNAME. The receiver still evaluates the resulting DKIM key and signature under DKIM rules. This setup does not apply when a provider instructs you to publish a DKIM TXT record directly. In that case, publish the TXT record at the hostname the provider specifies. Do not replace a provider-required TXT record with a CNAME because another service uses delegation. A domain can use several selectors at once. Different sending services may each use their own selector names, and a provider may issue more than one selector during a key rotation. Treat each selector as part of a specific sending path. ## What are the requirements? ### The DKIM signature identifies the lookup name RFC 6376 defines `d=` as the signing domain and `s=` as the selector. The verifier constructs the key query from those values. In ordinary use, that query is the selector followed by `._domainkey.` and the signing domain. ```text DKIM-Signature: v=1; d=yourdomain.com; s=selector1; ... DNS lookup name: selector1._domainkey.yourdomain.com ``` The values above are illustrative only. Your provider generates the actual selector and DNS target. Do not publish a selector, key, or target copied from another tenant. A CNAME changes where the DNS lookup is resolved. It does not change the signature fields on the message. The provider must sign mail using the selector and signing domain that correspond to the published DNS path. ### The selector hostname aliases the provider target A provider using delegated DKIM supplies a CNAME record name under your domain and a target hostname under its DNS zone. Publish the alias exactly as supplied. ```text selector1._domainkey.yourdomain.com. CNAME selector1.dkim.provider.example. ``` This is an illustrative structural example only. Use the exact hostname and target generated in your provider's domain-authentication settings. ![DKIM CNAME delegation showing a selector lookup under your domain resolving to a provider-hosted DKIM key](/images/editorial/dkim-cname/dkim-cname-record-map.webp "1200x466") *Source: Palisade.* The DNS architecture matters. Under [RFC 1034's CNAME rules](https://datatracker.ietf.org/doc/html/rfc1034), if a CNAME resource record is present at a node, no other data should be present there. In practice, do not leave a TXT record at the same selector hostname when you publish a CNAME. [Check the existing DNS record set](/tools/dns-lookup) before changing it. > Replacing a live DKIM TXT record can interrupt verification for mail that still signs with that selector. Confirm which system uses the selector and retain a working validation path before removing an existing record. ### The provider values must match the production sender The CNAME record only delegates a DNS lookup. It does not prove that every message sent with your visible `From:` domain uses the provider, the configured selector, or a valid DKIM signature. Follow the provider's official setup instructions for its values, verification process, and supported domain type. Provider labels and steps vary. Some services call this domain authentication, domain setup, or DKIM configuration. Use the current provider interface or its official documentation rather than a record example from another platform. For subdomain traffic, confirm the domain in the message's `d=` value and the domain the provider asks you to authenticate. A subdomain can have its own DKIM configuration. See whether a subdomain needs its own DKIM setup before publishing records for a separate sending domain. ## When does the requirement take effect? There is no single industry-wide effective date for DKIM CNAME records. A CNAME is a DNS mechanism, and DKIM is an IETF standard. Whether you must use a CNAME, a direct TXT record, or another provider-specific method depends on the sending service you selected. [RFC 6376](https://www.rfc-editor.org/rfc/rfc6376.html) is the controlling DKIM specification and is an IETF Standards Track RFC. It specifies how DKIM signatures and public-key retrieval work. It does not require every sender to publish a CNAME. Provider domain-authentication requirements take effect when you enable the provider's sending feature or when that provider changes its documented process. Check the provider's current documentation before an implementation or migration. A previously verified domain status is not evidence that current DNS records still match the provider's active configuration. ## How do I implement the requirement? ### 1. Identify the actual sending platform List the platform that sends the mail, the domain in the visible `From:` address, and the domain or subdomain the platform says it will sign. Open that platform's official domain-authentication instructions. If you use Cloudflare DNS, the [Cloudflare DKIM setup guide](/learning/cloudflare-dkim-setup) can help with entering the provider-issued record at the DNS host. It does not replace the sending provider's DKIM instructions. ### 2. Generate the provider's DKIM records Enable DKIM or domain authentication in the sending provider's current interface. Copy every record name and target exactly as generated. Record values are account-specific. Do not substitute a generic selector such as `selector1` or a target from a tutorial for the provider-generated values. ### 3. Inspect the existing selector hostname Before adding a CNAME, look for an existing record at the exact selector hostname. Determine whether it is an active DKIM TXT record used by another sender. If a TXT record exists at the same hostname, do not add a CNAME beside it. Plan a selector migration with the sender owner. A new selector is often safer than replacing a selector that may still sign production traffic. ### 4. Publish each CNAME in authoritative DNS Create each provider-issued record as type `CNAME`. Enter the record name and target according to your DNS host's field conventions. Some DNS interfaces append the zone name automatically, so verify the fully qualified name after saving. Do not add quotation marks around a CNAME target. Do not add a DKIM TXT key at the same hostname. ### 5. Complete provider verification Use the provider's verification status after the DNS records are visible. If verification fails, compare the published fully qualified name and target against the generated values character by character. The provider status checks its expected DNS condition. It does not prove that mail has been sent through the configured production path. ## How do I validate compliance? Validate DKIM CNAME setup at four layers. - **DNS:** Query the exact selector hostname through the authoritative DNS service and a public resolver. Confirm it returns the expected CNAME target, then follow the alias to the provider-hosted DKIM key. The [DKIM lookup tool](/tools/dkim) is appropriate when you have the selector and sending domain. A public lookup cannot prove the production sender uses that selector, monitor later DNS changes, or predict a receiver's inbox decision. - **Vendor:** Confirm the sending provider marks the authenticated domain or DKIM configuration as verified. Record the selector names the provider expects. - **Message:** Send a real message through the exact production path to a mailbox you control. Inspect its raw headers. Under [RFC 8601](https://www.rfc-editor.org/rfc/rfc8601.html), `Authentication-Results` communicates authentication assessment results. Look for the DKIM result, the signing domain, and the selector where available. ```text Authentication-Results: receiver.example; dkim=pass header.d=yourdomain.com header.s=selector1 ``` This header is illustrative only. Receiver formatting and available properties can vary. A provider dashboard is not a substitute for this delivered-message check. - **DMARC:** Once aggregate reports accumulate, inspect which sources sign for the domain and whether their DKIM results align with the visible `From:` domain. A DKIM pass by itself may not satisfy DMARC alignment requirements. ![Four-layer DKIM CNAME validation flow covering DNS, provider verification, delivered message, and DMARC alignment](/images/editorial/dkim-cname/dkim-cname-validation-flow.webp "1200x676") *Source: Palisade.* For a single DNS question, use the DKIM lookup tool. For an ongoing estate with multiple sending platforms, Palisade can analyze DMARC aggregate-report data, identify sending sources and authentication or alignment issues, and create prioritized remediation tickets. It can propose the next policy step when evidence supports it, but a human reviews the evidence and applies any DNS or DMARC policy change. ## Inspect the delegated DKIM record, then track the sources behind it Start by checking the exact selector and signing domain the provider gave you. [Check the DKIM record](/tools/dkim) A successful public lookup confirms the published DNS path at that moment. It cannot prove that every production sender signs with the selector, that every signature aligns with the visible `From:` domain, or how receivers will handle future messages. If your organization uses several sending services, that remaining gap is source inventory and repeated evidence from DMARC reports. Palisade is agentic DMARC software for teams that need to identify sources, investigate authentication and alignment issues, and work through prioritized remediation. It does not autonomously change your DNS or DMARC policy. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=email_authentication&utm_content=dkim-cname) ## Sources and further reading - [RFC 6376: DomainKeys Identified Mail Signatures](https://www.rfc-editor.org/rfc/rfc6376.html) - [RFC 1034: Domain names, concepts and facilities](https://datatracker.ietf.org/doc/html/rfc1034) - [RFC 8601: Message Header Field for Indicating Message Authentication Status](https://www.rfc-editor.org/rfc/rfc8601.html) ## Frequently asked questions ### Is a DKIM CNAME record the DKIM public key? No. The CNAME record is an alias. It directs the DKIM selector lookup to another hostname where the provider publishes the DKIM public key. ### Can a DKIM selector have both a CNAME and TXT record? No. RFC 1034 says that when a CNAME record is present at a node, no other data should be present there. Do not publish a CNAME and DKIM TXT record at the same selector hostname. ### Does a verified provider status prove DKIM passes on live mail? No. It proves the provider found the DNS condition it expects. Send a message through the exact production path and inspect its authentication results to confirm the signature is present and passes. ### Does a DKIM CNAME record guarantee DMARC passes? No. DKIM validation and DMARC evaluation are separate checks. A delivered message also needs the applicable DMARC alignment condition for DKIM to satisfy DMARC. ### Can different email platforms use different DKIM selectors? Yes. Different sending platforms can use distinct selectors under the same domain. Validate each platform's DNS records and send a test message through each production path. --- # How do you set up DKIM on Postfix with OpenDKIM? Canonical: https://www.palisade.email/learning/dkim-postfix-opendkim > DKIM on Postfix with OpenDKIM requires a matching milter, signing-table mapping, DNS key, and same-path message validation for every sending route. To set up DKIM on Postfix with OpenDKIM, connect Postfix to the OpenDKIM milter, map the actual sending domain to a private signing key, publish that selector's public key in DNS, and validate a newly delivered message. The setup is incomplete if mail leaves unsigned, the receiver cannot find the selector record, or the receiver reports `dkim=fail`. ## Quick takeaways - Postfix submits eligible mail to OpenDKIM through a configured milter endpoint. - OpenDKIM needs a SigningTable rule that matches the domain used by the message. - The public key DNS name comes from the `s=` selector and `d=` domain in `DKIM-Signature`. - A visible `DKIM-Signature` header shows that a signer added a signature, but receiver-added `dkim=pass` verifies it. - A public DKIM record does not prove that the local Postfix path reached OpenDKIM or selected the intended private key. - A DKIM pass supports DMARC only when the DKIM signing domain aligns with the visible From domain. For broader context on the protocol and its role in DMARC, see the [email authentication learning center](/learning). ## What does the failure mean? A Postfix and OpenDKIM setup has failed when a test message has no `DKIM-Signature` header, or when the receiving system reports a DKIM failure. [RFC 6376 defines DKIM's selector-based public-key lookup and signature verification process](https://www.rfc-editor.org/rfc/rfc6376.html). Start with the received message because it shows what the production path actually delivered. A receiver may report this exact evidence: ```text Authentication-Results: receiver.example; dkim=fail (body hash did not verify) header.d=example.com ``` The result means the receiver calculated a different canonicalized body hash from the value in `bh=`. It does not prove that DNS is wrong. If no `DKIM-Signature` header exists, the strongest initial inference is that Postfix did not reach OpenDKIM, OpenDKIM did not select a signing key, or the message did not match a signing rule. [RFC 8601 defines `Authentication-Results` as the header field used to report message-authentication assessments](https://www.rfc-editor.org/rfc/rfc8601.html). Treat receiver-added results as the useful verification evidence. Preserve the full raw source because a mail-client view can omit headers and cannot show the exact body bytes that were verified. ![Flow showing Postfix passing mail to OpenDKIM, OpenDKIM selecting a key, DNS returning the public key, and the receiver verifying the signature](/images/editorial/dkim-postfix-opendkim/dkim-postfix-opendkim-signing-flow.webp "1200x829") *Source: Palisade.* ## What usually causes it? ### The Postfix milter and OpenDKIM listener do not match [Postfix documents `smtpd_milters` and `non_smtpd_milters` as Milter connection settings](http://www.postfix.org/MILTER_README.html). Postfix must use the same reachable Unix socket or TCP listener that OpenDKIM is configured to accept. Compare endpoint type, host, port, path, permissions, and any Postfix chroot implications. A connection error can indicate a stopped service, an incorrect endpoint, or socket permissions. It does not identify the precise local cause by itself. ### Locally submitted mail bypasses the configured milter `smtpd_milters` applies to mail received through SMTP. `non_smtpd_milters` applies to locally submitted mail, such as messages from an application, cron, or the local `sendmail` interface. A successful SMTP test does not prove that application-generated mail is signed. This is an inference from the submission path and Postfix configuration. Confirm it with a fresh message sent through the same path that normally produces the failed result. ### The SigningTable does not match the sending identity [OpenDKIM documents KeyTable and SigningTable as the mechanism for associating messages with keys](http://opendkim.org/opendkim.conf.5.html). A rule that matches `*@yourdomain.com` will not select a key for a different sending domain. Check the visible From domain and the message's actual signing identity. Do not assume the envelope sender, application domain, and visible From domain are identical. ### The selector record is absent, malformed, or published at the wrong DNS owner name The receiver looks up the key at `<selector>._domainkey.<domain>`, using `s=` and `d=` from the signature under [RFC 6376's key-query rules](https://www.rfc-editor.org/rfc/rfc6376.html#section-3.6.2). A DNS control panel may append the zone name automatically, so entering a complete name can create an unintended owner name. A public lookup can confirm what public DNS currently returns. It cannot inspect the private key, prove OpenDKIM signed the message, or prove that Postfix reached the milter. ### A later system changed the message after signing A `dkim=fail (body hash did not verify)` result means the verifier's canonicalized body hash differs from `bh=`. A footer service, mailing list, gateway, or content-rewriting system may have changed signed content after OpenDKIM ran. That attribution remains an inference until raw messages from both sides of the suspected hop are compared. Changing the DMARC policy does not repair a DKIM body-hash failure. That changes requested enforcement, not the signed message content. ## How do I diagnose the failure? ### 1. Preserve the receiver's raw message and build a signing evidence packet Send a fresh message through the exact application, Postfix route, recipient provider, and content path that exposes the problem. Save the complete raw source in an access-controlled location. Collect this labelled signing evidence packet: - MTA context: the Postfix and OpenDKIM host names, versions, service status, and the submission path used for the test. - Signature identity: the `d=` domain and `s=` selector from `DKIM-Signature`. - Mapping reference: the exact redacted KeyTable entry and SigningTable rule expected to select that key. - DNS result: the owner name queried and the public result for `<selector>._domainkey.<domain>`. - Receiver result: the receiver-added `Authentication-Results` field and the DKIM outcome. - Delivery correlation: queue or message ID, sending time, recipient test mailbox, and relevant redacted service-log lines. - Controlled test outcome: whether the same message passed or failed when one suspected route, modifier, or submission method was changed. Do not share private keys, tokens, full recipient lists, or unredacted message headers in tickets. ### 2. Compare the configured milter endpoint The following fragment is illustrative only. It is a redacted configuration-to-header example, not a universal Postfix or OpenDKIM path. ```text # /etc/postfix/main.cf, illustrative only smtpd_milters = inet:localhost:8891 non_smtpd_milters = inet:localhost:8891 # OpenDKIM signing mapping, illustrative only KeyTable: selector1._domainkey.yourdomain.com yourdomain.com:selector1:/path/to/selector1.private SigningTable: *@yourdomain.com selector1._domainkey.yourdomain.com # Expected evidence from a fresh delivered message DKIM-Signature: v=1; d=yourdomain.com; s=selector1; ... Authentication-Results: receiver.example; dkim=pass header.d=yourdomain.com ``` > Do not copy a socket, private-key path, selector, or DNS value from another server. Use the values created for the host and domain you operate. The OpenDKIM service account needs access to its key without making that key broadly readable. Inspect both Postfix milter settings and the OpenDKIM listener. Then send a test while checking the relevant logs for a connection attempt and a signing decision. ### 3. Confirm the signing-table match Compare the actual sender identity from the received message with the applicable SigningTable rule. If OpenDKIM signs `yourdomain.com` but the application sends as `mail.yourdomain.com` or another domain, the expected rule may not match. The KeyTable reference must identify the selector, signing domain, and private-key location that OpenDKIM can read. This local mapping is evidence about the signer. It is separate from the public DNS record. ### 4. Query the exact selector record Copy `s=` and `d=` from the received signature, then look up the resulting public owner name. Use the [DKIM checker](/tools/dkim) to inspect the publicly visible selector record. For selector naming and CNAME-based publishing, see [what a DKIM CNAME record is and how to set it up](/learning/dkim-cname). A passing public result does not prove that this Postfix instance selected the matching private key, that the milter signed locally submitted mail, or that a receiver accepted a particular message. ### 5. Distinguish DKIM verification from DMARC alignment If the receiver reports `dkim=pass` but DMARC fails, compare `header.d=` with the visible From domain. DMARC requires an aligned authenticated identifier, not merely any valid DKIM signature. Keep that investigation separate from a missing signature or selector-record failure. ## How do I fix it? ### Repair a missing selector record When the exact `<selector>._domainkey.<domain>` lookup has no usable result, publish the public key generated for the corresponding OpenDKIM key. Confirm the DNS owner's final name with the DNS provider before publishing. This repair changes DNS publication. It does not prove which local key OpenDKIM used. Retest with a newly signed message after public DNS returns the intended record. ### Repair a mapping or signing-domain mismatch When the message domain does not match the SigningTable rule, update the narrowest applicable mapping so the intended sending domain selects the expected KeyTable entry. Confirm that the key-table domain and selector match the intended `d=` and `s=` values. Make one mapping change at a time and retain the previous configuration for rollback. Do not relax DMARC policy to conceal an unsigned or misaligned path. ### Repair message mutation after signing When controlled raw-message comparison identifies a post-signing body change, remove the confirmed transformation or move signing after that trusted modification. Verify that every intended outbound path reaches the new signing position. A changed footer, encoding, MIME boundary, or rewritten content can affect DKIM verification even when the message looks unchanged in a mail client. Do not regenerate a key as the first response to a confirmed body-hash mismatch. ## Investigate this with your coding agent Use this when the production path remains unresolved after you have collected redacted configuration, DNS, log, and same-path message evidence. Prepare only the variables needed to trace the repository-owned configuration. ```agent Problem: Postfix with OpenDKIM leaves the affected production message unsigned or the receiver reports a DKIM failure for the stated selector and signing domain. Evidence: Redacted sending domain, selector, d= domain, Authentication-Results result, queue or message ID and time, public DNS lookup result, KeyTable and SigningTable references, milter endpoint, and controlled test outcome. Repository scope: Repository-owned mail configuration, infrastructure-as-code, deployment manifests, runbooks, and tests at the supplied repository location. Constraints: Inspect before editing. Do not apply changes until I approve the proposed diff. Exclude private keys, tokens, unredacted headers, customer data, and production credentials. Limit recommendations to the affected Postfix route, OpenDKIM mapping, or DNS declaration. Requested output: Evidence-linked diagnosis, smallest proposed change, rollback notes, and unresolved assumptions. Verification: Run the relevant repository checks, inspect the public DKIM result, and repeat the same message path used to expose the issue. Stop if: Credentials, private data, production mutation, a source of truth outside the repository scope, or missing evidence is required. ``` ## How do I validate the repair? Repeat the original sending path with a new message. Check all four applicable layers: - DNS: query the exact selector record through the authoritative DNS source and at least one public resolver. - Vendor and service state: confirm that Postfix can reach the configured OpenDKIM listener and that OpenDKIM selected the intended signing identity. - Message: inspect the receiver-added `Authentication-Results` for `dkim=pass` and confirm the expected `header.d=` value. - DMARC: after aggregate data accumulates, check that the source appears with the expected authentication and alignment outcome. A green DNS result is not proof of local signing. A `dkim=pass` on a minimal test is not proof that every production template, application, or route will pass. Repeat any content and routing cases that were part of the original failure. ![Decision flow for missing DKIM signatures, absent selector records, signing-domain mismatches, and body changes after signing](/images/editorial/dkim-postfix-opendkim/dkim-postfix-opendkim-repair-branches.webp "1200x829") *Source: Palisade.* ## Check the public DKIM record behind this Postfix result After collecting the `d=` and `s=` values from the failed or passing message, inspect the selector record with the [Palisade DKIM checker](/tools/dkim). Compare the visible DNS answer with the signing evidence packet before changing local configuration. [Check the public DKIM selector](/tools/dkim) A public record check cannot access the private key, repair a Postfix or OpenDKIM mapping, monitor every sending path, or prove why an individual receiver accepted or rejected a message. If you need ongoing evidence across domains and sources, [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=email_authentication&utm_content=dkim-postfix-opendkim). Palisade analyzes DMARC aggregate-report data, identifies sources and authentication or alignment issues, and proposes next policy steps for human review. It does not change your DMARC policy or guarantee delivery. ## Sources and further reading - [RFC 6376: DomainKeys Identified Mail](https://www.rfc-editor.org/rfc/rfc6376.html) - [RFC 8601: Authentication-Results header field](https://www.rfc-editor.org/rfc/rfc8601.html) - [Postfix Milter documentation](http://www.postfix.org/MILTER_README.html) - [OpenDKIM opendkim.conf documentation](http://opendkim.org/opendkim.conf.5.html) - [Palisade DKIM checker](/tools/dkim) - [Cloudflare DKIM setup guide](/learning/cloudflare-dkim-setup) - [RFC 9989: Domain-based Message Authentication, Reporting, and Conformance](https://www.rfc-editor.org/rfc/rfc9989.html) ## Frequently asked questions ### Does Postfix sign DKIM messages by itself? No. Postfix can send mail to a Milter, but OpenDKIM or another configured signing service applies the DKIM signature. The message must pass through the configured milter path. ### Can a public DKIM record prove OpenDKIM is working? No. A public lookup confirms what DNS returns for a selector. It cannot prove that Postfix reached OpenDKIM, that OpenDKIM selected a private key, or that the tested message was signed. ### Does `dkim=pass` mean DMARC passes? Not always. The DKIM signing domain must align with the visible From domain for DKIM to satisfy DMARC. A valid signature from an unrelated domain can still leave DMARC failing. ### Should I change DMARC to `p=none` when Postfix mail is unsigned? No. Changing `p=` changes the domain's requested DMARC handling. It does not connect Postfix to OpenDKIM, select a signing key, or publish the required selector record. ### Can a footer added after OpenDKIM signs mail cause DKIM failure? Yes. A body change after signing can cause `dkim=fail (body hash did not verify)` when it affects content covered by the signature. Confirm the responsible hop by comparing raw messages from the relevant paths. --- # DMARC audit template for MSPs Canonical: https://www.palisade.email/learning/dmarc-audit-template-for-msps > Use this DMARC audit template to record per-client DNS, report, sender, ownership, approval, and retest evidence before remediation. An MSP DMARC audit should create a per-client decision record, not just a DNS scan. Record the scoped domains, public DMARC/SPF/DKIM evidence, aggregate-report observations, known senders, client confirmation, finding owner, approval state, and retest result. That distinction matters because [DMARC](https://www.rfc-editor.org/rfc/rfc9989.html) validates aligned domain identifiers and publishes a handling preference, but neither a passing lookup nor a report row authorizes a sender or a DNS change. ## Quick takeaways - Use one worksheet per client and domain scope, with an owner for every open finding. - Keep public DNS, aggregate-report observations, and client authorization as separate fields. - Treat a DMARC checker as evidence of the published record, not proof of every production sender. - Record a recommendation separately from approval and from the post-change retest. - Move completed sender governance into an [MSP email sender inventory](/learning/msp-email-sender-inventory), rather than reopening the audit for each review. ## Operating context and ownership This template is for the first DMARC-specific assessment of a client portfolio. It narrows the broader [client email security assessment](/learning/how-do-msps-run-an-email-security-assessment-for-a-new-client) to evidence that supports a DMARC remediation decision. It does not replace sender onboarding, policy rollout, or the recurring client review described in [DMARC QBR reporting](/learning/dmarc-qbr-reporting). The MSP may collect evidence, classify a finding, and recommend a next action. The client decides whether a sender is legitimate and approves business-risk changes. The DNS host publishes records, while a sending provider controls its own signing and return-path configuration. Mail receivers choose their own final handling: RFC 9989 says a receiver can honor a domain owner's requested handling, but is not required to do so. That is why the worksheet records an approval and retest rather than promising a delivery outcome. ## Evidence to collect Use these fields for each scoped domain. They are a Palisade operating framework, not fields required by an RFC. - **Scope and ownership:** client, domain, business owner, technical approver, DNS change owner, and review date. - **Public configuration:** observed DMARC record, `p` value, alignment modes, `rua` destination, SPF record, and DKIM selectors known from the client or a delivered message. - **Observed mail evidence:** aggregate-report date range, sending IP or source label, count, SPF/DKIM/DMARC result, and a link or ticket reference for the evidence. [RFC 9990](https://www.rfc-editor.org/rfc/rfc9990.html) defines the aggregate-report format; it is evidence about receiver observations, not a complete inventory of every sender. - **Authorization and finding:** client-confirmed, unknown, retired, or disputed sender state; finding severity; the owner who must decide or act; and the recommendation. - **Decision and retest:** approval status, approved change reference, retest method, result, and the next review date. Keep the worksheet portable so it can live in a ticket, PSA, or version-controlled runbook. Do not put mailbox content, customer addresses, private keys, or full unredacted message headers in a shared portfolio record. ![DMARC audit record anatomy groups scope, technical evidence, authorization, decision, approval, and retest fields so an MSP does not confuse an observation with client approval](/images/editorial/dmarc-audit-template-for-msps/dmarc-audit-record-anatomy.svg "1200x611") *Source: Palisade original deterministic operating diagram. The grouping is a reusable operating recommendation, not an RFC-required form.* ```yaml client: <client-name> domain: <author-domain> scope_status: in-review public_dmarc: <observed TXT record or absent> report_window: <YYYY-MM-DD through YYYY-MM-DD> observed_sender: <source label or IP reference> authorization: client-confirmed | unknown | retired | disputed finding: <specific evidence-backed gap> decision_owner: <client approver | sender owner | DNS owner> recommendation: <proposed action, not an applied change> approval_status: pending | approved | declined retest: <DNS, delivered message, or report evidence> review_on: <YYYY-MM-DD> ``` ![DMARC audit flow separates scoped evidence from client authorization, then tracks a recommendation through approval and retest, with unknown senders routed to an exception record](/images/editorial/dmarc-audit-template-for-msps/dmarc-audit-evidence-flow.svg "1200x1024") *Source: Palisade original deterministic operating diagram informed by [RFC 9989](https://www.rfc-editor.org/rfc/rfc9989.html) and [RFC 9990](https://www.rfc-editor.org/rfc/rfc9990.html). It shows an MSP workflow, not a protocol requirement.* ## How to run the workflow ### 1. Set the client and domain boundary List the domains and subdomains the client wants assessed, then name the business owner, technical approver, and DNS change owner. Record exclusions such as a divested brand or a vendor-managed subdomain. A missing owner is itself a finding because the MSP cannot infer authorization from DNS. ### 2. Capture public DNS evidence Use the [DMARC checker](/tools/dmarc) to record the published DMARC TXT record, policy, and reporting destination. Capture SPF and available DKIM evidence as separate fields. SPF authorizes a domain's use by a client IP during SPF evaluation, subject to the mechanism and lookup rules in [RFC 7208](https://www.rfc-editor.org/rfc/rfc7208.html); it does not establish that a business owner approved a particular application. Do not change the record while collecting a baseline. A public lookup cannot reveal every sender, prove which team owns a service, or show the authentication result of a delivered message. ### 3. Add report and message observations Where aggregate reports are available, add the reporting period, source, volume, and the reported SPF/DKIM/DMARC results. Mark each source as `report-observed`, not automatically authorized. For a disputed or business-critical path, request a redacted delivered-message sample and compare the receiver-added authentication evidence with the public record. RFC 9989 explains that a DMARC pass requires aligned SPF or DKIM, and it also cautions that a pass does not guarantee inbox placement. Treat a failing observation as a finding to investigate, not as proof that the source is malicious or the root cause is known. ### 4. Ask the client to classify each source Ask the client or designated system owner whether each observed source is legitimate, retired, unknown, or disputed. Capture the answer and the accountable person. If no one can confirm a source, create an exception rather than silently adding it to SPF or treating it as safe. This is the multi-client step a simple audit lacks. The same IP or source label can mean different things for two clients, and an MSP should not carry an authorization decision across tenants. ### 5. Write an evidence-backed recommendation State the exact gap and proposed action. For example: "The domain publishes `p=none`; two client-confirmed senders have no recorded aligned DKIM result; collect delivered-message evidence and enable the sender's custom DKIM before proposing a policy change." Keep the policy recommendation separate from any applied DNS value. For a stronger policy, route the work to a documented safe DMARC policy rollout. The audit provides the decision record; it is not permission to enforce. ### 6. Record approval and retest evidence After the authorized owner accepts a change, save the change reference and retest the same evidence layer that produced the finding. Re-query DNS for a record change, inspect a new delivered message for an authentication finding, or review a later report period for an observed-source finding. Record the result, reviewer, and next review date. If the result does not resolve the finding, reopen it with the new evidence instead of marking the audit complete. ## Investigate this with your coding agent Use this only when the worksheet or a report-normalization script lives in a repository. Prepare a redacted fixture with no customer domains, message content, credentials, or private keys. ```agent Problem: The audit worksheet does not consistently require a decision owner, approval status, and same-path retest for every DMARC finding. Evidence: A redacted worksheet fixture and the repository's existing audit-template schema or report-normalization tests. Repository scope: Inspect only the version-controlled audit-template, schema, parser, and associated tests. Constraints: Inspect before editing. Do not apply changes until I approve the proposed diff. Do not access client systems, cross tenant boundaries, secrets, production DNS, or active incidents. Requested output: Identify missing required fields, propose the smallest schema or template diff, include test updates and a rollback note, and list any ambiguous field mapping. Verification: Run the repository's template or parser tests against the redacted fixture and show the expected validation result. Stop if: Customer data, credentials, a production mutation, or a client approval is required, or the fixture cannot distinguish observation from authorization. ``` ## Exceptions and escalation Create an exception when a source lacks a confirmed owner, report evidence conflicts with the client inventory, a sender cannot demonstrate aligned authentication, or a client cannot approve a safe test window. Each exception needs the evidence, impact context, requested decision, owner, and review date. Escalate a business-critical sender to the client approver and sender owner before any policy change. Escalate unclear DNS control to the client relationship owner. The MSP can recommend a hold, a test, or remediation sequencing; it should not authorize a sender or accept residual client risk on the client's behalf. ## Reporting and success measures Keep a client-facing audit summary limited to the scope, confirmed and unknown sources, open findings by owner, approval state, and retest status. Review the shared portfolio queue for overdue exceptions and findings without a decision owner. Do not turn those fields into a universal protection score: they show the state of the audit record, not a guarantee about all mail. ## Check the public record before you open a finding Run the scoped domain through Palisade's DMARC checker to capture the public record used in the worksheet. Start there when the gap is unknown or the published policy needs confirmation. [Check a DMARC record](/tools/dmarc) A public record check cannot identify every production sender, approve a change, inspect private report data, or prove why a specific message reached a mailbox. ## Continue recurring sender review across client domains A completed public lookup and one audit baseline still do not show which production sources later fail alignment, which client adds a new sender, or which portfolio exceptions are overdue. [Palisade's DMARC Agent](https://docs.palisade.email/guides/fixing-authentication-issues/) analyzes DMARC aggregate-report data, identifies sending sources and authentication or alignment issues, creates prioritized remediation tickets, and detects when a domain appears ready for the next policy stage. A human reviews the evidence and applies any DNS or policy change. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=msp_operations&utm_content=dmarc-audit-template-for-msps) Palisade does not authorize a client sender, change external DNS without human approval, control a receiving mailbox provider, or guarantee delivery. ## Sources and further reading - [RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance](https://www.rfc-editor.org/rfc/rfc9989.html) - [RFC 9990: DMARC Aggregate Reporting](https://www.rfc-editor.org/rfc/rfc9990.html) - [RFC 7208: Sender Policy Framework](https://www.rfc-editor.org/rfc/rfc7208.html) - [Palisade DMARC documentation](https://docs.palisade.email/) ## Frequently asked questions ### Is a DMARC checker enough for an MSP audit? No. A checker can document the published record, but it cannot establish every sending source, client authorization, or the authentication result of a specific delivered message. ### Should an MSP add every source in an aggregate report to SPF? No. A report observation needs client or sender-owner confirmation first. An unknown source belongs in an exception record until the responsible party can classify it. ### Who approves a DMARC policy change? The client owner or an explicitly delegated approver should approve the change. The MSP can supply evidence, a recommendation, and a retest plan. ### What closes a DMARC audit finding? Only a recorded decision and a retest that addresses the original evidence should close it. A DNS change, an approval, or a dashboard status alone does not prove the finding is resolved. --- # DMARC QBR reporting: an MSP decision workflow Canonical: https://www.palisade.email/learning/dmarc-qbr-reporting > DMARC QBR reporting gives MSPs a reusable way to turn aggregate-report evidence into client decisions, owners, exceptions, and dated follow-up. DMARC QBR reporting should turn each client's aggregate-report evidence into a dated decision record. Separate what receiving systems observed from the MSP's interpretation, then document the client decision, owner, next action, evidence boundary, and review date. This gives an MSP a repeatable way to keep authentication exposure visible across tenants without treating report counts as proof of sender authorization, delivery, or business impact. ## Quick takeaways - DMARC aggregate reports record grouped receiver observations for a policy domain and reporting period. - An unfamiliar source needs investigation. It is not proof that a sender is legitimate or unauthorized. - A QBR finding should separate observed evidence, MSP recommendation, client decision, owner, and review date. - The client approves business risk and changes to DNS, sender configuration, or the DMARC policy. - A public DMARC record check confirms a published record, but does not prove the production sending path or a receiver's private handling decision. - Quarterly review rules in this article are a Palisade operating framework, not an RFC requirement. ## Operating context and ownership This workflow is for MSPs, MSSPs, and multi-tenant IT teams that must convert recurring DMARC evidence into client decisions. [RFC 9990 defines DMARC aggregate reporting](https://www.rfc-editor.org/rfc/rfc9990.html) as XML feedback sent by reporting receivers for a policy domain. A report includes metadata, published policy information, grouped source observations, policy evaluation, and SPF or DKIM results. Aggregate reports show what a reporting receiver observed. They do not establish that a client authorized a sender, explain every root cause, reveal a receiver's private reputation decision, or prove inbox placement. An MSP recommendation is therefore different from protocol evidence. Set the operating boundary before the first QBR: - The MSP service lead prepares the evidence packet, maintains the action register, and coordinates follow-up. - The authentication specialist interprets reported authentication and alignment outcomes. - The client approver accepts business risk and authorizes scoped changes. - The DNS host publishes approved DNS records. - The sender owner controls the relevant ESP, application, CRM, or mail service configuration. - The receiving mailbox provider makes its own handling decision for each message. The [Palisade MSP workflow](/for-managed-service-providers) provides broader context for operating DMARC across client portfolios. A QBR does not replace an incident process. Use the agreed client escalation path when a suspected mail-flow issue needs immediate action. Keep these states distinct in every finding: - Observed fact: a receiver reported a source, message count, policy disposition, or authentication result. - MSP interpretation: the service team identified an investigation, remediation, or risk-acceptance question. - Client decision: an authorized role approved, deferred, declined, or accepted an exception. - Follow-up: a named owner has a specific action, evidence requirement, and review date. ![Flow showing how DMARC aggregate observations become an MSP recommendation, client decision, assigned owner, and dated review](/images/editorial/dmarc-qbr-reporting/dmarc-qbr-reporting-evidence-flow.webp "1200x676") *Source: Palisade.* ## Evidence to collect Create one evidence packet and action register for each client. Fix the reporting window before comparing periods, and retain the original reports or a traceable export. A quarterly summary without supporting evidence is difficult to defend when a client asks why a recommendation was made. Normalize these fields before the QBR: - Client and policy-domain scope, including excluded domains. - Reporting window, report sources, and known collection or coverage gaps. - Source identifier, observed message volume, and policy disposition. - `header_from` domain plus reported SPF and DKIM outcomes. - Sender changes since the prior review, including new or retired sources. - Unresolved failure clusters and the evidence boundary for each. - Current DMARC policy, policy-change proposal, and client decision. - Owner, escalation route, evidence links, next action, and next review date. [RFC 9989 defines the DMARC policy and alignment model](https://www.rfc-editor.org/rfc/rfc9989.html). Use its terminology precisely. A reported alignment failure supports an investigation, but it is not a root-cause diagnosis until the MSP has evidence from the sender configuration or a real delivered message from the exact production path. Use a portable quarterly evidence record in a PSA, ticket system, controlled spreadsheet, or client report: ```yaml client: "Example Manufacturing" domain: "yourdomain.com" evidence: reporting_window: "2026-04-01 through 2026-06-30" aggregate_reports: "Retained export reference" coverage_boundary: "Reports received for the stated window. Receiver-private decisions are unavailable." finding: "DKIM did not align with header_from for an observed source." owner: "Client marketing operations" next_action: "Identify the sending platform and provide a delivered-message sample." review_on: "2026-07-31" ``` This is a Palisade-authored operating artifact, not a required RFC format or threshold. A [DMARC record check](/tools/dmarc) can inspect the public DMARC record for one domain. It cannot show which sources sent during the quarter, establish sender authorization, monitor later changes, or expose a receiver's private delivery decision. ![DMARC QBR record anatomy showing evidence, interpretation, client decision, owner, next action, and review date](/images/editorial/dmarc-qbr-reporting/dmarc-qbr-reporting-qbr-record.webp "1200x639") *Source: Palisade.* ## How to run the workflow ### 1. Prepare the client evidence packet Owner: MSP service lead. Input: the agreed reporting window, normalized aggregate-report data, current DMARC policy, and prior action register. Output: a client-specific evidence packet with stated coverage boundaries. Group observations by source and authentication outcome. Highlight changes that need a decision, such as a repeated new source, recurring alignment failure, overdue exception, or completed remediation that lacks later message evidence. Do not rank risk by report volume alone. A low-volume payroll or billing sender may need faster review than a high-volume marketing path. ### 2. Classify material items before the QBR Owner: authentication specialist. Input: the evidence packet and available client sender inventory. Output: a classification and evidence boundary for each material item. Use states such as `known and healthy`, `known but unresolved`, `unknown`, `evidence-limited`, and `accepted exception`. Record why an item has that state and what evidence would change it. For example, aggregate data can establish repeated failed DKIM alignment. It cannot establish that the source is a legitimate client application. The next action may require client confirmation, sender-owner investigation, or a delivered-message sample after configuration work. Platform selection and client review are separate decisions. The [DMARC report analyzer comparison](/compare/best-dmarc-report-analyzers) can help assess report-analysis options, but an analyzer does not assign a client owner or approve an exception. ### 3. Write decision-ready findings Owner: MSP service lead. Input: classified evidence and technical interpretation. Output: a QBR action record that a client can approve or challenge. Each finding should state the observed evidence, interpretation, practical consequence, recommendation, client decision required, owner, evidence link, and review date. "Fix DMARC" does not establish ownership or a completion test. A useful finding can state that receivers repeatedly observed an unaligned DKIM result for a source, that the client must identify the sending platform, and that the sender owner must provide a new delivered-message sample after any proposed repair. The client may approve investigation, approve scoped remediation, accept a time-limited exception, or identify the source as unauthorized. ### 4. Record exceptions as client decisions Owner: client approver, documented by the MSP. Input: a finding that cannot close before the QBR. Output: an exception with a review path. An exception should name the affected domain or source, decision-maker, accepted risk, evidence gap, review date, and condition for reconsideration. A deferred item without a date is backlog, not an exception register. > Do not add an unfamiliar source to SPF or relax the DMARC policy to close a QBR action. Confirm the source, its business purpose, and its authentication path before proposing a change. ### 5. Validate completed actions on the same sending path Owner: sender owner, reviewed by the MSP. Input: the approved remediation and a real message from the affected production path. Output: evidence that distinguishes published DNS from actual message authentication. Validate applicable changes at four layers: - DNS: query the authoritative DNS server and at least one public resolver for the published record. - Vendor: confirm the sender's current authentication status in the sending platform. - Message: inspect a real delivered message from the exact production path and its `Authentication-Results` header. - DMARC: review later aggregate-report data after it accumulates. A green vendor indicator is not proof that a delivered message used the configured signing or return path. A passing DNS lookup is not proof of future receiver handling. For a focused discussion of whether failure reports add useful operational evidence, see [Are DMARC failure reports worth the trouble?](/learning/what-exactly-is-a-dmarc-failure-report-and-why-should-you-care). ## Exceptions and escalation Use an escalation path when the QBR cannot resolve the item through normal ownership: - Unknown source with material volume or business impact: ask the client to identify the sender and business purpose. - Known sender with failed alignment: assign the sender owner to investigate configuration and provide same-path message evidence. - Missing DNS authority or approval: move the item to blocked status and name the client decision-maker. - Business-critical sender without a safe test window: record a time-limited exception, rollback condition, and next review. - Receiver decision that conflicts with public evidence: use the mailbox provider's dashboard or message evidence. Aggregate reports cannot explain a private receiver decision. The MSP maintains the evidence and makes the recommendation. The client owns authorization and risk acceptance. The DNS host, sender, and mailbox provider each control parts of the outcome that an MSP cannot unilaterally change. ## Reporting and success measures Use the QBR to compare evidence and decisions, not to present a universal security score. The quarterly client artifact can include: - Domains reviewed and reporting-window coverage. - New, resolved, and unresolved sources. - Repeated SPF or DKIM alignment outcomes that need investigation. - Current policy state and any approved or deferred policy decision. - Exceptions by owner, age, review date, and decision status. - Actions completed with DNS, vendor, message, and later report evidence. Keep report counts attached to their context. A lower failure count may reflect fewer messages, incomplete report coverage, a changed sender mix, or a completed repair. Describe the observation and the decision it requires. Reporting depth can also define the service commitment. The [MSP DMARC management pricing guide](/learning/how-should-msps-price-dmarc-management-services) explains how recurring reporting and remediation work affect a managed-service model. ## Turn each client's DMARC evidence into an owned next step A completed QBR record exposes the recurring work that remains across the portfolio: identifying sources, investigating authentication or alignment issues, prioritizing remediation, and following up with the right owner. Palisade is agentic DMARC software. Its DMARC Agent analyzes aggregate-report data, identifies sending sources and authentication or alignment issues, and creates prioritized remediation tickets. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=msp_operations&utm_content=dmarc-qbr-reporting) Palisade does not authorize client senders, make DNS or DMARC-policy changes, replace client approval, or guarantee delivery or inbox placement. ## Sources and further reading - [RFC 9990: DMARC Aggregate Reporting](https://www.rfc-editor.org/rfc/rfc9990.html) - [RFC 9989: Domain-based Message Authentication, Reporting, and Conformance](https://www.rfc-editor.org/rfc/rfc9989.html) - [Palisade guide to fixing authentication issues](https://docs.palisade.email/guides/fixing-authentication-issues/) ## Frequently asked questions ### What should a DMARC QBR report include? A DMARC QBR report should include the policy-domain scope, reporting window, evidence coverage, observed sources, authentication and alignment outcomes, current policy state, unresolved exceptions, named owners, client decisions, next actions, and review dates. Keep observed facts separate from MSP recommendations. ### Can DMARC aggregate reports prove that a sender is authorized? No. Aggregate reports can show that a reporting receiver observed a source and its reported authentication outcome. Client confirmation, sender configuration evidence, and a real message from the production path are needed to establish whether a source is legitimate. ### Who approves a DMARC policy change in an MSP QBR? The client approver should authorize a DMARC policy change because the client owns the business risk. The MSP can prepare evidence, recommend a scoped change, document a rollback condition, and validate the result after approval. ### How should an MSP handle an unknown DMARC source? Record the source as unknown, preserve the report evidence, and assign client confirmation as the next action. Do not add it to SPF, authorize it, or change the DMARC policy until the client and sender owner establish its purpose and authentication path. ### Does a passing DMARC record check validate the QBR finding? No. A public record check validates the currently published DMARC record. It does not show which senders used the domain during the reporting window, whether they authenticated on the production path, or how a receiving mailbox provider handled a message. ### How often should MSPs run DMARC QBRs? Quarterly is a useful operating cadence for a managed portfolio, but it is a service-framework choice rather than an RFC requirement. Review urgent authentication failures and mail-flow incidents through the active escalation process instead of waiting for the next QBR. --- # DMARCian DMARC checker: what the public result can tell you Canonical: https://www.palisade.email/learning/dmarcian-dmarc-checker > Use the dmarcian DMARC checker safely: interpret its current maintenance notice or DNS record state, collect the right evidence, and retest. The dmarcian DMARC Record Checker currently displays a maintenance notice, so it cannot provide a live public-DNS result at this time. Its page still documents the record, missing-record, and syntax-error states it is designed to show. Treat any future checker output as DNS evidence for the domain you entered, then use delivered-message headers or aggregate reports before deciding whether a sender passes DMARC or a policy change is safe. ## Quick takeaways - dmarcian's public checker page currently says its tools are under maintenance. - The documented checker states concern a published DMARC record, not a specific delivered message. - A found record can establish what public DNS returned for one domain at one point in time. - A missing or malformed record needs authoritative DNS evidence before anyone changes it. - Message headers and aggregate reports answer different questions from a DNS lookup. ## What this tool checks The [dmarcian DMARC Record Checker](https://dmarcian.com/dmarc-inspector/) describes itself as a diagnostic for inspecting a domain's DMARC policy and potential issues. On 29 July 2026, its public page showed the maintenance notice along with an `Enter domain` input and `Inspect the domain` control. It also contains copy for a valid record, no record found, and syntax errors. That is real interface evidence, but it is not a submitted-domain result. [RFC 9989](https://www.rfc-editor.org/rfc/rfc9989.html) defines DMARC as a receiver evaluation of authenticated identifiers, alignment, and a domain policy. A public record lookup can help with the policy-record part. It cannot show whether a particular message had aligned SPF or DKIM, whether a receiver applied local handling, or whether mail reached an inbox. ## How to run the check ### 1. Record the current dmarcian state Open the [DMARC Record Checker](https://dmarcian.com/dmarc-inspector/) and record whether it is available or displays the maintenance notice. If the checker becomes available, enter only the domain you are authorized to inspect and retain the returned public record state. Do not treat the page's prewritten state descriptions as a result for your domain. ### 2. Capture the exact record evidence If a result says a record is present, save the returned record and domain. If it says the record is missing or malformed, confirm the result with an authoritative DNS query before changing anything. The checker page itself places DMARC at the `_dmarc` DNS location, while RFC 9989 defines how receivers discover a policy record. ```bash dig +short TXT _dmarc.example.com ``` ### 3. Separate DNS from message evidence For a sending-path or delivery question, collect a real delivered message and inspect receiver-added authentication results. For fleet evidence, review [DMARC aggregate reports](/learning/dmarc-aggregate-report-format), whose record format is defined in [RFC 9990](https://www.rfc-editor.org/rfc/rfc9990.html). Do not infer a message result from the public policy alone. ## How to interpret the results ### Maintenance notice The current notice means no dmarcian checker result was obtained. It does not mean the domain lacks DMARC or that its configuration is broken. Preserve the notice and use a second public-DNS lookup only if you need the record now. ### Record found A record-found result establishes that a public resolver returned a DMARC policy for the entered domain. It does not establish that every sender aligns, that every receiver follows the requested policy, or that a specific message passed. Use [what DMARC evaluates](/learning/what-is-dmarc) to separate a policy record from message authentication. ### Record missing or syntax warning dmarcian's page documents separate messages for a missing record and syntax errors. Confirm the exact TXT answer in authoritative DNS, identify the DNS owner, and make the smallest approved correction. A missing record is not evidence that no email is sent from the domain, and a syntax warning is not a reason to replace an existing record with an unrelated example. ![Four-stage evidence map for a dmarcian checker maintenance notice or record state, from public DNS evidence to message evidence and retesting.](/images/editorial/dmarcian-dmarc-checker/dmarcian-dmarc-checker-evidence-map.svg "1200x688") *Source: Original Palisade evidence map based on the [dmarcian DMARC Record Checker](https://dmarcian.com/dmarc-inspector/) and [RFC 9989](https://www.rfc-editor.org/rfc/rfc9989.html). It shows the boundary between a public-record result and message evidence.* ## How to act on the result Start with the narrowest action the evidence supports. For maintenance, run the same domain through an independent public lookup and keep the result with the date. For a missing or malformed record, verify the TXT answer with the DNS owner before proposing a change. For a record that is present, avoid changing `p=`, alignment tags, or report addresses until known senders and their message evidence have been reviewed. When external report addresses are involved, validate their authorization rather than assuming the policy is complete. The [external reporting authorization guide](/learning/dmarc-rua-ruf-domain-authorization) explains that separate DNS relationship. If the question is whether a mail stream passes, use a delivered message and aggregate reports, not the checker alone. ## How to retest After an approved DNS correction, wait for the responsible DNS provider and public resolvers to return the intended record. Rerun the same domain in the dmarcian checker when it is available, or use the same-domain alternative while maintenance continues. Then send a message from the affected production path and review its headers. DNS confirmation, a message result, and aggregate-report evidence are separate validation layers. ## Confirm the published record with the same domain If the dmarcian checker is under maintenance or its output needs an independent public-DNS reading, run the same domain through Palisade's [DMARC checker](/tools/dmarc). It can inspect the published record, policy, and visible tags before you propose a DNS change. If the result reveals a recurring sender-visibility problem, [Palisade's DMARC Agent feature documentation](https://www.palisade.email/features/dmarc-agent) describes analysis of DMARC aggregate-report data and prioritized remediation tickets for sender, SPF, DKIM, alignment, and policy issues. A human reviews the evidence and approves any DNS, sender, or policy change. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=dmarc_diagnostics&utm_content=dmarcian-dmarc-checker) A public checker cannot repair DNS, prove a particular message passed DMARC, control receiver handling, or guarantee delivery. ## Sources and further reading - [dmarcian DMARC Record Checker](https://dmarcian.com/dmarc-inspector/) - [RFC 9989: Domain-based Message Authentication, Reporting, and Conformance](https://www.rfc-editor.org/rfc/rfc9989.html) - [Palisade DMARC checker](https://www.palisade.email/tools/dmarc) - [Palisade DMARC Agent feature documentation](https://www.palisade.email/features/dmarc-agent) ## Frequently asked questions ### Is the dmarcian DMARC checker working now? No. The public page displayed a maintenance notice when this article was checked on 29 July 2026. Recheck the page before relying on that availability state, because the tool may return to service. ### Can a DMARC record checker prove a message passed? No. A public checker can show a DNS policy record and related record-level findings. A delivered message's authentication results and alignment evidence are needed to assess that message's DMARC result. ### Does a missing record mean no one sends mail from the domain? No. A missing DMARC record says public DNS did not supply that policy record for the queried domain. It does not inventory senders, establish authorization, or describe mail already in transit. ### Should I change a DMARC policy after a syntax warning? Only after you confirm the exact authoritative TXT answer, identify the record owner, and understand the intended correction. Do not replace a record from a generic example or change enforcement without sender and message evidence. ### Can Palisade's DMARC checker replace aggregate reports? No. It can inspect the public policy record for a domain. Aggregate reports add receiver-reported evidence across senders and time, which a one-time DNS lookup cannot provide. --- # Email authentication failure: diagnose the right layer Canonical: https://www.palisade.email/learning/email-authentication-failure > Email authentication failure diagnosis starts with the failed message. Separate SPF, DKIM, DMARC, and SMTP evidence before changing DNS and headers. An email authentication failure must be diagnosed at the layer that failed: SPF authorization for the envelope identity, DKIM signature verification, DMARC identifier alignment, or a separate SMTP receiver policy. Preserve the failed message and its complete headers first. Then compare the named identities and retest through the same application and route. A public DNS result is useful, but it does not prove what happened to that production message. ## Quick takeaways - A trusted receiver-added `Authentication-Results` field is stronger evidence than a public DNS lookup. - SPF evaluates the MAIL FROM or HELO identity, which can differ from the visible From domain. - DKIM verification depends on the exact `d=` signing domain and `s=` selector in the failed message. - DMARC needs an aligned SPF pass or an aligned DKIM pass for the visible From domain. - SPF and DKIM can both pass while DMARC fails when their passing identities do not align. - Do not relax the DMARC policy to hide an SPF, DKIM, or alignment problem. ## What does the failure mean? [Authentication-Results](https://www.rfc-editor.org/rfc/rfc8601.html) records message-authentication results inside a receiver's trust boundary. Use the result added by the receiving system that accepted the message. A copied header in a forwarded message can be untrusted evidence. Start by creating a labelled failure evidence packet. It keeps DNS work, sender configuration, and receiver evidence tied to the same failed transaction. - Visible From domain: the domain in the message's `From:` header. - SPF envelope domain and result: `smtp.mailfrom`, `smtp.helo` when present, and the SPF result. - DKIM domain, selector, and result: `header.d`, `header.s`, and the reported DKIM result. - DMARC disposition and alignment result: `header.from`, the DMARC result, and any reported disposition. - DNS owner names checked: the owner responsible for the SPF identity, DKIM selector record, and `_dmarc` record. - Message ID and time: the Message-ID and UTC timestamp for the failed message. - Sender and application: the application, ESP, stream, region, and outbound gateway used. - SMTP response: the complete provider response, including its exact text and subcode, when the message was rejected during SMTP. This illustrative fragment is redacted and shows three separate identities: ```text Authentication-Results: receiver.example; spf=pass smtp.mailfrom=returns.example.net; dkim=pass header.d=mailer.example.net header.s=s1; dmarc=fail header.from=example.com ``` SPF and DKIM may pass while DMARC fails because their passing domains are `returns.example.net` and `mailer.example.net`, while the visible From domain is `example.com`. [DMARC requires identifier alignment](https://www.rfc-editor.org/rfc/rfc9989.html) between the visible From domain and at least one passing SPF or DKIM identifier. The result does not mean every domain in the message failed. ![Decision flow for routing trusted message evidence to DNS publication, DKIM signing, identifier alignment, or separate SMTP policy investigation](/images/editorial/email-authentication-failure/email-authentication-failure-diagnostic-router.webp "1200x906") *Source: Palisade.* The [DMARC learning hub](/learning/dmarc) explains how SPF, DKIM, and DMARC work together. This guide focuses on assigning a reported failure to the layer that can actually resolve it. ## What usually causes it? ### The receiver evaluated a different SPF identity [SPF evaluates the MAIL FROM identity and, when needed, the HELO identity](https://www.rfc-editor.org/rfc/rfc7208.html). The visible From address can use `example.com` while a sending service uses `returns.example.net` as its envelope sender. An SPF record for `example.com` does not authorize a production IP for `returns.example.net`. A temporary result needs a same-path retry and DNS investigation before changing the record. SPF authorization does not determine a receiver's final delivery decision. ### The SPF result code points at a different fix [RFC 7208](https://www.rfc-editor.org/rfc/rfc7208.html) defines several distinct SPF results, and they mean very different things: - **pass**: the sending IP is authorized. Nothing to fix. - **fail** (hardfail): the IP is explicitly not authorized. A record ending in `-all` produces it, and receivers are entitled to reject the message. The [`-all` vs `~all` distinction](/learning/spf-hardfail-vs-softfail) decides which of the next two results a non-matching IP earns. - **softfail**: the IP is probably not authorized, but the domain is not asserting it firmly. A record ending in `~all` produces it. Mail is usually accepted but marked suspicious. - **neutral**: the domain explicitly takes no position (`?all`). Receivers treat it the same as having no SPF record at all. - **none**: the domain publishes no SPF record, or none could be found. - **permerror**: a permanent error in the record itself: broken syntax, [more than one SPF record](/learning/how-many-spf-records-per-domain), or [too many DNS lookups](/learning/how-do-i-fix-spf-permerror-too-many-dns-lookups). The check cannot complete until the record is fixed. - **temperror**: a transient DNS problem, such as a timeout. It usually resolves on its own. ![An SPF record ending in ~all (softfail)](/images/figures/spf-record-softfail-example.webp "1200x384") *Source: Palisade.* A duplicate record is a common `permerror` cause. A domain may publish [only one SPF TXT record](/learning/how-many-spf-records-per-domain). When two exist, often one left behind by a previous provider, the result is a `permerror` for all of the domain's mail. Merge everything into a single `v=spf1` record. ### The DKIM selector record or signing path is wrong [DKIM signatures name the signing domain with `d=` and selector with `s=`](https://www.rfc-editor.org/rfc/rfc6376.html). The receiver looks up the selector-specific public key. A lookup for a guessed selector, or for the visible From domain instead of the signed domain, does not test the failed signature. A missing public key, an active private key that does not match the published key, or a body change after signing can cause DKIM failure. If the receiver reports a body-hash mismatch, the responsible post-signing hop is an inference until raw message copies or controlled tests isolate it. ### Passing identifiers do not align with the visible From domain A third-party sender can pass SPF for its own return-path domain and DKIM for its own signing domain. DMARC still fails when neither passing identifier aligns with `header.from`. The repair is normally an aligned custom MAIL FROM domain, an aligned DKIM signing domain, or a sender configuration change. The [email authentication checker guide](/tools/email-security-score) describes why DNS, vendor status, message headers, and DMARC reports are separate evidence layers. ### The message passed authentication but hit a separate receiver policy A `5.7.x` SMTP response can concern authentication, but it can also concern recipient policy, TLS, content, reputation, volume, or a local administrator rule. Preserve the complete response. Unless the provider's response explicitly identifies authentication as the cause, concluding that authentication caused the rejection is an inference. Changing SPF, DKIM, or DMARC does not repair an invalid recipient, prohibited attachment, reputation decision, or private inbound rule. ## How do I diagnose the failure? ### 1. Preserve the exact failed transaction Save the raw source or complete SMTP response for one failed message. Record the evidence packet fields before making DNS changes. Keep an access-controlled original for byte-level work. Redact recipient addresses, message content, tokens, and customer data before sharing evidence. A manually sent message from another mailbox does not reproduce a failure from a billing platform, CRM, or transactional sender. ### 2. Identify the trusted result and each evaluated identity Find the receiver-added `Authentication-Results` header. Record the method result beside the identity it evaluated. ```text SPF: result and smtp.mailfrom or smtp.helo DKIM: result and header.d plus header.s DMARC: result, header.from, and aligned pass if present SMTP: complete response text and provider subcode ``` Do not treat a copied authentication header as trusted outside the trust boundary defined by RFC 8601. For a rejection without a delivered message, begin with the full SMTP response and the sender's transaction logs. ### 3. Check only the DNS name named by the evidence For SPF, inspect the exact MAIL FROM or HELO domain. For DKIM, inspect the DNS name formed from the failed message's selector and signing domain. ```text selector1._domainkey.yourdomain.com ``` This is illustrative only. Use the `s=` and `d=` values from the failed message, not this example. For DMARC, inspect `_dmarc.<visible-from-domain>`. Run the visible From domain through the [Email Security Score](/tools/email-security-score) after preserving the failed-message identities. Its public checks can identify a published DNS gap. They cannot prove the sender used the corresponding private key, that the live IP followed the SPF path, what a receiver saw at failure time, or why one receiver made a private delivery decision. ### 4. Assign the failure to the right owner The DNS owner publishes the record. The sender-service owner enables signing or configures the custom return path. The gateway owner removes a confirmed post-signing modification. The application owner selects the authenticated From domain and sending route. Document the owner beside each DNS name and sender setting. This avoids republishing a correct DKIM key while the production service continues to sign with a different selector. ### 5. Reproduce the same production path Send a new message through the same application, stream, region, visible From domain, envelope sender, outbound gateway, and recipient path. Inspect trusted headers from the receiving mailbox. Change one scoped setting at a time. A changed result after one controlled change is stronger evidence than several unrelated DNS edits. ## How do I fix it? ### Repair a DNS publication failure When the failed result identifies a missing, malformed, or incorrect SPF, DKIM, or DMARC DNS record, obtain the exact value from the sender service or the approved DNS change record. Publish it at the exact owner name identified in the evidence packet. For SPF, publish one SPF policy record for an identity and account for DNS lookup limits defined by [RFC 7208](https://www.rfc-editor.org/rfc/rfc7208.html). If lookup-limit maintenance is required, reduce or consolidate documented includes only after confirming the actual production senders. Do not add a second SPF TXT record. > Do not replace an account-generated DKIM selector, CNAME target, or token with an example value. The sending service generates the production value. This repair changes DNS publication. It does not prove that the sender has started using the corrected record. ### Repair a DKIM signing failure When the record resolves but the message still reports DKIM failure, compare the active `d=` and `s=` values with the sender's verified configuration. Confirm the sender is using the expected signing domain and selector. For a body-hash failure, trace the path after signing. Move signing after a confirmed body-changing gateway, or remove the confirmed transformation. Do not change the DMARC policy for a DKIM signature problem. That changes enforcement, not signature verification. ### Repair an identifier alignment failure When SPF or DKIM passes but DMARC fails, compare each passing identity with `header.from`. Configure an aligned custom return-path domain, an aligned DKIM signing domain, or the sender's supported authenticated-domain setting. This repair changes identifier alignment. It does not guarantee inbox placement or override receiver-specific policy. ### Escalate a separate SMTP policy failure When the message authentication results pass or the provider response does not identify authentication, stop changing authentication records. Investigate the provider response, recipient policy, transport logs, content, TLS, or reputation evidence with the relevant owner. Do not weaken `p=` as an incident workaround. A DMARC policy change changes requested enforcement and reporting behavior. It does not correct an unauthorised sending IP, invalid DKIM signature, or private receiver decision. ## How do I validate the repair? Repeat the exact production path that failed. Validation has four layers: - DNS: query the authoritative DNS server and at least one public resolver for the corrected owner name. - Vendor: confirm the sending service reports the expected domain, return path, or DKIM status. - Message: inspect a newly delivered message's trusted `Authentication-Results` field. - DMARC: review aggregate reports after data accumulates for the same production sending source. ![Four validation layers for an email authentication repair: DNS, vendor configuration, trusted message headers, and DMARC aggregate reports](/images/editorial/email-authentication-failure/email-authentication-failure-validation-layers.webp "1200x829") *Source: Palisade.* A green vendor status is not a delivered-message check. A public lookup is not proof of private-key use or future receiver treatment. After the one-message diagnosis, an IT team or MSP may need a way to identify every production source that still fails authentication or alignment. Palisade's [DMARC Agent remediation guidance](https://docs.palisade.email/guides/fixing-authentication-issues/) uses DMARC aggregate-report findings to identify affected sending sources and create prioritized remediation tickets. It proposes the next policy step or security level for human review. It does not change DMARC policy automatically, reproduce a private receiver decision, or guarantee future delivery. ## Check the public email-authentication configuration Use the [Email Security Score](/tools/email-security-score) for the visible From domain after you have saved the failed-message evidence. Compare the public DNS findings with the exact SPF, DKIM, and DMARC identities from the production message. [Check the visible From domain](/tools/email-security-score) A public DNS check cannot prove that the same sender path authenticated, repair a DKIM signature, monitor later production changes, or explain an individual receiver's private decision. If the repair exposes an ongoing source-ownership or multi-domain monitoring gap, [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=email_authentication&utm_content=email-authentication-failure) to review DMARC aggregate-report evidence and the proposed remediation work with a human-controlled policy change. ## Sources and further reading - [RFC 8601: Authentication-Results header field](https://www.rfc-editor.org/rfc/rfc8601.html) - [RFC 7208: Sender Policy Framework](https://www.rfc-editor.org/rfc/rfc7208.html) - [RFC 6376: DomainKeys Identified Mail](https://www.rfc-editor.org/rfc/rfc6376.html) - [RFC 9989: Domain-based Message Authentication, Reporting, and Conformance](https://www.rfc-editor.org/rfc/rfc9989.html) - [Palisade guide to fixing authentication issues](https://docs.palisade.email/guides/fixing-authentication-issues/) ## Frequently asked questions ### Can SPF and DKIM pass while DMARC fails? Yes. SPF and DKIM can pass for domains that differ from the visible From domain. DMARC fails when neither passing identifier aligns with the `From:` domain under the DMARC alignment rule. ### Should I check the visible From domain or the SPF envelope domain? Yes, check both when SPF is involved. The visible From domain is the DMARC identity, while SPF evaluates the `smtp.mailfrom` or HELO identity recorded in the trusted receiver result. ### Does a passing DKIM DNS lookup prove DKIM is working? No. It proves that a public record is visible for the queried selector and domain. It does not prove the production sender used the matching private key, that the message survived unchanged after signing, or that the receiver accepted the signature. ### Will changing DMARC to `p=none` fix an authentication failure? No. Changing `p=` changes the domain's requested DMARC handling. It does not authorize an SPF sender, repair a DKIM signature, or create identifier alignment. ### What should I do if the SMTP rejection does not mention SPF, DKIM, or DMARC? Preserve the exact SMTP response and stop treating authentication as the proven cause. Investigate the provider-specific response, recipient policy, transport logs, TLS, content, or reputation evidence with the owner of that layer. --- # Email rejected per DMARC policy: how to fix the bounce Canonical: https://www.palisade.email/learning/email-rejected-per-dmarc-policy > Email rejected per DMARC policy means no aligned SPF or DKIM pass was found. Trace the sender, repair alignment, and retest the same path today. An `email rejected per DMARC policy` bounce means the receiving system did not find an SPF or DKIM pass aligned with the visible From domain, then applied a DMARC handling decision. Preserve the exact rejection, identify the application that sent the message, repair that sender's authentication or alignment, and resend through the same production path. Do not lower the DMARC policy to hide an unconfigured legitimate sender. ## Quick takeaways - DMARC passes when SPF or DKIM passes and the passing domain aligns with the visible From domain. - A DMARC `p=reject` record requests rejection, but the receiving system makes the final handling decision. - One returned bounce identifies one rejected message, not every application that sends using the domain. - An SPF pass for a third-party return-path domain can still leave DMARC failing. - A controlled delivered message with trusted authentication results is stronger evidence than a public DNS lookup. - A `550 5.7.0` response alone does not prove DMARC caused the rejection. ## What does the failure mean? [DMARC, defined in RFC 9989](https://www.rfc-editor.org/rfc/rfc9989.html), evaluates the domain in the visible From address, called the Author Domain. DMARC passes when SPF or DKIM passes for a domain that aligns with that Author Domain. One aligned pass is sufficient. The `p=reject` value is a domain owner's requested disposition, and a receiver can apply local policy when deciding how to handle a failing message. The bounce proves that one receiver rejected one message. It does not prove that every receiver will reject it, identify the application responsible, or show that the published DMARC record is wrong. The [DMARC learning hub](/learning/dmarc) explains the full evaluation model. These are illustrative, redacted examples. The returned bounce is rejection evidence. The `Authentication-Results` block is from a separate controlled message delivered to a mailbox. ```text Returned bounce: 550 5.7.1 Unauthenticated email from example.com is not accepted due to domain's DMARC policy. Controlled delivered test: Authentication-Results: mx.receiver.example; spf=fail smtp.mailfrom=bounce.marketing-tool.example; dkim=none header.d=marketing-tool.example; dmarc=fail (p=REJECT) header.from=example.com ``` The `spf`, `dkim`, and `dmarc` result tokens, plus properties such as `smtp.mailfrom`, `header.d`, and `header.from`, use the [Authentication-Results format in RFC 8601](https://www.rfc-editor.org/rfc/rfc8601.html). Read this field only when you trust the receiving authentication service that added it. A message can carry an untrusted or forged copy. ![DMARC repair sequence showing how to preserve rejection evidence, identify the sender, test alignment, repair authentication, and validate the same path](/images/editorial/email-rejected-per-dmarc-policy/dmarc-repair-sequence.svg "1200x861") *Source: [RFC 8601: Message Authentication-Results](https://www.rfc-editor.org/rfc/rfc8601.html), checked 2026-08-12.* A `550 5.7.0` response alone does not identify DMARC as the cause. [RFC 3463 defines X.7.0 as an undefined security status](https://www.rfc-editor.org/rfc/rfc3463.html), while [RFC 7372 defines more specific email-authentication status codes](https://www.rfc-editor.org/rfc/rfc7372.html). Keep the complete diagnostic text and reporting host. Google documents `550-5.7.26` as an unauthenticated-mail rejection example in its [Gmail sender guidelines](https://support.google.com/mail/answer/2451690). Microsoft documents that Exchange Online can apply a sender's published DMARC policy during SMTP in its [DMARC configuration guidance](https://learn.microsoft.com/en-us/defender-office-365/email-authentication-dmarc-configure). These examples do not predict every receiver's response. ## What usually causes it? ### A legitimate sender has no aligned authentication pass A marketing platform, CRM, help desk, or transactional service can use your visible From domain while using its own envelope sender and DKIM signing domain. In the illustrative header, SPF fails for `bounce.marketing-tool.example` and DKIM is absent. Neither result supplies an aligned pass for `example.com`. Confirm the application and outbound route before changing DNS. [Why DMARC fails and how to fix it](/learning/why-dmarc-fails-how-to-fix-it) explains why a passing authentication result can still fail DMARC alignment. ### DKIM passes for an unaligned signing domain A `dkim=pass` result is insufficient by itself. The passing `header.d` domain must align with the visible From domain under the domain's DMARC alignment mode. This follows from the [DMARC alignment rules in RFC 9989](https://www.rfc-editor.org/rfc/rfc9989.html). It does not prove that a particular sending service lacks support for domain authentication. ### SPF passes for an unaligned envelope sender SPF evaluates the SMTP envelope sender domain, exposed as `smtp.mailfrom` in a trusted Authentication-Results field. A service can pass SPF for its own return-path domain while the visible From address uses your domain. DMARC still fails unless DKIM supplies an aligned pass. Do not add a service to SPF based on a bounce alone. Confirm that the service sent the rejected production path, then use that provider's current account-specific instructions for an authenticated return path or DKIM domain. ### An indirect mail flow changed the message path Forwarding can break SPF because the receiver evaluates the forwarding server's IP address. An aligned DKIM signature can preserve DMARC through an unmodified indirect flow, but message changes by a list or intermediary can invalidate that signature. [RFC 7960 explains these indirect-mail limitations](https://www.rfc-editor.org/rfc/rfc7960.html). This remains an inference until you compare the original route with the forwarded or list-processed route. ### The rejected message was spoofed If sender logs and DMARC reports do not identify the IP, application, or platform as an authorized source, the rejected message may be spoofed. In that case, rejection can be the expected result of enforcement. Changing policy reduces the domain's requested protection without repairing a legitimate sender. For help interpreting other returned-mail symptoms, see [Bounce-back email: how to read the error and fix the cause](/learning/bounce-back-email). ## What about "554 5.7.5 Permanent Error Evaluating DMARC Policy"? Some receivers return a `554` response instead of a `550` when DMARC evaluation fails: ```text 554 5.7.5 Permanent Error Evaluating DMARC Policy ``` `554 5.7.5` means the receiver queried `_dmarc.<your-domain>` and could not turn the answer into a policy. The record was unparseable or ambiguous. That is a policy *discovery* failure rather than an authentication result, so a message can draw this response while SPF and DKIM both pass. It is not an authentication verdict at all: [RFC 3463](https://www.rfc-editor.org/rfc/rfc3463) registers `X.7.5` as "Cryptographic failure", so this string is a receiver's non-standard reuse of a code that means something else. Preserve the exact response, then check the record itself before changing anything else. ### A DMARC record the receiver cannot resolve Publish exactly one DMARC record at `_dmarc`. When two TXT records exist there, policy discovery returns no usable record and receivers can return this permanent-error response even though each record looks valid on its own. Query the label directly to see what the receiver sees: ```text dig +short TXT _dmarc.example.com ``` Exactly one line should come back, and it should start with `v=DMARC1`. Two lines is the common cause. No line at all is a different situation: a domain that publishes no DMARC record is skipped rather than rejected, so look at the recipient-side policy below. A single record still fails to parse when it omits the policy tag or carries stray characters. Start with `v=DMARC1`, specify the policy with `p=` (`none`, `quarantine`, or `reject`), and remove characters left by manual entry or a copy-paste mistake. This record fails because of the trailing tag: ```text v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; extra-character=!; ``` Remove the invalid `extra-character=!;` entry, republish, and validate the record before resending. ### A recipient-side policy The receiving server applies its own rules for handling mail that fails authentication, and those rules can reject or quarantine a message independently of your published record. When one recipient domain keeps rejecting repaired mail, work with that recipient to understand how its policies evaluate the message and align your authentication settings accordingly. ### What this response does not tell you A misconfigured SPF or DKIM record does not produce `554 5.7.5`. It produces an ordinary DMARC failure and one of the `550` responses covered above. If the record at `_dmarc` resolves and parses and mail is still rejected, the problem is the alignment failure described earlier on this page, not this one. You will still need the record syntax to make that repair. An SPF record is a DNS TXT record that looks like this: ```text v=spf1 ip4:192.0.2.0/24 ip4:198.51.100.0/24 include:example.com -all ``` The `ip4:` mechanisms authorize address ranges, `include:` pulls in another domain's authorized senders, and [`-all` marks every other source as a hard fail](/learning/glossary/spf-all-qualifier). A DKIM public key is published under a [DKIM selector](/learning/glossary/dkim-selector): ```text thirdparty._domainkey.example.com IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCS..." ``` Use the selector and key generated by your own sending service, not this example. ## What about "DMARC unauthenticated mail is prohibited"? "DMARC unauthenticated mail is prohibited" is a third wording for the same rejection: the receiver found no aligned SPF or DKIM pass and applied the published DMARC policy. Google states the same refusal as a `550-5.7.26` response, and that is the wording senders most often paste into a search box: ```text 550-5.7.26 Unauthenticated email from example.com is not accepted due to domain's DMARC policy. Contact the administrator of example.com domain if this was legitimate email. To learn about the DMARC initiative, go to Control unauthenticated email from your domain. ``` Microsoft and several appliance vendors return the "unauthenticated mail is prohibited" phrasing instead. The response code differs and the sentence differs, but the cause does not. Unauthenticated mail here means mail that carries no authentication result the receiver can tie back to the domain in the visible `From:` header, not mail that failed a spam check. Treat it exactly like the `550 5.7.1` case above. Preserve the response, identify the sending service, then check alignment before changing anything in DNS. For the Google response code on its own, including the full text Gmail returns and the retry behaviour, see [SMTP error 550 5.7.26](/learning/smtp-error-codes/550-5-7-26). ## How do I diagnose the failure? ### 1. Preserve the complete returned bounce Save the complete bounce, reporting host, SMTP status, timestamp, visible From domain, recipient domain, and diagnostic text. Match it to sender logs using the Message-ID, recipient, and sending time where available. Build a labelled evidence packet before editing DNS or vendor settings: ```text Illustrative redacted rejection evidence packet Visible From domain: example.com SPF envelope domain/result: bounce.marketing-tool.example / fail DKIM d=/selector/result: marketing-tool.example / selector1 / none DMARC result/disposition: fail / p=REJECT Exact recipient response: 550 5.7.1 Unauthenticated email from example.com is not accepted due to domain's DMARC policy. Message ID/time: <redacted-message-id> / 2026-08-12T10:15:00Z Sender application: marketing platform ``` If the response says `550 5.7.1`, retain its exact wording. The [broad 550 5.7.1 variant guide](/learning/smtp-error-codes/550-5-7-1) shows how to distinguish DMARC wording from relay, blocklist, recipient-policy, and content-policy refusals. ### 2. Identify the exact production sender Determine which application, ESP, gateway, or user submitted the message. Record the visible From domain, envelope sender, outbound relay or IP, DKIM selector, and branded-domain configuration. Do not identify the application from the display name. One domain can be used by several independent systems with separate SPF, DKIM, and return-path settings. ### 3. Read a controlled delivered message Send a controlled message through the same application, authenticated domain, template type, outbound route, and recipient provider where practical. Deliver it to a mailbox you control that exposes full headers. Compare the visible From domain with the SPF `smtp.mailfrom` domain and any passing DKIM `header.d` domain in the trusted receiver-added Authentication-Results field. This identifies the branch to repair: - Authentication failure: SPF and DKIM both fail or are absent. Repair the confirmed sender's authentication setup. - Alignment failure: SPF or DKIM passes, but its passing domain does not align with the visible From domain. Configure the sender's authenticated return path or DKIM signing domain. - Receiver decision: DMARC fails and the receiver rejects, quarantines, or accepts the test. The domain policy is a request, not a guarantee of identical treatment across receivers. ![Decision flow for reading a DMARC rejection, comparing the visible From domain with SPF and DKIM domains, and selecting the narrowest repair](/images/editorial/email-rejected-per-dmarc-policy/email-rejected-per-dmarc-policy-diagnosis-flow.webp "1200x980") *Source: Palisade.* ### 4. Check the published DMARC policy separately Look up the From domain's DMARC record after you preserve the message evidence. Confirm the domain being checked is the exact visible From domain or its applicable organizational domain. Record `p=`, `adkim=`, and `aspf=` if they are present. A public record result shows current DNS publication. It does not prove that the application signs mail, uses the configured return path, or produced the rejected message. ## How do I fix it? ### Configure the confirmed sender's aligned DKIM domain When the application supports custom DKIM signing, configure the domain it provides in its account settings and publish the account-generated DNS records. Then complete the provider's verification process. > Do not publish selectors, CNAME targets, tokens, or hostnames copied from another account. Use only values generated for your own domain and tenant. This repair changes authentication and alignment. It does not alter DMARC enforcement. ### Configure an authenticated return path when SPF is the aligned path When the sender supports a custom return path, publish its account-generated DNS records and confirm that the envelope sender uses the authenticated subdomain. Then send a new message and compare the resulting `smtp.mailfrom` domain with the visible From domain. An SPF include can authorize infrastructure, but it does not by itself make a third-party envelope domain align with your visible From domain. ### Repair the signing or routing order for indirect mail If a forwarder, list, or gateway changes the message after signing, determine whether the change can occur before aligned DKIM signing or whether the route can avoid the modification. Test one controlled route at a time. Do not treat forwarding as proof that the sender configuration is correct. Forwarding and message modification are separate conditions under [RFC 7960's indirect-mail guidance](https://www.rfc-editor.org/rfc/rfc7960.html). ### Keep an enforcement change separate from the repair Do not lower `p=reject` as the technical fix. Changing `p=` changes the domain's requested DMARC handling, not the sender's SPF result, DKIM signature, or domain alignment. If an incident requires a temporary policy decision, document it separately, limit its duration, and continue repairing the identified sender. ## How do I validate the repair? To validate a DMARC rejection repair, repeat the same production path: the same application, visible From domain, template, recipient provider, and routing conditions. A successful DNS lookup is only the first validation layer. Check each applicable layer: - DNS: [query the domain's published records](/tools/dns-lookup) through the authoritative DNS provider and at least one public resolver. - Vendor: confirm the sender's current domain-authentication or verification status in its own interface. - Message: send a new message and inspect the trusted receiver-added Authentication-Results field for an SPF or DKIM pass aligned with the visible From domain. - DMARC: after reports accumulate, confirm that the repaired source appears as expected in DMARC aggregate-report data. Keep the passing raw message and the previous failed evidence together. A green vendor status is not proof that the exact production route produced an aligned pass. ## Find every sender that still fails DMARC alignment Check the domain's published policy before making another change. [Check your domain's DMARC record](/tools/dmarc) The checker inspects the published record and SPF/DKIM posture. It cannot prove why one specific receiver rejected one specific message, does not monitor continuously, and does not guarantee future inbox placement. After one sender is aligned, the remaining question is which other production sources still fail alignment. Palisade's DMARC Agent analyzes incoming DMARC aggregate-report data, identifies sending sources and authentication or alignment issues, and creates prioritized remediation tickets. Your team reviews the evidence and applies the fix. Palisade does not change your DNS or DMARC policy automatically, does not control receiver-side handling, and does not guarantee delivery. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=dmarc_troubleshooting&utm_content=email-rejected-per-dmarc-policy) ## Sources and further reading - [RFC 9989: Domain-based Message Authentication, Reporting, and Conformance](https://www.rfc-editor.org/rfc/rfc9989.html) - [IANA SMTP enhanced status code registry](https://www.iana.org/assignments/smtp-enhanced-status-codes/) — registers `X.7.5` as a cryptographic failure, which `554 5.7.5` reuses for a different meaning. - [RFC 8601: Authentication-Results header field](https://www.rfc-editor.org/rfc/rfc8601.html) - [RFC 7960: Interoperability issues between DMARC and indirect email flows](https://www.rfc-editor.org/rfc/rfc7960.html) - [RFC 3463: Enhanced mail system status codes](https://www.rfc-editor.org/rfc/rfc3463.html) - [Gmail sender guidelines](https://support.google.com/mail/answer/2451690) - [Microsoft Exchange Online DMARC configuration guidance](https://learn.microsoft.com/en-us/defender-office-365/email-authentication-dmarc-configure) ## Frequently asked questions ### What does "554 5.7.5 Permanent Error Evaluating DMARC Policy" mean? `554 5.7.5 Permanent Error Evaluating DMARC Policy` means the receiver queried `_dmarc.<your-domain>` and could not turn the answer into a policy. Check the record first: two TXT records at `_dmarc`, a missing `v=DMARC1`, or stray characters all stop discovery. A recipient-side policy is the other cause. Misconfigured SPF or DKIM records do not produce this response; they produce an ordinary DMARC failure and a `550`. ### Does `p=reject` mean every receiver will reject my email? No. `p=reject` requests rejection for DMARC-failing mail, but RFC 9989 allows each receiver to apply its own local handling. A receiver can accept, reject, quarantine, or filter a message using its own policy. ### Can SPF pass while DMARC fails? Yes. SPF can pass for the envelope sender domain while the visible From address uses a different domain. DMARC requires the passing SPF domain to align with the visible From domain, unless aligned DKIM supplies the DMARC pass. ### Does `550 5.7.0` prove a DMARC rejection? A `550 5.7.0` response does not by itself prove a DMARC rejection. RFC 3463 defines `X.7.0` as an undefined security status. Keep the full SMTP response and inspect a controlled delivered test before attributing the rejection to DMARC. ### Should I change my DMARC policy to `p=none`? No. Changing to `p=none` removes the domain's DMARC-specific enforcement request but does not repair SPF, DKIM, alignment, or the sender configuration that caused the rejection. ### Can forwarding cause email to be rejected per DMARC policy? Yes. Forwarding can cause SPF to fail because the forwarding server's IP is evaluated. An aligned DKIM signature can preserve DMARC only while the message remains unmodified, so compare the original and forwarded paths before changing the sender configuration. --- # Email security for small business: what actually matters first Canonical: https://www.palisade.email/learning/email-security-for-small-business > The working order for small business email security: MFA first, then the controls Microsoft 365 and Google Workspace already include, then DMARC. Turn on multi-factor authentication first. CISA, NSA, FBI, and MS-ISAC name strong MFA as the best step a small business can take to protect its internet-facing accounts against phishing. Next, switch on the anti-phishing settings your Microsoft 365 or Google Workspace subscription already includes, keep software updating itself, and then authenticate your own domain with SPF, DKIM, and DMARC. A paid email security product is a later decision, not a first one. ## Quick takeaways - MFA on every account, administrators first, is the highest-value hour a small team spends on email. - Microsoft 365 and Google Workspace already run spoof detection, attachment scanning, and link warnings on every mailbox. - SPF, DKIM, and DMARC protect whoever receives mail claiming to be from you, and Google requires them from bulk senders. - DMARC stops exact-domain spoofing only, so lookalike domains and forged display names stay a people problem. - Buy an add-on when you can name the message your current settings let through, not before. ![Small business email security controls in working order](/images/editorial/email-security-for-small-business/email-security-for-small-business-controls-order.webp "1200x925") *Source: Palisade.* ## What your mail platform already includes Before pricing anything, find out what you own. Microsoft's [anti-phishing protection documentation](https://learn.microsoft.com/en-us/defender-office-365/anti-phishing-protection-about) says every cloud mailbox gets spoof intelligence, tunable anti-phishing policies, an option to honor the sending domain's DMARC policy when a message is detected as spoof, and implicit email authentication that adds sender reputation and behavioral analysis to the SPF, DKIM, and DMARC results. Impersonation protection, mailbox intelligence, and Campaign Views sit in Defender for Office 365, the paid tier above that baseline. Google Workspace ships the same job as admin settings rather than a separate product. Google's [advanced phishing and malware protection](https://knowledge.workspace.google.com/admin/gmail/advanced/advanced-phishing-and-malware-protection) covers attachments (encrypted files, malicious scripts, unusual types), links and external images (shortened URLs, linked images, clicks through to untrusted domains), and spoofing and authentication (visually similar domains, employee name impersonation, unauthenticated mail). Most default to keeping the message in the inbox with a warning, so the protection is on but quiet, and the stricter actions are still an unmade decision. That is why the honest first answer to "which email security product should we buy" is usually "none, for now". Work this order instead. ## The order to work in when nobody owns IT full time ### 1. Turn on multi-factor authentication, administrators first [CISA, NSA, FBI, and MS-ISAC's phishing guidance](https://www.cisa.gov/sites/default/files/2025-03/Phishing%20Guidance%20-%20Stopping%20the%20Attack%20Cycle%20at%20Phase%20One%20508.pdf) puts activating strong MFA at the top of what small businesses should do, because a stolen password stops being enough on its own. Start with the accounts that can change everything else: the Microsoft 365 or Google Workspace admin, the DNS registrar, and the finance and payroll logins. The same guidance is specific about weak MFA: push approval without number matching can be worn down by repeated prompts until someone taps approve, and SMS or voice codes fall to a carrier being talked into moving the number. The UK National Cyber Security Centre's small business guide now leads with passkeys where a service offers them, and two-step verification elsewhere. **Effort:** an afternoon for a team of twenty, most of it walking people through enrollment. **Cost:** included in every Microsoft 365 and Google Workspace plan. ### 2. Switch on the protection you are already paying for Open both consoles and read the current settings against the lists above. In Microsoft 365 that means the anti-phishing policy, the spoof intelligence insight, unauthenticated sender indicators in Outlook, and the setting that honors a sender's `p=quarantine` or `p=reject` policy. In Google Workspace it means deciding, per protection group, where a warning banner is enough and where the message should be quarantined. Change one group at a time and watch it for a week. Quarantining a category that carries a real supplier's invoices is what makes a team switch everything back off. **Effort:** about an hour per console, plus a week of watching. **Cost:** included. ### 3. Let software update itself, and block the known-bad destinations Phishing works when the click lands somewhere. The federal guidance asks small businesses to set applications to update automatically, run anti-virus so an opened attachment cannot execute, restrict high-risk file types such as `.exe` and `.scr` on standard accounts, and put DNS filtering or firewall denylists in front of known malicious sites. It names free tools for the DNS layer when there is no budget. None of it is email-specific, which is the point: it catches the click your filter missed. **Effort:** a morning to configure, then close to zero. **Cost:** update policies and anti-virus are included; DNS filtering has free tiers. ### 4. Authenticate your own domain with SPF, DKIM, and DMARC The first three steps protect your people from inbound mail. This one protects everyone who receives mail claiming to come from you, and it is now a delivery requirement. Google's [email sender guidelines](https://support.google.com/a/answer/81126) require SPF or DKIM from every sender, valid forward and reverse DNS, a TLS connection, and spam complaints below 0.3%. Senders of 5,000 or more messages a day to Gmail accounts also need a DMARC record (a policy of `none` meets the minimum), a From domain aligned with the SPF or DKIM domain, and one-click unsubscribe on marketing mail. Unauthenticated mail can be rejected with a `5.7.26` error. Publish a monitoring record first, so you see who sends as you before anything is blocked: ```text _dmarc.yourdomain.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com" ``` Read the reports until every legitimate sender passes and aligns, then move to `quarantine` and finally `reject`, which is where the federal guidance says outbound DMARC should end up. [How DMARC works](/learning/what-is-dmarc) covers the alignment mechanism doing the actual work. Report reading is what stalls small teams, because aggregate reports arrive as compressed XML from dozens of receivers. Run the free [email security score check](/tools/email-security-score) to see which records your domain publishes today. Palisade is DMARC automation for the step after that: the agent reads the reports, identifies each sender, drafts the SPF and DKIM fixes, and proposes each policy move for you to approve. The [Palisade documentation](https://docs.palisade.email/) scopes the product to authentication and DMARC compliance, so it sits beside your platform's inbound filtering rather than replacing it. **Effort:** under an hour to publish the records, then a few weeks of report reading before enforcement. **Cost:** DNS changes are free. ### 5. Give people somewhere to report, then keep the training short The federal guidance asks for an anti-phishing training program reviewed annually, with a check that people retained it, and points small businesses at free NIST and FTC material. Pair that with a report button that lands in a mailbox somebody reads. A report route nobody monitors is not a control. Teach the two patterns that survive good filtering: a payment or bank detail change requested by email, and an urgent request from a name people recognize. Both are covered in [what phishing is and how it works](/learning/what-is-phishing). **Effort:** recurring, roughly 20 minutes per person per year, plus an owner for the queue. **Cost:** free material exists. ### 6. Back up what your mail holds, and test one restore The NCSC small business guide leads with backups and asks you to prove the data can be restored, not just that a backup ran. Mailboxes hold contracts, invoices, and the only copy of plenty of decisions, and ransomware arrives through that same inbox. **Effort:** half a day to set up, an hour a quarter to test a restore. **Cost:** low, and lower than the first incident. ## What email authentication does not cover DMARC is narrower than it is usually sold as. [RFC 9989](https://www.rfc-editor.org/rfc/rfc9989.html#section-2.2) states that DMARC does not attempt to solve all fraudulent email, and specifically that it does not address visually similar domain names, known as cousin domains, or abuse of the display name in the From header. So `acme-billing.com` sending mail about your invoices passes its own authentication checks and arrives, as does a message carrying your CEO's name with a free webmail address behind it. Those are caught by the impersonation settings in step 2, the reporting path in step 5, and a rule that no bank details change on the strength of an email. ## What to skip while you are still small - **A separate secure email gateway**, until you have used the settings you already own. [How email security gateways work](/learning/email-security-gateway) explains what the extra hop buys and what it costs in mail flow complexity. - **Phishing simulation platforms**, until there is a monitored queue to report into. A click rate with no response path measures nothing you can act on. - **Data loss prevention and log management projects**, which need an owner with weekly time or they become shelfware with a subscription attached. - **Lookalike domain monitoring**, until your own domain is at `p=reject`. Stop the spoofing you can stop for free first. ## When a paid add-on earns its place Buy when you can point at what your setup missed: a phishing message that reached an inbox with no policy covering it, an archiving obligation the platform does not meet, or mailboxes split across platforms with no single console. Growth alone is not a signal, and neither is a renewal quote. ## Sources and further reading - [Phishing Guidance: Stopping the Attack Cycle at Phase One](https://www.cisa.gov/sites/default/files/2025-03/Phishing%20Guidance%20-%20Stopping%20the%20Attack%20Cycle%20at%20Phase%20One%20508.pdf), CISA, NSA, FBI, and MS-ISAC. - [Anti-phishing protection in Microsoft 365](https://learn.microsoft.com/en-us/defender-office-365/anti-phishing-protection-about), Microsoft. - [Advanced phishing and malware protection](https://knowledge.workspace.google.com/admin/gmail/advanced/advanced-phishing-and-malware-protection), Google Workspace. - [Email sender guidelines](https://support.google.com/a/answer/81126), Google. - [RFC 9989](https://www.rfc-editor.org/rfc/rfc9989.html), the DMARC specification. ## Frequently asked questions ### What is the first email security control a small business should turn on? Multi-factor authentication, starting with administrator accounts. The federal phishing guidance names activating strong MFA as the best step a small business can take for its internet-facing accounts, and it costs nothing beyond the plan you already pay for. Prefer passkeys or an authenticator app over SMS codes. ### Does Microsoft 365 include phishing protection without buying Defender? Yes. Microsoft documents spoof intelligence, anti-phishing policies, unauthenticated sender indicators, and implicit email authentication as present for all cloud mailboxes. Defender for Office 365 adds impersonation protection, mailbox intelligence, Campaign Views, and attack simulation training. Configure the included layer and see what still gets through before paying for the upper tier. ### Do small businesses need an email security gateway? Not usually, and not first. A gateway adds a hop in front of Microsoft 365 or Google Workspace, and both already filter, scan attachments, and warn on links. The case strengthens when a message the built-in settings had no policy for reaches an inbox, or when mailboxes live on two platforms. ### Does DMARC stop someone spoofing a lookalike domain? No. RFC 9989 says DMARC does not address visually similar cousin domains or abuse of the From header display name. It stops mail that forges your exact domain in the From address. Lookalike domains and display name tricks are handled by impersonation settings, a reporting path people use, and an out-of-band check before any payment detail changes. --- # What is an email warmup API? Canonical: https://www.palisade.email/learning/email-warmup-api > An email warmup API controls a provider's warmup process. Learn what its status can show and which production evidence it cannot replace. An email warmup API is a provider interface for creating, starting, stopping, or reading that provider's warmup process. It can automate a dedicated IP's warmup state or report provider-side activity, depending on the product. Its status does not prove that a real campaign authenticates correctly, reaches wanted recipients, or lands in an inbox. Treat API status as process evidence, then verify the production sending path separately. ## Quick takeaways - A warmup API controls or reports a provider's process, not a mailbox provider's final placement decision. - Dedicated-IP warmup APIs manage volume limits for a particular sending IP. - Mailbox-network warmup is a separate product mechanism from a dedicated-IP ramp. - Verify a real message's authentication and receiver feedback outside the warmup API. - A public-domain check can reveal authentication gaps, but it cannot validate API activity or inbox placement. ## What can an email warmup API control? The exact operations are provider-specific. [Mailgun's IP Address Warmup API documentation](https://documentation.mailgun.com/docs/mailgun/api-reference/send/mailgun/ip-address-warmup) documents lifecycle operations for dedicated-IP warmup plans. [Twilio SendGrid's IP-warmup endpoint](https://www.twilio.com/docs/sendgrid/api-reference/ip-warmup/start-warming-up-an-ip-address) puts a dedicated IP into warmup mode, while SendGrid documents that its warmup process limits mail volume by hour according to how long the IP has been warming up. That makes an API useful for automation: an integration can request a provider action and retain the provider's response as an operational record. It does not make the API a universal email-deliverability test. For the separate mechanism of connected-mailbox activity, see [automated email warmup](/learning/email-warmup-service). For a real-mail ramp, see [an email warmup schedule](/learning/email-warmup-schedule). ## What does API status prove? An API response can show that the provider accepted a warmup request or reports a state for the resource it manages. It cannot, by itself, establish recipient consent, real-message authentication, complaints, or a future inbox result. That boundary is an inference from the scope of the documented API operations and the separate sender controls Gmail requires for delivery. [Google's email sender guidelines](https://support.google.com/mail/answer/81126?hl=en) require SPF or DKIM for all senders to personal Gmail accounts. Senders of more than 5,000 messages per day must also set up SPF, DKIM, and DMARC. Those requirements concern the real sending domain and message path, not whether a provider reports a warmup state. [Email deliverability](/email-deliverability) includes both successful delivery and inbox placement, which is why provider process status and production evidence must stay separate. ## API scope and production evidence Use this boundary when a vendor proposes a warmup integration. The left side is evidence about the provider-managed process. The right side is evidence you still need before drawing a conclusion about a real sending route. ![API scope and evidence card separating provider-controlled dedicated-IP warmup operations from the production-message evidence required for deliverability decisions.](/images/editorial/email-warmup-api/email-warmup-api-scope-and-evidence.svg "1200x627") *Source: Original Palisade deterministic evidence card based on [Mailgun's IP Address Warmup API documentation](https://documentation.mailgun.com/docs/mailgun/api-reference/send/mailgun/ip-address-warmup), [Twilio SendGrid's IP-warmup endpoint](https://www.twilio.com/docs/sendgrid/api-reference/ip-warmup/start-warming-up-an-ip-address), and [Google's email sender guidelines](https://support.google.com/mail/answer/81126?hl=en). It separates provider process evidence from production evidence and is not a vendor interface or inbox-placement model.* ```text Provider process evidence - Dedicated IP entered warmup mode - Provider-reported warmup state or limit Production evidence still needed - Authentication result from a delivered message - Recipient consent and campaign feedback - Receiver-side placement outcome ``` If production mail is already filtering, investigate the delivered message and sending practices rather than changing volume from an API response alone. ## How do you evaluate an email warmup API? ### 1. Name the resource the API controls Confirm whether the API manages a dedicated IP, a mailbox-network workflow, or another provider-owned object. Do not assume that an endpoint designed for a dedicated IP represents mailbox activity, or that a warmup-network signal represents your production campaign. ### 2. Record the provider result without overreading it Keep the request, response time, resource identifier, and provider-reported state in your own operational records. The useful conclusion is narrow: the provider says its managed process is in that state. It is not evidence that a recipient wanted a message or that a receiver placed one in the inbox. ### 3. Verify the production sender independently Check published SPF, DKIM, DMARC, and BIMI before treating warmup status as useful context. [What is DMARC?](/learning/what-is-dmarc) explains the policy and alignment layer that a warmup API does not configure or prove. Then send legitimate mail through the intended production path and review the resulting headers, delivery results, complaints, and receiver feedback. ## Check the sending domain before integrating a warmup API Before you compare provider status with production results, inspect the public authentication controls on the domain that will send the mail. The [Email Security Score](/tools/email-security-score) can review published SPF, DKIM, DMARC, and BIMI configuration so you can find a visible prerequisite gap. It cannot connect to a warmup API, read provider events, verify recipient consent, observe campaign volume, or determine future inbox placement. For recurring sender and alignment evidence after the public check, [Palisade's DMARC Agent guidance](https://docs.palisade.email/guides/fixing-authentication-issues/) describes an aggregate-report workflow that identifies sending sources and authentication or alignment issues for human-reviewed remediation. It does not operate a warmup provider, change DNS or DMARC policy automatically, or guarantee delivery. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=email_deliverability&utm_content=email-warmup-api) ## Sources and further reading - [Mailgun IP Address Warmup API](https://documentation.mailgun.com/docs/mailgun/api-reference/send/mailgun/ip-address-warmup) - [Twilio SendGrid: Start warming up an IP address](https://www.twilio.com/docs/sendgrid/api-reference/ip-warmup/start-warming-up-an-ip-address) - [Google: Email sender guidelines](https://support.google.com/mail/answer/81126?hl=en) ## Frequently asked questions ### Is an email warmup API the same as an inbox-placement API? No. A warmup API controls or reports the provider's warmup process. Inbox placement is a receiver-side outcome for a real message, so an API status does not establish it. ### Does an IP-warmup API authenticate my sending domain? No. A dedicated-IP warmup endpoint manages the provider's IP warmup process. You still need to configure and verify the authentication required for your actual sending domain and mail stream. ### Can API status replace a delivered-message check? No. API status can be useful operational context, but a delivered message and its receiver-added results are the relevant evidence for the production path you intend to use. ### Should I increase real campaign volume when the API says warmup is active? Not automatically. Compare the provider status with production authentication, recipient consent, delivery results, complaints, and engagement before changing a real-mail volume plan. ### Does an email security check validate the warmup integration? No. A public-domain check can inspect published authentication records. It cannot read API credentials, provider events, mailbox-network activity, campaign consent, or future placement. --- # Email warmup appsumo Canonical: https://www.palisade.email/learning/email-warmup-appsumo > AppSumo's Email Warmup listing is sold out. Learn what its historic claims mean and what to check on a real sending path. AppSumo's exact **Email Warmup** listing is marked **Sold out**, so it is not a current AppSumo deal to buy or configure. The page retains historic deal terms and seller descriptions, but those are context rather than evidence that a message from your sender will authenticate, be accepted, or reach an inbox. If you are evaluating a real sending concern, check the domain and a representative production message instead of relying on a historic listing. ## Quick takeaways - AppSumo currently labels its Email Warmup deal as sold out and unavailable. - The listing's lifetime-access terms describe the former deal, not a current purchase path. - Seller statements about warmup or reputation are historical product claims, not independent proof of delivery outcomes. - A warmup product cannot show the SPF, DKIM, or DMARC result of your production message unless you inspect that message. - Start with the actual sending domain and route when a campaign has a delivery or filtering symptom. ## Is the AppSumo Email Warmup deal available? [AppSumo's Email Warmup listing](https://appsumo.com/products/marketplace-email-warmup/) identifies the deal as **Sold out** and says it is unavailable. That is the direct answer for a search for email warmup AppSumo: the page is a record of a former offer, not a live setup or checkout path. The same listing preserves historic terms such as lifetime access, code redemption within 60 days of purchase, and plan features. Those details describe what AppSumo published for the former deal. They do not establish current access to the product, current pricing, or the status of any service outside AppSumo. ## What can the historic listing tell you? The listing includes seller descriptions about a network of email addresses, simulated positive behaviors, sender reputation, and delivery. Attribute those statements to the seller. The public AppSumo page does not test a sender's real campaign, publish receiver decisions, or document the authentication results for a message from your domain. ![Decision card separating a sold-out AppSumo listing and historic seller claims from the real sender and production-message evidence needed to assess delivery.](/images/editorial/email-warmup-appsumo/email-warmup-appsumo-status-evidence.svg "1200x572") *Source: Original Palisade deterministic decision card based on [AppSumo's Email Warmup listing](https://appsumo.com/products/marketplace-email-warmup/). It summarizes the listing's sold-out status and separates historic seller claims from production-message evidence. It does not reproduce an AppSumo interface or a mailbox-provider scoring model.* That boundary matters because warmup-network activity and a production campaign are different scopes of evidence. For the vendor-neutral mechanics, see [automated email warmup](/learning/email-warmup-service). For the wider question of a careful ramp of legitimate mail, see [does email warmup work?](/learning/does-email-warmup-work). Neither article turns an old listing into proof of inbox placement. ```text APPSUMO LISTING EVIDENCE CHECK Listing state: sold out and unavailable Historic content: former deal terms and seller product claims Not established: current access, SPF, DKIM, DMARC, recipient response, or inbox placement Next evidence: public domain configuration and a representative production message Decision: treat the listing as status context, not a delivery result ``` ## What should you check instead? ### 1. Confirm the real sending identity Use the domain and sending service that carry the mail you actually manage. Check the domain's public SPF, DKIM, and DMARC configuration before changing volume or paying for another tool. [Email deliverability](/email-deliverability) is an outcome from the sending and recipient path, not a result that an old product page can prove. ### 2. Inspect a representative production message Send a representative message through the same application, domain, and route as the affected campaign. Preserve the receiver-added authentication results, SMTP response, and any observable symptom. If a real message is filtering, use the evidence-led guide to [why outbound email goes to spam](/learning/why-do-your-emails-go-to-spam-and-how-can-you-fix-it) rather than treating a historic warmup offer as a diagnosis. ### 3. Change only what the evidence supports If the domain configuration or delivered message exposes a specific gap, correct that gap and retest the same route. Do not infer a filtering cause from the AppSumo listing's status or from the seller's historic product description. ## Check the public authentication baseline separately If you manage the sending domain, run an [Email Security Score](/tools/email-security-score) to review its public DNS configuration. Palisade says the score checks published DMARC, SPF, DKIM, BIMI, MX, MTA-STS, and TLS-RPT records. It is a useful baseline, but it cannot inspect the former AppSumo offer, a recipient mailbox, or the full path of a delivered message. If recurring production evidence identifies sender or alignment gaps, [Palisade's DMARC Agent remediation guide](https://docs.palisade.email/guides/fixing-authentication-issues/) describes using DMARC aggregate-report data to identify sending sources and authentication or alignment issues, then create prioritized remediation tickets for human review. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=sender_reputation&utm_content=email-warmup-appsumo) only after preserving the message evidence. Palisade does not operate the former AppSumo offer, control a recipient mailbox, or guarantee delivery or inbox placement. ## Sources and further reading - [AppSumo: Email Warmup listing](https://appsumo.com/products/marketplace-email-warmup/) - [Palisade: Email Security Score](https://www.palisade.email/tools/email-security-score) - [Palisade: Fixing authentication issues](https://docs.palisade.email/guides/fixing-authentication-issues/) ## Frequently asked questions ### Can I buy Email Warmup through AppSumo today? No. AppSumo marks the exact Email Warmup listing as sold out and says the deal is unavailable. The page is not a current AppSumo purchase or configuration path. ### Does the lifetime-access wording mean the deal is still active? No. The listing retains historic deal terms, including lifetime access and code-redemption conditions, but AppSumo's current status on the same page is sold out. Historic wording does not override the current availability notice. ### Do the listing's seller claims prove inbox placement? No. The seller descriptions are claims about the former product. They do not show the authentication, recipient response, receiver filtering, or inbox placement for a message sent through your production route. ### Is the AppSumo listing a guide to configuring email warmup? No. The deal is unavailable, and the public listing is not a verified current setup guide. Use it to identify the offer's status, then assess the sender and message path you actually manage. ### What is the first useful check if a real campaign has a delivery problem? Only check the public authentication configuration for the sending domain and a representative delivered message from the affected route. Keep those results separate from the former AppSumo deal and make a narrow change only when the evidence identifies one. --- # Email warmup schedule: a controlled ramp for real mail Canonical: https://www.palisade.email/learning/email-warmup-schedule > Use an email warmup schedule as a controlled ramp for real mail, with evidence for when to hold, advance, or investigate. An email warmup schedule should be a controlled ramp for legitimate, opted-in mail, not a fixed calendar. First confirm the production sender and its authentication, then hold a low, steady volume and increase gradually only while delivered-message results, SMTP responses, complaints, and engagement stay healthy. Pause and investigate when those signals worsen. No universal daily number can prove inbox placement because the safe pace depends on the sending path, audience, and receiver feedback. ## Quick takeaways - Start with real, engaged recipients instead of a sudden volume jump. - Check SPF, DKIM, and DMARC on a representative production message before raising volume. - Advance only when the same sending path has stable delivery, complaint, and engagement signals. - Hold or reduce volume when SMTP deferrals, bounces, complaints, or authentication results worsen. - Treat a warmup-network score as tool activity, not proof of inbox placement for a real campaign. ## What an evidence-led schedule looks like Google's [email sender guidelines](https://support.google.com/mail/answer/81126?hl=en) tell large senders to begin at low volume with engaged recipients, increase slowly, avoid sudden spikes, and monitor delivery, spam rate, and sending-[domain reputation](/tools/domain-reputation). They also require SPF or DKIM for mail sent to personal Gmail accounts, with SPF, DKIM, and DMARC requirements for bulk senders. That is a sound starting condition for a production ramp, not a universal day-by-day quota. To sketch the volumes for your own ramp, the [email warmup calculator](/tools/warmup-calculator) draws the curve between a starting and a target volume and labels it as arithmetic rather than provider guidance. The schedule should follow the identity that actually sends the mail. Confirm the visible From domain and authentication result on a delivered message, then keep the audience and route stable long enough to interpret the next result. [What DMARC does](/learning/what-is-dmarc) explains why the visible From domain matters to authentication evaluation, while [email deliverability](/email-deliverability) covers the broader outcome that the ramp is trying to observe. ![Volume-ramp decision card showing preflight, hold, advance, and investigate states for legitimate production mail.](/images/editorial/email-warmup-schedule/email-warmup-schedule-volume-ramp.svg "1200x919") *Source: Original Palisade deterministic decision card based on [Google's email sender guidelines](https://support.google.com/mail/answer/81126?hl=en). It expresses an operator decision rule, not a mailbox-provider scoring formula or user interface.* ## When to hold, advance, or investigate ### Review each increase Use the same review point after every small increase. A stable result permits another gradual increase. A deteriorating result does not identify one cause by itself, but it is a reason to stop increasing volume and inspect the changed sending path, audience, or message. This is an inference from [Google's instruction to monitor delivery, spam rate, server responses, and reputation](https://support.google.com/mail/answer/81126?hl=en) while increasing volume; Google does not publish one volume calendar that applies to every sender. ### Treat dedicated-IP plans as specific For a new dedicated IP, the context is narrower. [Twilio SendGrid's IP warm-up guidance](https://www.twilio.com/docs/sendgrid/ui/sending-email/warming-up-an-ip-address) describes increasing volume gradually through a dedicated IP and prioritizing the most engaged recipients. Apply provider-specific limits only to the provider and infrastructure they document. Do not copy an IP-warmup schedule onto a shared-IP or domain-only change. ```text VOLUME-RAMP DECISION RECORD Preflight: representative production message passes expected authentication Hold: low, stable volume to opted-in, engaged recipients Advance: delivery and authentication remain stable; no worsening complaints or deferrals Investigate: authentication regression, bounces, deferrals, complaints, or reputation deterioration Boundary: a warmup score or automated replies do not prove future inbox placement ``` ## Build the schedule from real mail ### 1. Establish a production baseline Send representative mail through the exact service, domain, and audience path you plan to ramp. Record its authentication results, acceptance or bounce information, complaint signals, and any provider-specific reputation data available for that route. [Google Postmaster Tools documentation](https://support.google.com/mail/answer/14668346?hl=en-GB) describes Gmail-specific dashboards for verified domains, including spam rate, reputation, authentication, and delivery errors, subject to data-volume limits. ### 2. Hold a low, steady volume Keep the recipient segment engaged and opted in, then avoid changing content, list source, authentication, and volume at the same time. A steady baseline gives the next review a useful comparison. If the goal is to understand automated tool activity instead, [automated email warmup](/learning/email-warmup-service) explains why that activity is not the same evidence as a production message. ### 3. Advance only after a healthy review Increase gradually after the baseline signals remain healthy. The exact increment is a local operating choice, not a fact supplied by this article. Keep a record of the volume change, sender, audience segment, and observed outcome so a later regression can be compared with the previous stable step. ### 4. Investigate before resuming a ramp Pause or reduce the affected volume when the evidence worsens. Start with the actual returned SMTP response, a representative message's authentication results, list-consent evidence, and the specific change made before the regression. If real mail is already reaching spam folders, use the evidence-led guide to [why emails go to spam](/learning/why-do-your-emails-go-to-spam-and-how-can-you-fix-it) instead of treating a larger warmup volume as the repair. ## Check the sender before the next volume step Before increasing volume, inspect the sending domain's public authentication posture with the [Email Security Score](/tools/email-security-score). It can help identify published SPF, DKIM, DMARC, and BIMI configuration gaps that deserve follow-up before a ramp. It cannot see recipient consent, campaign volume, complaint rate, the exact production sending path, or a receiver's future inbox decision. ## Keep an ongoing sender-evidence gap visible A public check is a useful preflight, but it cannot show which production senders later fail alignment or when a new source changes a domain's aggregate-report evidence. After that immediate check, [Palisade's DMARC Agent](https://www.palisade.email/solutions) reads DMARC data, identifies sending services, and helps work through authentication and alignment issues. A human still reviews the evidence and approves sender, DNS, and policy changes; Palisade does not warm mailboxes or control a receiver's placement decision. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=email_deliverability&utm_content=email-warmup-schedule) ## Sources and further reading - [Google email sender guidelines](https://support.google.com/mail/answer/81126?hl=en) - [Google Postmaster Tools dashboards](https://support.google.com/mail/answer/14668346?hl=en-GB) - [Twilio SendGrid: warm up an IP address](https://www.twilio.com/docs/sendgrid/ui/sending-email/warming-up-an-ip-address) - [Instantly: How Warm-Up Works and Why it's Important](https://help.instantly.ai/en/articles/5975329-how-warm-up-works-and-why-it-s-important) - [Palisade DMARC solutions](https://www.palisade.email/solutions) ## Frequently asked questions ### Is there a universal email warmup schedule? No. Google advises a gradual increase with engaged recipients and monitoring, but it does not publish one daily schedule for every sender. Set the next step from the evidence for the actual sender, audience, and receiving environment. ### Should I warm up a shared IP? Not as though it were a dedicated IP. [Google says activity from any sender using a shared IP affects reputation for all senders on that IP](https://support.google.com/mail/answer/81126?hl=en-GB), so a provider's dedicated-IP warm-up plan may not apply. Confirm the provider's guidance and focus on the sender controls and evidence you can observe. ### Can automated warmup messages prove inbox placement? No. [Instantly documents warmup activity among participating accounts](https://help.instantly.ai/en/articles/5975329-how-warm-up-works-and-why-it-s-important), while [Google's sender guidance evaluates the real sending domain, IP, recipient feedback, and authentication](https://support.google.com/mail/answer/81126?hl=en). It follows that tool activity does not establish how a production campaign authenticates, whether recipients opted in, or where a receiver will place future mail. ### What should make me pause a volume increase? Pause when representative production evidence worsens, such as authentication failures, SMTP deferrals, bounces, complaints, or sender-reputation deterioration. Preserve the evidence and investigate the changed route or audience before testing another increase. ### Does a healthy authentication check mean I can send at any volume? No. Authentication is a prerequisite, not a volume allowance or placement guarantee. Continue to increase gradually and use delivery, complaint, engagement, and receiver-specific evidence to decide whether the current pace remains appropriate. --- # Firebase authentication email verification Canonical: https://www.palisade.email/learning/firebase-authentication-email-verification > Firebase Authentication email verification sends a link for a signed-in user and records whether that address is verified. Firebase Authentication email verification is an account-management action for a signed-in user. Firebase can send that user an address-verification email, and the user record exposes an `emailVerified` state. This differs from signing in with an email and password or with an email link. A verified Firebase address also does not establish whether an outgoing message passed [SPF](https://www.rfc-editor.org/rfc/rfc7208), [DKIM](https://www.rfc-editor.org/rfc/rfc6376), or [DMARC](https://www.rfc-editor.org/rfc/rfc9989.html). ## Quick takeaways - Firebase documents `sendEmailVerification` for the current signed-in user. - The user profile includes an `emailVerified` property. - Email-link sign-in verifies the address when that documented flow completes. - Email/password uses a separate password credential flow. - Sender-domain authentication and Firebase user verification answer different questions. ## What Firebase email verification does Firebase's [Manage Users documentation](https://firebase.google.com/docs/auth/web/manage-users) shows `sendEmailVerification` for `auth.currentUser`. In the same Web documentation, the current user's profile includes the `emailVerified` property. Those details describe a user-account state and the action that begins verification. They do not document inbox delivery timing, a Firebase Console path, or an application's own policy for what it permits before the user completes verification. ```text Current signed-in Firebase user -> sendEmailVerification -> user completes the verification link -> inspect emailVerified in the user profile ``` If you are building the flow, use Firebase's current platform documentation for the actual SDK call and the point at which your application refreshes or reads the user state. This article only clarifies which Firebase task the email relates to. ## How verification differs from Firebase email sign-in Firebase [email/password authentication](https://firebase.google.com/docs/auth/web/password-auth) is a provider and credential flow: the user signs in with an email address and password. Firebase's [Email Link documentation](https://firebase.google.com/docs/auth/web/email-link-auth) describes a different passwordless flow that completes sign-in through a received link. Firebase states that this completed Email Link flow also verifies the email address. That qualification matters. Email Link can include address verification as part of its documented completed sign-in flow. Sending a verification email is the separate action to use when the question is whether an existing signed-in user's address has been verified. For the broader choice between the two sign-in methods, see [Firebase authentication email](/learning/firebase-authentication-email). ## Choose the right Firebase email task Use this decision flow to identify the Firebase action that matches the user state before treating any email message as evidence of verification. ![Decision flow separating password credentials, email-link sign-in, and verification for an existing signed-in Firebase user.](/images/editorial/firebase-authentication-email-verification/firebase-authentication-email-verification-flow.svg "1200x550") *Source: Original Palisade decision flow summarizing Firebase's [Manage Users documentation](https://firebase.google.com/docs/auth/web/manage-users), [Email Link documentation](https://firebase.google.com/docs/auth/web/email-link-auth), and [email/password documentation](https://firebase.google.com/docs/auth/web/password-auth). It is a conceptual summary, not a Firebase interface or project-specific configuration.* The flow is deliberately narrow: it does not show Firebase Console settings, template options, inbox delivery, or any sender-domain authentication result. ## Check the state without mixing tasks ### 1. Identify the user's starting state Ask whether the person is signing in with a password, completing an Email Link sign-in, or already signed in and waiting to verify an address. These are different Firebase tasks even though all can involve an email address. ### 2. Use the matching Firebase flow Use the Email/Password or Email Link flow when the question is how the user signs in. Use the account-management verification action when the question concerns the existing user's email-verified state. Follow the current Firebase documentation for the platform your application uses. ### 3. Read the verification state in the user context After the documented verification flow completes, evaluate `emailVerified` in the application's Firebase user context. Do not use the existence of a sent message as proof that the user completed the link or that the application has refreshed its state. ## Keep sender authentication separate [SPF](https://www.rfc-editor.org/rfc/rfc7208) evaluates whether a host is authorized to use a domain in mail sending. [DKIM](https://www.rfc-editor.org/rfc/rfc6376) uses a cryptographic signature to associate a responsible signing domain with a message. [DMARC](https://www.rfc-editor.org/rfc/rfc9989.html) uses SPF or DKIM results and identifier alignment for the visible From domain. Firebase's documentation instead describes verification as a state on an application user. It follows that a sender-domain check cannot prove that a Firebase user completed verification, and a verified Firebase user cannot prove a message passed sender-domain authentication. See [what email authentication is and why it matters](/learning/what-is-email-authentication-and-why-does-it-matter) for the sender-domain question. An [email authentication checker](/tools/email-security-score) can inspect published domain evidence, but it cannot inspect a Firebase user's `emailVerified` state, a private inbox, or a completed application flow. Use Firebase's documentation and your application's own authorized user-state checks for those questions. ## Sources and further reading - [Firebase: Manage Users](https://firebase.google.com/docs/auth/web/manage-users) - [Firebase: Authenticate with Firebase Using Email Link in JavaScript](https://firebase.google.com/docs/auth/web/email-link-auth) - [Firebase: Authenticate with Firebase using Password-Based Accounts using JavaScript](https://firebase.google.com/docs/auth/web/password-auth) - [IETF email-authentication specifications: SPF (RFC 7208), DKIM (RFC 6376), and DMARC (RFC 9989)](https://www.rfc-editor.org/rfc/rfc9989.html) ## Frequently asked questions ### Does sending a Firebase verification email mean the address is verified? No. Sending the message begins Firebase's documented verification action for the current user. Treat `emailVerified` as the relevant user-profile state, and ensure your application handles the completed verification flow before relying on that state. ### Does Firebase Email Link sign-in verify the email address? Yes. Firebase documents that the completed Email Link sign-in flow verifies the user's email address. That is specific to the completed Email Link flow, rather than a rule that every Firebase email/password user is already verified. ### Is Firebase email verification the same as password reset? No. Email verification concerns the user's address-verification state. Firebase documents password reset as a separate `sendPasswordResetEmail` account-management action, so it should not be used as evidence that an address is verified. See [Firebase: Manage Users](https://firebase.google.com/docs/auth/web/manage-users). ### Does Firebase email verification prove DMARC passed? No. Firebase email verification concerns an application user's address state. [DMARC](https://www.rfc-editor.org/rfc/rfc9989.html) evaluates aligned SPF or DKIM authentication for the visible From domain, so the two results cannot establish each other. ### Should an app require a verified Firebase email before access? Only if that requirement matches the application's own policy and user journey. Firebase documents the verification action and user state, but the application owner decides which actions, if any, depend on a verified address. --- # Firebase authentication email Canonical: https://www.palisade.email/learning/firebase-authentication-email > Firebase Authentication supports email/password and email-link sign-in. Learn how those flows differ from email verification and sender authentication. Firebase Authentication can authenticate an application user by checking an email address and password, or by sending a one-time sign-in link to the address. Enable the Email/Password or Email Link provider in the Firebase project before using its flow. Email verification is a separate account-state action, and none of these application-user checks prove that the message passed SPF, DKIM, or DMARC. ## Quick takeaways - Email/Password sign-in uses an email address with a password that the user supplies. - Email Link sign-in sends a link that completes sign-in and verifies the user's email address in that flow. - Sending a verification email for an existing email/password user is separate from choosing a sign-in method. - Firebase application authentication and sender-domain email authentication answer different questions. ## How Firebase email sign-in works Firebase documents two email-based sign-in choices for web applications. With [email/password authentication](https://firebase.google.com/docs/auth/web/password-auth), an app creates or signs in a user with an email address and password after the Email/Password provider is enabled. With [email-link authentication](https://firebase.google.com/docs/auth/web/email-link-auth), the app sends a sign-in link to the address and completes the sign-in after the user opens it. The important distinction is the credential. An email/password flow checks a password credential. An email-link flow uses possession of the received sign-in link as part of its documented flow. Firebase says the email address is verified when the email-link flow completes, but that does not mean every email/password account is automatically verified. ## When the answer changes Choose email/password when the application needs a password-based account and can safely support password creation, reset, and recovery. Choose an email link when the product wants a passwordless sign-in experience and can implement the documented link-handling flow. In both cases, enable the relevant provider in the Firebase project first. Email verification is not a third sign-in method in this comparison. Firebase's [user-management documentation](https://firebase.google.com/docs/auth/web/manage-users) treats sending a verification email as an action on a signed-in user. Keep that task separate from password credentials and email-link sign-in, and from the narrower Firebase verification-email topic. ## Choose the Firebase email flow Use this decision rule before you write code or change project settings. ![Decision diagram showing the three Firebase email-related tasks: password credentials, email-link sign-in, and verification for an existing user.](/images/editorial/firebase-authentication-email/firebase-authentication-email-flow.svg "1200x550") *Source: Original Palisade decision card summarizing Firebase's [email/password documentation](https://firebase.google.com/docs/auth/web/password-auth), [email-link documentation](https://firebase.google.com/docs/auth/web/email-link-auth), and [user-management documentation](https://firebase.google.com/docs/auth/web/manage-users). It is not a Firebase Console interface or a substitute for project-specific configuration.* ```text Need a password credential? Use Email/Password and enable that provider. Need passwordless sign-in by message link? Use Email Link and handle the completed sign-in link. Need to confirm an existing email/password user's address? Send a verification email as a separate account-management action. ``` ## Apply the choice in the right order ### 1. Name the user-authentication task Decide whether the user must enter a password, open a sign-in link, or verify an account that already exists. Do not treat these as interchangeable just because each uses an email address. ### 2. Enable the matching Firebase provider Enable Email/Password for password credentials or Email Link for link-based sign-in, following the current Firebase documentation for the platform in use. Provider availability in a project is configuration evidence; an email message alone is not. ### 3. Keep sender authentication in its own lane SPF, DKIM, and DMARC help receiving mail systems assess whether a domain is authorized to send a message. Our guide to [email authentication and why it matters](/learning/what-is-email-authentication-and-why-does-it-matter) explains that domain-level question. An [email authentication checker](/tools/email-security-score) can help inspect published sender-domain evidence, but it cannot prove a Firebase user signed in or that an email-link flow completed. If the issue is an SMTP submission or mailbox-login error, use [authentication failed email](/learning/authentication-failed-email) for the evidence relevant to that failure. It is not Firebase Auth provider configuration evidence. ## Sources and further reading - [Firebase: Authenticate with Firebase using Password-Based Accounts using JavaScript](https://firebase.google.com/docs/auth/web/password-auth) - [Firebase: Authenticate with Firebase Using Email Link in JavaScript](https://firebase.google.com/docs/auth/web/email-link-auth) - [Firebase: Manage Users](https://firebase.google.com/docs/auth/web/manage-users) ## Frequently asked questions ### Is Firebase email authentication the same as email verification? No. Firebase can authenticate a user through email/password credentials or an email sign-in link. Sending a verification email is a separate account-management action, although a completed email-link sign-in flow verifies the address in that documented flow. ### Does Firebase email-link sign-in require a password? No. Firebase documents email-link authentication as a passwordless sign-in method. The application sends a sign-in link to the user's email address, then completes the flow when the user opens the link through the implementation's configured handling path. ### Does Firebase Authentication prove an email message passed DMARC? No. Firebase Authentication concerns an application user's sign-in state. DMARC evaluates sender-domain alignment and authentication results at the receiving mail system, so it cannot be established by a Firebase credential or email-link completion. ### Should I use email/password or an email link? Only use email/password when the product needs password-based accounts; use an email link when a passwordless link-based sign-in experience fits the product. In either case, follow Firebase's current provider and implementation documentation for the application platform. --- # Gartner secure email gateway Magic Quadrant Canonical: https://www.palisade.email/learning/gartner-secure-email-gateway-magic-quadrant > Gartner's current report is the Magic Quadrant for Email Security. How to read it, how to verify a 2020 or 2021 gateway claim, and its limits. The current Gartner research for this search is [Gartner Magic Quadrant for Email Security](https://www.gartner.com/en/documents/7222830), published 1 December 2025. Gartner's public abstract does not identify a separate current report titled “Magic Quadrant for Secure Email Gateways.” Use the Email Security report to understand Gartner's market research, then validate deployment, controls, and outcomes in your own environment before treating it as a product decision. ## Quick takeaways - The current public report is titled Magic Quadrant for Email Security. - Gartner publishes its title, date, scope, and a summary on the public abstract page. - A Magic Quadrant is market-position research, not proof of performance in one tenant. - A gateway review still needs evidence about mail flow, controls, and operational fit. - A 2020 or 2021 gateway placement cannot be confirmed from a vendor page or a search result; it needs the original Gartner publication. ## Why the report uses email security, not secure email gateway “Secure email gateway” describes one way to protect mail flow. For that architecture, see [what an email security gateway is](/learning/email-security-gateway). For how it relates to sender authentication, see [how secure email gateways protect an organization](/learning/how-secure-email-gateways-protect-organization). The current Gartner public abstract uses the broader title **Magic Quadrant for Email Security** and says the full research includes a market definition, inclusion and exclusion criteria, vendor strengths and cautions, and evaluation criteria. Gartner describes Magic Quadrant research as graphical competitive positioning based on **Ability to Execute** and **Completeness of Vision** on its [Magic Quadrant research page](https://www.gartner.com/en/information-technology/research/magic-quadrant). That framing is useful for market research. It does not establish how a particular mail route, policy set, permission model, or incident process will work in your organization. ## What a Magic Quadrant can and cannot decide Use the report to form questions for a shortlist, not to skip the evidence that answers them. The following decision card is an original editorial framework based on Gartner's public methodology description. It is not a Gartner chart, ranking, or vendor assessment. ![Decision card separating market research, vendor documentation, and tenant validation](/images/editorial/gartner-secure-email-gateway-magic-quadrant/magic-quadrant-decision-card.svg "1300x712") *Source: Original deterministic decision card based on [Gartner's Magic Quadrant research description](https://www.gartner.com/en/information-technology/research/magic-quadrant).* The report can help structure a market conversation. Vendor documentation can establish what a product says it supports. Only a controlled tenant evaluation can test the mail flow and operating conditions that matter to your team. Do not infer a vendor's placement, price, feature superiority, or tenant performance from the public abstract. ## How to turn the report into an evaluation ### 1. Record the market question Start with the public report title, date, and the problem your team wants to solve. If your task is broader cross-vendor selection rather than research interpretation, use the separate [anti-phishing software selection guide](/learning/anti-phishing-software) for that decision. ### 2. Compare documented requirements For each candidate, collect its current deployment model, mail-flow dependencies, administrative permissions, logging, integrations, and policy controls from the vendor's documentation. A provider explainer, such as [Barracuda email security](/learning/barracuda-email-security), can clarify a product's documented scope, but it does not establish a Gartner placement. ### 3. Test the conditions you own Run a controlled evaluation with representative mail paths and a defined test plan. Capture the evidence before making a production decision. ```text Evaluation record Scope: inbound, outbound, or API-connected mail path Controls: routing, permissions, policy, logging, integrations Test evidence: detection, false positives, response workflow, operator effort Decision boundary: no vendor placement or tenant outcome is inferred from the public abstract ``` ## What about a 2020 or 2021 secure email gateway Magic Quadrant? Gartner's current public abstract is the Magic Quadrant for Email Security, published 1 December 2025, and it does not identify a 2020 or 2021 report titled "Magic Quadrant for Secure Email Gateways." Whether such a report exists, and what it concluded, can only be established from the original Gartner publication or an official Gartner record. A vendor homepage, a search snippet, or a remembered result cannot establish it. This page makes no claim that Gartner published, renamed, superseded, or discontinued any report under that title. A historical analyst citation has several parts, and each one has to come from the report itself or from an official Gartner record: - The exact report title, which identifies the market that was assessed. - The publication date, which confirms the year in question. - The inclusion criteria and methodology, which explain what was evaluated. - The vendor list and any quadrant classification, which the source has to state rather than leave to inference. A vendor's current product page can describe what that vendor sells today. It cannot retroactively establish that the vendor was named a Leader, Challenger, Visionary, or Niche Player in an earlier report. To quote or compare a historical result, obtain the original Gartner publication or licensed Gartner material that reproduces it. "Email Security" and "secure email gateway" are also not interchangeable report categories. A vendor page stating it is a Leader in a current Gartner Magic Quadrant for Email Security is evidence about that current report only. It does not establish a position in any earlier report about secure email gateways, and any relationship between the two category names would have to be documented in the reports themselves. A historical result also cannot show whether a control is working now. Products, provider integrations, mail routes, third-party senders, and policy settings all change. When the task is to review an email-security control today, collect evidence from the deployed mail path instead of from an older market report. ## A bounded procurement checklist - Confirm that the public Gartner page is the report and date your team intends to discuss. - Separate Gartner's market framing from the product claims in each vendor's current documentation. - Map the candidate to the actual mail paths and identity systems in scope. - Define success and false-positive criteria before the tenant test begins. - Review the response workflow, ownership, and evidence retention with the operators who will use it. - When the question is current exposure rather than market research, start from the [email threat-management hub](/learning/threats). ## Sources and further reading - [Gartner Magic Quadrant for Email Security public abstract](https://www.gartner.com/en/documents/7222830) - [Gartner Magic Quadrant research and methodology page](https://www.gartner.com/en/information-technology/research/magic-quadrant) ## Frequently asked questions ### Is there a current Gartner Magic Quadrant for secure email gateways? Not under that exact public title. Gartner's current public abstract is titled Magic Quadrant for Email Security and was published on 1 December 2025. Use that official page to confirm the report before relying on secondary pages that use older gateway terminology. ### Does the public Gartner page show every vendor's placement? No. The public abstract identifies the report and its included research areas, but it is not a reproduced Magic Quadrant graphic or a complete placement analysis. Do not infer a vendor's quadrant placement from the abstract alone. ### Does a Magic Quadrant prove a gateway will work in our environment? No. Gartner's methodology describes market positioning. It cannot prove how your routes, administrative permissions, detection settings, false positives, or incident process will behave. Those questions need documented requirements and a controlled tenant evaluation. ### Can I use vendor documentation as proof of Gartner placement? No. Vendor documentation can help verify a product's deployment and control claims. It does not replace Gartner's own report or establish the vendor's position, inclusion rationale, or comparative standing. ### Where can I find the 2020 or 2021 secure email gateway Magic Quadrant? Gartner's current public abstract is the Magic Quadrant for Email Security, published 1 December 2025, and it does not identify an earlier Secure Email Gateway report. To cite a 2020 or 2021 result, obtain the original Gartner publication or licensed Gartner material that reproduces it. ### Can a vendor's website confirm its placement in an older Magic Quadrant? No. A vendor homepage or product page describes the current offering. It does not establish the title, date, evaluation criteria, or vendor positions of a historical analyst report, so it cannot support a claim that a vendor held a particular quadrant position. --- # Why does Gmail say "Be careful with this message"? Canonical: https://www.palisade.email/learning/gmail-be-careful-with-this-message-warning > Why Gmail says "Be careful with this message": inspect the warning text and headers, repair SPF, DKIM, or DMARC issues, then retest delivery. Gmail's "Be careful with this message" heading is a safety warning, not one specific DNS error. Read the text below it first. If Gmail says it could not verify the sender, inspect the delivered message's SPF, DKIM, and DMARC results before repairing the sending path. If the warning says the message may be phishing, spoofed, or sent by a compromised contact, treat it as a security issue instead of changing DNS. ## Quick takeaways - Gmail documents several warning categories, so the sentence beneath the heading matters more than the heading alone. - An unconfirmed sender is not automatically phishing, but Gmail cannot confirm the apparent sender. - SPF and DKIM help DMARC only when their authenticated domain aligns with the visible From domain. - A forwarding service, mailing list, gateway, or third-party application can change the authentication evidence Gmail receives. - A public DNS lookup cannot prove how the affected production message was authenticated. - Retest with a new message sent through the same application and route after each repair. ## What should I check before configuring Gmail? Identify the exact sending path that produced the warning. Employee mail from Google Workspace, marketing mail from an email platform, transactional mail from an application, and mail routed through a gateway can use different envelope senders, DKIM selectors, and DNS zones. Collect the affected message's full headers, access to the service that sent it, and permission to inspect the relevant DNS zone. Do not edit the visible From domain's DNS until the message evidence identifies the responsible sending identity. > Copy DNS values from the account and domain you are configuring. Do not publish selectors, targets, tokens, or hostnames from another account or from an online example. Google's [Gmail warning guidance](https://support.google.com/mail/answer/1366858) distinguishes unconfirmed senders from warnings about spoofing, phishing, and possible account compromise. Google does not publish a one-to-one mapping between every banner phrase and a technical cause. Treat the banner as a classification clue, then confirm the cause from the delivered message. ![Public Gmail warning banner showing the "Be careful with this message" heading](/images/editorial/gmail-be-careful-with-this-message-warning/gmail-be-careful-warning-banner.png "1365x217") *Source: [Why are my emails been flagged with a be careful with this email message?](https://support.google.com/a/thread/173774680/why-are-my-emails-been-flagged-with-a-be-careful-with-this-email-message?hl=en), checked 2026-08-12. This is a public community example, not Google product documentation or proof of a current account state.* ## Which setup method should I use? Use the repair that matches the message evidence. - If a marketing, CRM, billing, or transactional service sent the message, use that service's current domain-authentication workflow. It may supply account-generated DKIM records, a custom return-path domain, or SPF instructions. - If the affected path is mailbox-hosted Google Workspace mail, inspect the Workspace authentication configuration and any outbound gateway. - If direct mail passes but forwarded or relayed mail fails, investigate the forwarding service or gateway before changing the original sender's DNS. - If Gmail warns that the message is a scam or appears to come from a compromised contact, follow Google's [guidance for suspicious messages](https://support.google.com/mail/answer/1366858) and verify the request outside the message. Google's [sender guidelines for personal Gmail accounts](https://support.google.com/mail/answer/81126) require SPF or DKIM for all senders. Bulk senders have additional SPF, DKIM, and DMARC requirements. Authentication supports delivery, but it does not guarantee inbox placement or remove every Gmail safety warning. For broader implementation guidance, use Palisade's [vendor email authentication guides](/learning/esp-setup). ## How do I configure SPF and DKIM for Gmail deliveries? ### 1. Record the complete Gmail warning Copy the sentence beneath the banner. Record the visible From address, Reply-To address, delivery time, recipient mailbox, and whether Gmail placed the message in Inbox or Spam. If you are a recipient rather than the sending-domain operator, do not reply, open links, or download attachments while investigating a warning that indicates risk. Confirm sensitive requests through a known phone number, portal, or separate conversation. ### 2. Open Gmail's original-message view and collect the evidence In Gmail on the web, open the affected message, select More beside Reply, then choose **Show original**. Google's [instructions for viewing full message headers](https://support.google.com/mail/answer/29436) document this path. Find the `Authentication-Results` field added by the receiving system you trust. [RFC 8601 defines Authentication-Results syntax and its trust boundary](https://www.rfc-editor.org/rfc/rfc8601.html). A sender can add similar-looking fields, so a sender-supplied line is not evidence of what Gmail evaluated. Keep the warning text separate from the sending evidence. - **Gmail warning text:** The complete sentence beneath the banner. It classifies the visible risk signal but does not identify a failed DNS record by itself. - **Visible From domain:** The domain in the address the recipient sees, such as `yourdomain.com`. - **Trusted receiver Authentication-Results:** The `spf=`, `dkim=`, and `dmarc=` results from Gmail or another receiver you trust. - **DKIM `d=` domain:** The signing domain in `DKIM-Signature`. - **Return-path domain:** The envelope-sender identity, often shown in `Return-Path` and as `smtp.mailfrom=`. - **Sending application:** The mailbox platform, email service, CRM, billing system, or application that created the message. This redacted header example is illustrative only: ```text Authentication-Results: mx.google.com; spf=pass smtp.mailfrom=bounce.mailer.yourdomain.com; dkim=pass header.d=yourdomain.com header.s=selector1; dmarc=pass header.from=yourdomain.com ``` A passing SPF or DKIM result does not prove that the visible From domain passed DMARC, that every sender uses this path, or that Gmail will remove the warning from future messages. Read Palisade's guide to [Gmail Authentication-Results](/learning/what-is-an-email-header) before changing DNS based on one message. ### 3. Classify the authentication results Compare each result with the identity it names. - `spf=` with `smtp.mailfrom=` identifies the SPF result and envelope-sender domain. - `dkim=` with `header.d=` identifies the DKIM result and signing domain. - `dmarc=` with `header.from=` identifies Gmail's DMARC result for the visible From domain. - `arc=` can add context when a forwarder or mailing list handled the message. The result pair tells you which branch to investigate first. ![Decision flow for classifying a Gmail warning from the warning text and trusted authentication results](/images/editorial/gmail-be-careful-with-this-message-warning/gmail-warning-diagnostic-flow.svg "1200x879") *Source: [Gmail Help: Email authentication](https://support.google.com/mail/answer/180707), checked 2026-08-12.* Treat the diagram as a routing aid, not as a substitute for the complete header. [RFC 9989 defines DMARC alignment](https://www.rfc-editor.org/rfc/rfc9989.html). An SPF pass for a provider-owned return-path domain can still leave DMARC failing when that domain does not align with `header.from`. ### 4. Publish records for the actual sending identity For SPF failures, inspect the exact `smtp.mailfrom` identity. [RFC 7208 defines SPF as authorization for the MAIL FROM identity or, in some cases, the HELO identity](https://www.rfc-editor.org/rfc/rfc7208.html). Publish one SPF TXT policy at that domain and merge legitimate services into the existing policy. Do not add a second `v=spf1` record. **Record type:** `TXT` **Host (illustrative only):** ```text mail.yourdomain.com ``` **Value (illustrative only):** ```text v=spf1 include:spf.example-sender.invalid -all ``` > Do not publish this example. Copy the full SPF mechanisms from the service that sent the affected message. DNS providers that append the zone name can create `mail.yourdomain.com.yourdomain.com` when a full name is pasted into a host field. For a DKIM failure or missing signature, open the sending service that produced the message and retrieve its current domain-authentication records. [RFC 6376 defines DKIM selectors and public-key records](https://www.rfc-editor.org/rfc/rfc6376.html). The vendor generates the real selector, CNAME target, or TXT value for its account. Do not copy one from another tenant or an online example. ### 5. Verify in the sending service and send a new message Return to the service that sent the warning-triggering message and wait for its domain-authentication status to show the published records are accepted. Then send a new message through the same production application, return path, gateway, and visible From domain. A green vendor indicator proves that the service accepted its current DNS configuration. It does not prove Gmail's treatment of a delivered message, that another application is configured, or that the next message will have the same route. ## How does this setup affect DMARC? DMARC passes when SPF or DKIM passes and aligns with the visible From domain. SPF alignment compares the authenticated envelope sender with the From domain. DKIM alignment compares the `d=` signing domain with the From domain. A valid signature for an unrelated provider domain can still fail DMARC alignment. Use Palisade's [DMARC checker](/tools/dmarc) to inspect the published DMARC policy before changing enforcement. A public record check cannot show which application sent the affected message, Gmail's private safety decision, or future message placement. If the message comes from a third-party sender, ask whether it supports a custom return path or DKIM signing with your domain. If it does not, its mail may pass SPF or DKIM for its own domain while failing alignment with your visible From domain. Palisade's [Gmail authentication setup guide](/learning/authenticate-email-for-gmail) covers the wider sender requirements and deployment sequence. ## How do I validate the setup? ### Check public DNS Query the exact SPF, DKIM selector, or DMARC owner identified by the message. Compare the authoritative DNS answer with at least one public resolver. ```bash dig +short TXT yourdomain.com dig +short TXT selector1._domainkey.yourdomain.com dig +short TXT _dmarc.yourdomain.com ``` Keep the exact owner names from the affected path. A DNS provider's host-field suffix behavior can create duplicated names even when the entry appears plausible in its console. ### Check the vendor or sending-service state Confirm that the sending service accepts the configured domain, DKIM selector, and any required return-path setup. Record the selected account and domain. This is the vendor-side check for the path that created the message. ### Inspect a newly delivered Gmail message Open **Show original** for a new message sent after the repair. Confirm the expected `smtp.mailfrom`, `header.d`, selector, and `header.from` values. Check that the required SPF or DKIM result passes and aligns with the visible From domain when it is expected to satisfy DMARC. ### Verify Gmail's warning state Send another fresh production message to a Gmail mailbox and compare its banner text with the original warning. Gmail does not document a public rule that guarantees a particular banner disappears after an authentication repair. The comparison can show whether Gmail still presents the same sender-verification warning on the repaired path. It does not prove Gmail's future classification decisions. ### Review DMARC aggregate data After reports accumulate, review whether the repaired sending source passes SPF or DKIM and aligns with the From domain. Palisade can analyze DMARC aggregate-report data, identify sending sources and authentication or alignment issues, and create prioritized remediation tickets. A human reviews the evidence and applies any DNS or DMARC policy change. ## Troubleshooting ### Gmail shows no SPF or DKIM pass Check which identity failed before editing DNS. SPF must authorize the `smtp.mailfrom` or relevant HELO identity. DKIM requires a valid signature and the public key at the selector's DNS owner. Confirm that the sending service is actually using the domain whose records you changed. ### SPF passes but DMARC fails Compare `smtp.mailfrom` with `header.from`. The SPF domain may belong to the sender's shared infrastructure rather than your visible From domain. Configure an aligned custom return path if the sender supports it, or use aligned DKIM signing. ### DKIM passes but DMARC fails Compare `header.d` with `header.from`. A DKIM pass from an unrelated domain does not meet DMARC alignment. Configure the service to sign with an aligned domain or investigate why the intended signing domain is absent. ### Direct mail passes but forwarded mail shows the warning Google's [forwarding guidance](https://support.google.com/mail/answer/175365) explains that forwarding can affect SPF and recommends preserving authentication evidence. Compare a direct message with the forwarded message. Check the forwarding service's ARC handling and its configuration before modifying the original sender's DNS. ### Gmail's warning describes phishing or a compromised contact Do not treat this as an SPF or DKIM repair. Google's guidance tells recipients to avoid responding to suspicious messages and to verify a request outside the message. If account compromise is confirmed, follow Google's [account security recovery steps](https://support.google.com/accounts/answer/6294825) for the affected account. ### Only one application triggers the warning Inventory the sender that created the message. A domain can have working Google Workspace authentication while a marketing platform, CRM, billing tool, or application uses a different return path or DKIM domain. Repair and retest the one application before assuming the whole domain is fixed. ## Keep the sender inventory after the one-message repair Use Palisade's [email security score](/tools/email-security-score) to inspect the domain's public authentication posture after you correct the affected sender. Compare that result with the new message headers and the sending service's status. A public check cannot prove why Gmail warned on one message, monitor all production sending paths, or control Gmail's safety banners. For the ongoing gap after a single repair, Palisade is agentic DMARC software that analyzes aggregate-report data, identifies sending sources and alignment issues, and proposes the next policy step for human review. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=existing_content_migration&utm_content=gmail-be-careful-with-this-message-warning) ## Sources and further reading - [Gmail Help: Email authentication](https://support.google.com/mail/answer/180707) - [Gmail Help: Warning messages](https://support.google.com/mail/answer/1366858) - [Google sender guidelines for personal Gmail accounts](https://support.google.com/mail/answer/81126) - [RFC 8601: Authentication-Results](https://www.rfc-editor.org/rfc/rfc8601.html) - [RFC 9989: DMARC](https://www.rfc-editor.org/rfc/rfc9989.html) - [RFC 7208: Sender Policy Framework](https://www.rfc-editor.org/rfc/rfc7208.html) ## Frequently asked questions ### Does "Be careful with this message" mean the email is phishing? No. Gmail documents unconfirmed-sender warnings separately from phishing, spoofing, and compromised-contact warnings. Read the full text beneath the heading, then inspect the message headers if it concerns sender verification. Do not open links or attachments while the warning indicates a possible scam. ### Can a recipient remove the Gmail warning permanently? No. A recipient can make an immediate safety decision, but recipient-side actions do not repair the sender's authentication path or establish a permanent solution for other recipients. The sending-domain operator must diagnose the affected application, return path, DKIM signature, and alignment evidence. ### Can SPF and DKIM both pass while Gmail still shows a warning? Yes. A passing SPF or DKIM result may not align with the visible From domain, so DMARC can still fail. Gmail can also show a warning for reasons other than sender authentication. Compare `smtp.mailfrom`, `header.d`, and `header.from` in the trusted `Authentication-Results` field. ### Why does only one application trigger Gmail's warning? One application can use a separate envelope sender, DKIM selector, gateway, or DNS zone from the rest of the domain's mail. Test each material sending path with a new message. Do not treat a successful Google Workspace message as proof that a CRM or transactional sender is configured correctly. ### Does publishing a DMARC record remove Gmail's warning? No. A DMARC record alone does not repair an unauthenticated or misaligned sending path. DMARC evaluates SPF or DKIM alignment for each message. Configure the actual sender, validate a fresh message, then use aggregate reports to confirm how that source performs over time. --- # Why does Gmail report TLS errors? Canonical: https://www.palisade.email/learning/gmail-tls-errors > Gmail TLS errors mean an SMTP connection could not meet transport-security checks. Capture the exact host, handshake evidence, policy, then retest. Gmail reports a TLS error when the SMTP connection for a delivery attempt cannot complete or cannot meet the transport-security checks that apply to that route. Start with the complete SMTP error and the exact MX host involved. Then test that SMTP path, compare its TLS certificate and configuration with published MX and MTA-STS records, repair the confirmed issue, and retry through the same route. SPF, DKIM, and DMARC do not repair a failed TLS negotiation. ## Quick takeaways - A Gmail TLS error concerns SMTP transport security before SPF, DKIM, or DMARC results can help explain delivery. - The full SMTP response, delivery direction, MX hostname, and timestamp determine the useful diagnostic branch. - STARTTLS support, TLS protocol compatibility, certificate validation, MX records, and MTA-STS policy are separate checks. - An MTA-STS policy in `enforce` mode can cause a sender to defer delivery when the selected MX host or its certificate fails policy requirements. - Public DNS inspection can reveal published MX records, but it cannot prove the exact production SMTP route or Gmail's decision for one attempt. - A successful TLS connection does not establish message acceptance, inbox placement, or future delivery. ## What does the failure mean? Google's [SMTP error reference for senders](https://support.google.com/mail/answer/3726730?hl=en) documents delivery responses that help identify mail transport failures. Google also requires bulk senders to use TLS or SSL for SMTP connections. The phrase "TLS error" alone does not identify one cause. It can refer to a failed STARTTLS exchange, a handshake failure, certificate validation, or a conflict with the receiving domain's transport policy. ```text TLS error ``` Preserve the complete SMTP response exactly as logged, including any three-digit SMTP code and enhanced status code. Also retain the sending system, recipient domain, receiving MX hostname, source IP, timestamp, and message ID where available. The string above identifies the symptom, not the responsible host or configuration fault. [SMTP STARTTLS in RFC 3207](https://www.rfc-editor.org/rfc/rfc3207.html) defines the protocol sequence. An SMTP server advertises `STARTTLS` during capability exchange. The client requests TLS only after that advertisement, then the peers begin the TLS handshake. A failure before or during that handshake is a transport-layer problem. It is separate from message-authentication evaluation. ![Flow showing how to move from an SMTP TLS error to the affected MX host, certificate and MTA-STS checks, then a controlled retry](/images/editorial/gmail-tls-errors/gmail-tls-errors-tls-evidence-flow.webp "1200x829") *Source: Palisade.* For broader protocol context, use the [email transport security learning hub](/learning/infrastructure). ## What usually causes it? ### The receiving SMTP server does not offer usable STARTTLS The SMTP server may not advertise `STARTTLS`, or a gateway on the route may interfere with the capability exchange. RFC 3207 states that an SMTP client must not begin TLS negotiation unless the server advertises the extension. This branch fits evidence that the connection did not reach a TLS handshake. An HTTPS browser test does not disprove it because SMTP can use a different port, certificate, network path, and security device. ### The peers cannot negotiate compatible TLS settings The sending and receiving systems need mutually supported TLS settings. Google's [Gmail SMTP TLS documentation](https://support.google.com/a/answer/9795993?hl=en) publishes the TLS versions and cipher suites Gmail supports for SMTP connections. Do not infer the exact protocol or cipher issue from a short SMTP response. Inspect the sending MTA, gateway, or receiving SMTP logs for offered settings, negotiated settings, or the handshake alert that ended negotiation. ### The SMTP certificate does not validate for the MX host A server can offer TLS and still fail certificate validation. Relevant evidence can include an expired certificate, a certificate that is not yet valid, an incomplete chain, an untrusted issuer, or a certificate name that does not match the MX hostname the sender contacted. Certificate faults and protocol-compatibility faults require different repairs. Replacing a certificate does not solve a lack of compatible TLS settings. Changing cipher settings does not make an expired or incorrectly named certificate valid. ### MX records, the SMTP listener, and MTA-STS policy disagree An MX record can direct mail to a host whose certificate does not cover that host. During a migration, a lower-priority MX host can remain published with an old certificate or different TLS configuration. [RFC 8461 defines MTA-STS](https://www.rfc-editor.org/rfc/rfc8461.html). With an `enforce` policy, a policy-aware sender must use TLS, select an MX host permitted by the policy, and validate the certificate for that host. If the active MX, certificate, or policy `mx` pattern disagree, the sender can defer delivery instead of using an unauthorized route. ### A provider-managed sender or gateway controls the failing hop The failure can occur while Google Workspace sends to a remote domain, while an external sender delivers to your MX infrastructure, or at a provider-operated gateway between them. The delivery direction and connection evidence identify who controls the failing SMTP host. This is an operational inference from the SMTP path, not a documented Gmail mapping. If another operator controls the host, provide that operator with the complete response, hostname, timestamp, and certificate evidence. ## How do I diagnose the failure? ### 1. Preserve the SMTP evidence Save the raw SMTP transcript or complete log event before changing DNS, certificates, TLS settings, or MTA-STS policy. Determine the delivery direction first. - If your system sends to a Gmail or Google Workspace recipient, inspect outbound MTA or gateway logs. - If Gmail or Google Workspace sends to your domain, inspect the inbound SMTP listener and the MX host Google attempted to reach. - If a provider sends mail for your domain, request connection evidence from that provider. Do not diagnose the failure from an end-user notification alone. It often omits the MX hostname and handshake details needed to isolate the connection. ### 2. Build a TLS evidence packet Use one labelled packet for the incident ticket, provider escalation, or controlled retest: - **Sending MTA or service:** the application, outbound MTA, ESP, or gateway that opened the SMTP connection. - **Recipient domain:** the domain used to resolve MX records. - **Timestamp and timezone:** the delivery attempt time with a timezone, so both operators can locate the same event. - **Full SMTP or TLS error text:** preserve the string and codes without rewriting them. - **Port and STARTTLS context:** record the port, whether `STARTTLS` was advertised, whether the client issued `STARTTLS`, and where the exchange ended. - **Negotiated protocol and cipher evidence:** record the protocol and cipher if negotiation completed, or the available alert and offered-settings evidence if it did not. - **MX host resolved:** record the exact hostname and IP used for the failed connection. - **Controlled retry result:** record the same-path test result after one scoped change or a confirmed no-change retry. This is an illustrative redacted evidence shape. Do not publish customer domains, recipient addresses, private IP addresses, message IDs, or certificate serial numbers in a shared ticket. ![TLS evidence packet showing the SMTP host, delivery direction, handshake result, certificate details, and controlled retry fields](/images/editorial/gmail-tls-errors/gmail-tls-errors-evidence-packet.webp "1200x754") *Source: Palisade.* ```text Timestamp: 2026-08-12 09:14:22 America/Toronto Sending service: outbound-mta.example Recipient domain: recipient.example MX host resolved: mx1.recipient.example Port: 25 STARTTLS: advertised, client command accepted TLS evidence: handshake failed before negotiated protocol/cipher was recorded SMTP/TLS error: TLS error Controlled retry: same route, same result ``` Connection evidence can establish which SMTP host was contacted, whether STARTTLS was offered, and whether the TLS session negotiated or failed. It cannot establish that Gmail accepted the message body, assigned a message to the inbox, or would make the same decision for a later attempt. ### 3. Test the affected SMTP host Test the hostname identified in logs from a network authorized to reach it. This command is an example for a host you control: ```bash openssl s_client -starttls smtp -connect mx1.yourdomain.com:25 -servername mx1.yourdomain.com -showcerts ``` Inspect whether the server advertises and accepts STARTTLS, the negotiated TLS version and cipher, certificate validity dates, certificate names, and the returned chain. > Do not test only the highest-priority MX host. A lower-priority host can receive traffic during an outage, maintenance event, or routing change. If an outbound gateway completes TLS on behalf of the sending application, establish that through approved logs or a controlled test. Do not bypass a production security control without the owning team's approval. ### 4. Compare MX publication, certificates, and MTA-STS Look up the recipient domain's MX records, then test every host that can receive mail. Compare the SMTP hostname with the valid names in its certificate. For a domain using MTA-STS, compare active MX names with the policy's `mx` patterns. This is illustrative only. Obtain the real values from the domain's own published policy. ```text version: STSv1 mode: enforce mx: mx1.yourdomain.com mx: mx2.yourdomain.com max_age: 86400 ``` An `enforce` policy does not repair an incorrect certificate or stale MX record. It changes delivery behavior by requiring compliant senders to use an authenticated TLS route that matches policy. Use the [MX records checker](/tools/mx) to inspect public MX publication before comparing it with connection logs and direct TLS tests. An MX lookup cannot prove port 25 reachability, the certificate presented on the production route, a gateway's routing choice, or why Gmail treated one attempt as a TLS failure. ### 5. Separate transport failure from message authentication Do not change SPF, DKIM, or the DMARC policy while the TLS failure remains unconfirmed. These controls answer different questions. The [guide to Gmail SPF errors](/learning/why-does-gmail-report-an-spf-error) covers an authentication failure after message handling reaches that stage. If Google sends an MTA-STS report, compare the report timing and destination host with the evidence packet. The [Google MTA-STS TLS reports guide](/learning/google-mta-sts-tls-reports) explains why those reports need SMTP and DNS evidence before a repair decision. ## How do I fix it? ### Restore usable STARTTLS on the affected SMTP listener If logs show that the host does not advertise or accept STARTTLS, correct the listener or the gateway configuration on that specific route. Confirm the listener supports the SMTP service expected on port 25 before changing other hosts. This repair changes transport configuration. It does not change SPF, DKIM, DMARC, or the requested DMARC enforcement policy. ### Align TLS capabilities on both peers If evidence shows no mutually supported protocol version or cipher suite, update the system you control to a configuration compatible with the peer's documented support. For Gmail connections, compare the local configuration with [Google's published SMTP TLS support](https://support.google.com/a/answer/9795993?hl=en). Change one TLS setting group at a time and keep the previous configuration available for rollback. A broad TLS-policy change can affect other mail routes. ### Correct the certificate and hostname mapping If the certificate is expired, incomplete, untrusted, or mismatched to the contacted MX hostname, deploy a valid certificate chain for that hostname or correct the MX publication to a hostname covered by the intended certificate. Test every published MX host after the change. Repairing only the primary host leaves an intermittent failure when a backup host receives traffic. ### Repair the MX and MTA-STS relationship If the MTA-STS policy permits different hosts than current MX records, correct the stale MX record, certificate, or policy entry according to the intended receiving architecture. Keep policy changes separate from the underlying repair. Do not switch `mode: enforce` to a weaker mode as a substitute for repairing a broken mail path. That changes transport-policy enforcement but does not restore certificate validity, STARTTLS support, or routing correctness. ### Escalate provider-managed failures with the evidence packet If a provider controls the sending MTA, receiving MX host, or intervening gateway, send the redacted TLS evidence packet and ask the provider to identify the failed connection stage. Include the controlled retry result. Do not assume a provider dashboard status proves the same production SMTP path was healthy. Request confirmation tied to the hostname and timestamp in the failed event. ## How do I validate the repair? Repeat the failed delivery through the same application, sending service, recipient domain, and route. Confirm that the affected SMTP host advertises and completes STARTTLS, then record the negotiated TLS version and cipher when available. Validate all applicable layers: - **DNS:** query authoritative DNS and at least one public resolver for the current MX records. Confirm that every reachable MX hostname matches the intended infrastructure. - **Vendor:** check the sending or receiving provider's current connection status when that provider controls the affected service. - **Message:** send a new message through the same production path and preserve its SMTP result. A successful TLS session does not itself prove acceptance or inbox placement. - **DMARC:** once reports accumulate, inspect aggregate-report data for the sending domain's authentication and alignment behavior. DMARC reports do not replace SMTP TLS evidence. If the incident involved MTA-STS, verify that the selected MX host matches the published policy and that its certificate validates for the host. Keep the failed evidence packet, passing retest, configuration change, and rollback condition with the incident record. ## Track transport issues that DNS checks cannot show Use the MX checker to confirm what public DNS currently publishes, then compare that result with the affected SMTP logs. [Inspect published MX records](/tools/mx) A public MX check cannot test the live TLS handshake, prove Gmail accepted a message, monitor future route changes, or diagnose a provider-managed connection failure. For teams handling recurring domains and senders, Palisade is agentic DMARC software that analyzes DMARC aggregate-report data, identifies sending sources and authentication or alignment issues, and creates prioritized remediation tickets. It does not change the DMARC policy automatically, control an SMTP peer's TLS configuration, or guarantee delivery. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=email_transport_security&utm_content=gmail-tls-errors) ## Sources and further reading - [Google SMTP error reference for senders](https://support.google.com/mail/answer/3726730?hl=en) - [Google Workspace SMTP TLS versions and cipher suites](https://support.google.com/a/answer/9795993?hl=en) - [RFC 3207: SMTP Service Extension for Secure SMTP over Transport Layer Security](https://www.rfc-editor.org/rfc/rfc3207.html) - [RFC 8461: SMTP MTA Strict Transport Security](https://www.rfc-editor.org/rfc/rfc8461.html) - [Palisade MX records checker](/tools/mx) ## Frequently asked questions ### Does a Gmail TLS error mean my DMARC record is wrong? No. A TLS error concerns the SMTP transport connection. DMARC evaluates alignment and authentication results after message processing reaches the applicable authentication stage. ### Can an expired certificate cause a Gmail TLS error? Yes. A certificate that is expired, not yet valid, incomplete, untrusted, or mismatched to the contacted MX hostname can prevent successful certificate validation. Confirm the exact host from SMTP evidence before replacing a certificate. ### Can a public MX lookup prove Gmail can deliver mail? No. An MX lookup shows publicly published routing records. It cannot prove port 25 availability, STARTTLS support, the certificate presented to Gmail, Gmail's private delivery decision, or inbox placement. ### Does MTA-STS enforce mode block fallback to a bad TLS route? Yes. Under RFC 8461, a policy-aware sender using an `enforce` policy must use TLS and validate an MX host and certificate that meet the policy. The sender can defer delivery if those requirements are not met. ### Should I lower my DMARC policy to fix a TLS error? No. Lowering the DMARC policy changes requested DMARC enforcement. It does not repair STARTTLS capability, TLS compatibility, certificates, MX routing, or MTA-STS policy mismatches. --- # How can I create a DMARC record in DNS with Palisade? Canonical: https://www.palisade.email/learning/how-can-i-create-a-dmarc-record-in-dns-with-palisade > Create a DMARC record in DNS with Palisade, publish the correct TXT value, check the public record, and safely validate real sender alignment. To create a DMARC record in DNS with Palisade, publish one TXT record at `_dmarc.yourdomain.com`, then use the [Palisade DMARC checker](/tools/dmarc) to inspect the public record returned for that domain. Start with a monitored policy while you validate each real sending path. A public DNS result confirms the policy receivers can retrieve, but it does not prove that a sender has aligned SPF or DKIM. ## Quick takeaways - A DMARC policy is one TXT record published at `_dmarc.yourdomain.com`. - The `v=DMARC1` tag must be first, and the `p=` tag states the requested policy. - `p=none` requests monitoring, while `p=quarantine` and `p=reject` request enforcement. - Keep a DNS change record before publication so the owner, value, approval, and follow-up are clear. - A public lookup validates record visibility, not sender configuration, delivered-message authentication, or inbox placement. - Move toward enforcement only after reviewing sender evidence and DMARC aggregate-report data. ## What this tool checks The [Palisade DMARC checker](/tools/dmarc) performs a public lookup for the DMARC TXT record associated with the domain you enter. Use it to compare the public DNS answer with the record your DNS provider should publish. [RFC 9989 defines DMARC record discovery at the `_dmarc` subdomain and the DMARC policy tags](https://www.rfc-editor.org/rfc/rfc9989.html). The checker can inspect the DNS layer. It cannot inspect a sending platform's private configuration, prove that an application signs mail, show the `Authentication-Results` from a delivered message, or reveal a receiver's private filtering decision. Use the checker after a change, not as proof that the entire sending path works. The [DMARC learning hub](/learning/dmarc) has related guidance for policy rollout and sender investigation. ## How to run the check ### 1. Identify the visible From domain Use the domain after `@` in the visible `From:` address that recipients receive. DMARC evaluates alignment against that domain, which can differ from an envelope sender or a provider-owned sending domain. Treat each visible From domain as its own setup and validation task. A DMARC record for `yourdomain.com` does not automatically apply to `otherdomain.com`. ### 2. Draft the record and log the proposed DNS change Create a record that starts with `v=DMARC1` and uses the policy appropriate to your current evidence. This example is illustrative only. Do not publish it unchanged, and do not use a reporting mailbox you do not control. ```text _dmarc.yourdomain.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com" ``` In this example, `v=DMARC1` identifies the DMARC record version, `p=none` requests monitoring, and `rua` requests aggregate reports at the named mailbox. [RFC 9989 describes these tags and the allowed policy values](https://www.rfc-editor.org/rfc/rfc9989.html). Record the change before publishing it. This creates an auditable handoff between the person drafting the policy and the person responsible for the DNS zone. - **Organizational domain:** `yourdomain.com` - **DNS provider or zone owner:** the provider and account responsible for the authoritative zone - **Exact owner name:** `_dmarc.yourdomain.com` - **Proposed record value:** `v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com` - **Purpose of each tag:** `v` identifies DMARC, `p` requests the receiver policy, and `rua` names the aggregate-report destination - **Approver or change ticket:** your approved change record, such as `CHG-0000` - **Publish time:** the planned UTC publication time - **DNS verification result:** the returned authoritative and public DNS answers after publication - **Real-message or report follow-up date:** the date to inspect a new message from each active sender and later review aggregate reports The same structure works when adding optional tags. Keep the exact final TXT value in the record, rather than paraphrasing it in a ticket. ![Illustrative DMARC DNS record showing the required owner name and a monitoring policy](/images/editorial/how-can-i-create-a-dmarc-record-in-dns-with-palisade/how-can-i-create-a-dmarc-record-in-dns-with-palisade-record-shape.webp "1200x400") *Source: Palisade.* ### 3. Create one TXT record in the authoritative DNS zone Open the DNS zone for the visible From domain and add a TXT record. Some DNS interfaces append the zone name automatically. In those interfaces, enter `_dmarc` as the host. If the interface requires a fully qualified owner name, enter `_dmarc.yourdomain.com`. Paste the final TXT value exactly as approved. Do not add the domain twice. A provider that appends `yourdomain.com` to an entered `_dmarc.yourdomain.com` can publish the wrong owner name. > Publish only one DMARC TXT record at the `_dmarc` owner name. Multiple DMARC records at that name can leave a receiver unable to select a valid DMARC policy. ### 4. Check the public DNS answer Enter the visible From domain in the Palisade DMARC checker and compare its returned record with the approved value in the DNS change record. You can also repeat the public lookup independently: ```bash dig +short TXT _dmarc.yourdomain.com ``` A public answer can remain cached until the record's TTL expires. Compare the result with the authoritative DNS provider before treating an earlier public answer as a failed publication. ## How to interpret the results ### A DMARC record is returned A returned record means the lookup found public TXT data at the expected DMARC owner name. Compare the entire string with the approved value. Check that `v=DMARC1` is first, the policy is intentional, and the `rua` mailbox belongs to your organization. This is syntax and publication evidence. It does not establish that a specific sender aligns. To make that conclusion, inspect a delivered message from that sender and its receiver-added authentication results. ### No DMARC record is returned Confirm that you entered the visible From domain and that the DNS owner is `_dmarc.yourdomain.com`. Check whether the provider expects `_dmarc` or a fully qualified name, then inspect the authoritative zone for accidental duplication. If the record was just saved, note the publication time and TTL in the change record. Retest after the relevant cache period instead of creating another TXT record. ### The returned record differs from the approved value Treat a mismatch as a DNS publishing issue until the authoritative answer explains it. Common causes include editing the wrong zone, retaining an older TXT value, or publishing the host name in a form the provider expanded twice. Correct the single authoritative record, update the change record with the observed result, and repeat the same lookup. ## How to act on the result ### No record or an incorrect owner name Correct the TXT owner name in the authoritative zone first. Use `_dmarc` only where the provider appends the domain automatically. Then validate with the authoritative provider and a public resolver. ### A monitoring policy is published With `p=none`, keep the DNS record in place and move to evidence from each active sender. Confirm the sender's own authentication setup, send a real message through the production route, and inspect the recipient's `Authentication-Results` header. [RFC 8601 defines the message header field used to report authentication results](https://www.rfc-editor.org/rfc/rfc8601.html). A specific message passes DMARC when either SPF or DKIM passes and aligns with the visible From domain. A correctly formatted record does not make that happen. If you need to separate DNS publication from message signing, the [DKIM record setup guide](/learning/add-dkim-record-godaddy) explains why both checks matter. ### You are considering quarantine or reject Do not choose an enforcement policy because the DNS record looks valid. First identify legitimate senders, validate a delivered message from each production path, and review DMARC aggregate reports after they accumulate. The [DMARC setup guide](/dmarc-setup) provides additional rollout context. Use the DNS change record to document the evidence reviewed, the intended policy change, the approver, and the rollback value. A policy change is a human-controlled DNS change. Palisade does not autonomously change the DMARC policy. ## How to retest Repeat the same Palisade DMARC checker lookup after the authoritative DNS record changes. The expected DNS result is the exact approved `v=DMARC1` TXT value at `_dmarc.yourdomain.com`. Then validate the other layers separately: - **DNS:** Compare the authoritative answer and a public resolver answer. - **Vendor:** Check each sending service's current domain-authentication or verification status. - **Message:** Send a new message through the same production path and inspect its `Authentication-Results`. - **DMARC:** Review aggregate-report data after reports accumulate. A green public DNS result is not proof that an application used an aligned envelope sender or that a receiver will place future messages in the inbox. ## Track sender alignment after the DNS record is live The public record is one part of the work. The remaining question is which production senders still fail authentication or alignment as reports arrive. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=existing_content_migration&utm_content=how-can-i-create-a-dmarc-record-in-dns-with-palisade) to analyze DMARC aggregate-report data, identify sending sources and alignment issues, and create prioritized remediation tickets before a human reviews and applies a policy change. Palisade does not autonomously publish DNS changes, prove every future message will authenticate, or guarantee inbox placement. ## Sources and further reading - [RFC 9989: Domain-based Message Authentication, Reporting, and Conformance](https://www.rfc-editor.org/rfc/rfc9989.html) - [RFC 8601: Message Authentication Status](https://www.rfc-editor.org/rfc/rfc8601.html) - [Palisade DMARC checker](/tools/dmarc) - [Palisade documentation](https://docs.palisade.email/) ## Frequently asked questions ### Where do I publish a DMARC record? Publish the DMARC TXT record at `_dmarc.yourdomain.com`, where `yourdomain.com` is the domain in the visible From address you want to protect. ### Can I publish more than one DMARC TXT record? No. Publish one DMARC record at the `_dmarc` owner name for the domain. Multiple DMARC TXT records can prevent a receiver from selecting a valid policy. ### Does a valid DMARC record prove my email passes DMARC? No. A valid public record proves that receivers can retrieve the policy. You still need a delivered message from each production sender to confirm aligned SPF or DKIM authentication. ### Should I start with p=none? Yes, when you still need to identify legitimate sending sources and validate their authentication. `p=none` requests monitoring rather than quarantine or rejection. ### When can I move to p=quarantine or p=reject? Only after you have reviewed sender configuration, delivered-message evidence, and DMARC aggregate-report data for the production sources that use the domain. A DNS check alone is insufficient evidence for enforcement. --- # How can I send secure email using Outlook? Canonical: https://www.palisade.email/learning/how-can-i-send-secure-email-using-outlook > How can I send secure email using Outlook? Choose Encrypt or a published sensitivity label, test recipient access, and validate domain authentication. To send secure email using Outlook, compose a message, select **Options > Encrypt** and choose an available protection option, or apply a published sensitivity label in the compose window. The available controls depend on your Microsoft 365 tenant, license, Outlook client, and administrator configuration. Copy no settings from another tenant, then send a harmless test message to a representative recipient to confirm they can open it. ## Quick takeaways - Outlook protection controls can include **Encrypt** and **Sensitivity**, depending on Microsoft 365 configuration. - A published sensitivity label applies the protection settings your administrator configured for that label. - Microsoft Purview Message Encryption protects message content, but it does not establish DMARC authentication for the visible From domain. - S/MIME requires an organization-managed certificate workflow and compatible clients. - A selected Outlook protection option does not prove that an external recipient can access the message. - Validate public DNS, Microsoft 365 status, a delivered message, and DMARC reporting as separate checks. ## What should I check before configuring Outlook? Confirm that Outlook is the actual sending path in scope. This guide covers a person composing mail from a Microsoft 365 mailbox. It does not configure encryption for an application using SMTP relay, a transactional email service, or a marketing platform that sends with your domain. Check that you can use the intended Outlook client, that your administrator has enabled the relevant Microsoft 365 capabilities, and that you can send harmless test content to a representative recipient. Microsoft's [security and compliance guidance for new Outlook for Windows](https://learn.microsoft.com/en-us/microsoft-365-apps/outlook/security/security-compliance) documents the compose-window **Encrypt** and **Sensitivity** controls. Sensitivity labels are organization policy. Administrators create, configure, and publish [Microsoft Purview sensitivity labels](https://learn.microsoft.com/en-us/purview/sensitivity-labels), so a sender cannot create a replacement label from the Outlook compose window. If the organization plans to use S/MIME, confirm its certificate and client-support process before changing user settings. > Copy DNS values from the account and domain you are configuring. Do not publish selectors, targets, tokens, or hostnames from another account or from an online example. ## Which setup method should I use? Use **Encrypt** when you need to protect an individual message and your tenant exposes an option that matches the intended sharing requirement. Microsoft describes [Microsoft Purview Message Encryption](https://learn.microsoft.com/en-us/purview/ome) as an email-encryption service that helps protect messages sent inside or outside the organization. Use a **Sensitivity** label when the message belongs to an existing classification policy. The label can apply the protection behavior configured by your administrator, so the sender should select only a label published to their account. Use S/MIME only after the organization has established its certificate workflow and confirmed support for the Outlook client and recipient path. Do not infer S/MIME availability from the presence of a different Outlook protection control. The compose path below was verified from Microsoft's documentation, not from a live tenant. ![Outlook compose window showing the Encrypt menu used to choose a message protection option](/images/editorial/how-can-i-send-secure-email-using-outlook/outlook-compose-encrypt-options.png "700x409") *Source: [Security and compliance in new Outlook for Windows](https://learn.microsoft.com/en-us/microsoft-365-apps/outlook/security/security-compliance), checked 2026-08-11.* ### Decision and evidence record Record the choice before sending. This separates a recipient-access problem from a tenant setting, Outlook client limitation, or message-routing issue. - **Sensitivity and recipient requirement:** Record the information classification and whether the recipient is internal or external. - **Selected method:** Record **Encrypt**, the exact published sensitivity label, or S/MIME. - **Account and client context:** Record the sending mailbox, Microsoft 365 tenant, and Outlook client used for the test. - **Recipient access condition:** Identify the test recipient and the access path they are expected to use. - **Sent-message proof:** Retain the send time, visible From address, recipient domain, selected option, and a redacted confirmation of the recipient outcome. - **Prerequisite:** Record the applicable tenant policy, published-label requirement, or certificate requirement. ## How do I configure secure email in Outlook? ### 1. Open a new message from the mailbox you will test Create a new message from the same mailbox and through the normal route that will send protected email. Confirm the visible From address before proceeding, especially when using a shared mailbox or a domain with several sending identities. A personal-mailbox test does not validate a shared mailbox, application relay, or a different domain. If the organization has multiple Outlook clients, record which client is used because the available controls can differ. ### 2. Select Encrypt or a published sensitivity label In new Outlook for Windows, open **Options > Encrypt** and choose the available protection option that fits the message. If the organization uses labels, select **Sensitivity** in the compose window and choose the appropriate published label. Microsoft shows both controls in its [Outlook security and compliance documentation](https://learn.microsoft.com/en-us/microsoft-365-apps/outlook/security/security-compliance). Use the exact choice available in the tenant. Do not copy label names, restrictions, or access assumptions from another organization. ![Outlook compose window showing the Sensitivity control and available label choices](/images/editorial/how-can-i-send-secure-email-using-outlook/outlook-compose-sensitivity-label.png "700x488") *Source: [Security and compliance in new Outlook for Windows](https://learn.microsoft.com/en-us/microsoft-365-apps/outlook/security/security-compliance), checked 2026-08-11.* ### 3. Review recipients and use a safe subject line Review every recipient before sending. Encryption cannot correct an incorrectly addressed message. Use a subject line that does not disclose information that should remain protected. For external mail, arrange a test with a recipient who represents the access path you need to support. Their result helps distinguish recipient access from a typo, mail-flow rule, or provider filtering decision. ### 4. Send a new test message and capture the outcome Send harmless test content to the representative recipient. Ask them to use their normal mail client or supported access path, then confirm what they can open. Keep a redacted record of the selected method, send time, sender, recipient domain, and recipient outcome. A message sent before the protection choice changed is not evidence for the current configuration. ### 5. Check the sending domain's authentication separately Message encryption and rights controls do not establish that the visible From domain is authorized to send the message. DMARC evaluates whether SPF or DKIM passed and aligned with that visible From domain. [RFC 9989 defines DMARC identifier alignment](https://www.rfc-editor.org/rfc/rfc9989.html). A DMARC record has this structural form: ```text Record type: TXT Host: _dmarc.yourdomain.com Value: v=DMARC1; p=none ``` > Do not publish this example as a production policy. Use the record for your own domain and assess real sending sources before moving beyond monitoring. ![Example DMARC record fields used to separate Outlook message protection from domain authentication](/images/editorial/how-can-i-send-secure-email-using-outlook/how-can-i-send-secure-email-using-outlook-dmarc-record.webp "1200x466") *Source: Palisade.* Read the [email authentication learning center](/learning) for the relationship between Outlook mail, SPF, DKIM, and DMARC. If you have the visible From domain, use Palisade's [DMARC checker](/tools/dmarc) to inspect its public DMARC record. A public DNS check does not prove the production Outlook path, a recipient's private decision, or future inbox placement. ## How does this setup affect DMARC? For an Outlook-sent message to pass DMARC through DKIM, the DKIM signing domain must align with the visible From domain. For SPF, the authenticated RFC 5321 MailFrom domain must align with that same visible From domain. RFC 9989 defines both alignment paths, and a passing authentication result for an unrelated domain does not satisfy DMARC. Use a real delivered message to identify the actual path. [RFC 8601 defines the `Authentication-Results` field and its trust boundary](https://www.rfc-editor.org/rfc/rfc8601.html). Inspect results added by the receiving system you trust, rather than treating a copied header from an unknown intermediary as proof. Outlook protection and domain authentication solve different problems. Encryption helps control access to message content. SPF, DKIM, and DMARC help receivers evaluate whether mail using a domain is authenticated. If Outlook messages reach junk, compare the delivered headers and recipient evidence with the practical causes in [How to stop emails going to spam in Outlook](/email-deliverability/how-to-stop-emails-going-to-spam-in-outlook). ## How do I validate the setup? ### Check public DNS Query the domain's published DMARC record through the authoritative DNS service and at least one public resolver. Compare the answers before changing policy. ```bash dig +short TXT _dmarc.yourdomain.com ``` This checks published DNS only. It does not show whether Outlook is signing a specific message or using the expected return path. ### Check the Microsoft 365 sender-side status Return to the same Outlook compose window and mailbox used for the test. Confirm that the selected **Encrypt** option or published **Sensitivity** label remains available, then record its exact displayed name and the client used. If the option or label is absent, stop and ask the Microsoft 365 administrator to check the tenant policy and label publication. This verifies the documented sender-side configuration available to that mailbox. It does not prove recipient access or delivered-message authentication. ### Inspect a delivered message Open the raw source of a newly delivered test message. Confirm the visible From domain, then inspect the trusted receiver-added `Authentication-Results` header for `spf=`, `dkim=`, and `dmarc=` outcomes. Record only redacted headers in the change record. The result should match the path you tested. If a shared mailbox, outbound gateway, or alternate domain sends mail differently, repeat the test for that route. ### Review DMARC reports After aggregate reports arrive, review whether Microsoft 365 traffic passes SPF or DKIM and aligns with the visible From domain. Separate expected Microsoft 365 traffic from other systems that use the domain. A single successful Outlook test does not inventory every sender. The same distinction matters when investigating why mail goes to junk in [Hotmail and Outlook](/email-deliverability/why-do-emails-go-to-junk-in-hotmail-outlook). ## Troubleshooting ### Encrypt is missing from the compose window Confirm the Outlook client and the mailbox used for the test. Microsoft's documented controls are subject to Microsoft 365 configuration. Ask the administrator to check whether the relevant encryption capability is enabled for that user before changing DNS or mail flow. ### A sensitivity label is missing Use only labels published to the sender. Microsoft documents that sensitivity labels are configured and published by administrators. Ask the label administrator to verify the label policy and the user's scope. ### The recipient cannot open the protected message Compare the recipient's result with the selected Outlook option, recipient type, and normal access path. Repeat with harmless content and a representative recipient. Do not weaken protection based only on an unverified report from a different client or recipient domain. ### The message is protected but DMARC fails Inspect the new message's trusted `Authentication-Results` header. Compare the SPF MailFrom domain and DKIM `d=` domain with the visible From domain. A valid protection choice does not repair an authentication or alignment problem. ### Outlook mail passes DMARC but reaches junk DMARC is one authentication signal, not a guarantee of inbox placement. Preserve the delivered headers and use recipient-side evidence to investigate the actual filtering result. The workflow for [sending a secure email in Gmail](/learning/how-do-i-send-a-secure-email-in-gmail) is also separate because a different sender interface can use a different authentication path. ## Track the sending sources behind the Outlook test The Outlook test confirms one mailbox, client, recipient, and moment in time. It does not show every service that sends with the same domain, which sources later fail alignment, or when the domain appears ready for a safer DMARC policy. Palisade is agentic DMARC software that analyzes DMARC aggregate-report data, identifies sending sources and authentication or alignment issues, and creates prioritized remediation tickets. It can propose the next policy step after a human reviews the evidence and applies the DNS change. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=existing_content_migration&utm_content=how-can-i-send-secure-email-using-outlook). Palisade does not change the DMARC policy on its own, prove recipient access to an Outlook-protected message, or guarantee delivery or inbox placement. For a provider-specific implementation of these authentication checks, see [Zix email security: what the name means today](/learning/zix-email-security). ## Sources and further reading - [Microsoft security and compliance in new Outlook for Windows](https://learn.microsoft.com/en-us/microsoft-365-apps/outlook/security/security-compliance) - [Microsoft Purview Message Encryption documentation](https://learn.microsoft.com/en-us/purview/ome) - [Microsoft Purview sensitivity labels documentation](https://learn.microsoft.com/en-us/purview/sensitivity-labels) - [RFC 9989: Domain-based Message Authentication, Reporting, and Conformance](https://www.rfc-editor.org/rfc/rfc9989.html) - [RFC 8601: Message Header Field for Indicating Message Authentication Status](https://www.rfc-editor.org/rfc/rfc8601.html) ## Frequently asked questions ### Can Outlook encrypt an email sent to an external recipient? Yes, if the Microsoft 365 tenant provides an encryption option that supports the recipient scenario. Select the available option, send harmless test content to a representative external recipient, and confirm their actual access result. ### Does a sensitivity label encrypt every Outlook email? Only if the administrator configured that published label to apply encryption or other protection. A label's name alone does not prove its protection behavior, so use the organization's documented label policy. ### Does encrypting an Outlook email make it pass DMARC? No. Outlook encryption protects message content and access. DMARC requires an aligned SPF or DKIM result for the visible From domain, which must be checked in a delivered message and later in DMARC reporting. ### Can I use S/MIME in every Outlook client? No. S/MIME requires certificates and compatible client and recipient support. Confirm the organization's certificate workflow and the supported Outlook experience before making it the required method. ### Is a green Microsoft 365 setting enough to prove secure delivery? No. It shows that the selected sender-side control is available or accepted for that mailbox. Test recipient access, inspect a newly delivered message, and review domain authentication separately. --- # How can I take down lookalike domains targeting my business? Canonical: https://www.palisade.email/learning/how-can-i-take-down-lookalike-domains > Take down lookalike domains by preserving evidence, reporting the active service, and escalating phishing or trademark abuse safely, step by step. To take down a lookalike domain targeting your business, preserve evidence first, identify the registrar and any service delivering harmful content, then report the case to the party able to investigate it. Escalate active credential or payment theft quickly through phishing-reporting channels. Use trademark or domain-dispute processes for bad-faith brand abuse. No report guarantees that a registrar, host, or browser-security service will remove a domain. ## Quick takeaways - Preserve the exact URL, capture time, screenshots, redirect chain, original email, and full headers before reporting a lookalike domain. - A registrar controls registration, while a hosting provider, CDN, or content platform may be able to remove a live harmful page. - Public DNS and domain observations can help route an abuse report, but they do not prove ownership, malicious intent, or a takedown outcome. - Treat active credential collection, payment fraud, and malware as urgent phishing incidents alongside any brand-protection case. - A UDRP dispute can address certain bad-faith trademark registrations, but it is not an emergency process for removing a live phishing page. - DMARC helps protect your legitimate domain from unauthorized spoofing. It does not remove mail or websites using a separately registered lookalike domain. ## Scope and prerequisites Use this process for one suspicious domain that appears to impersonate your organization, staff, products, or payment process. Start with an observable harm: a credential-collection page, fraudulent payment instructions, a copied brand page, or an email sent from a confusingly similar domain. Assign an incident owner, an authorized reporter, and a legal contact for trademark or fraud escalation. Preserve the evidence in an access-controlled case location. The rollback condition is procedural: do not request suspension of a domain until a reviewer has confirmed the suspicious domain is not your own, a partner's, or an authorized campaign domain. A mistaken report can disrupt a legitimate business. For broader guidance on reducing email-borne impersonation risk, see the [Palisade email security learning hub](/learning). ### Create a case record after triage Create a labelled record before reports begin. It keeps evidence, ownership, and follow-up decisions tied to the same incident. ```text Case ID: LKD-2026-001 Suspected domain and URL: pay-yourdomain-example.com / https://pay-yourdomain-example.com/sign-in Legitimate brand domain: yourdomain.com Observed impersonation evidence: Redacted page screenshot uses our business name and asks for account credentials Captured at: 2026-08-12T14:20:00Z Registrar, hosting, and DNS evidence: Public NS and A-record observations retained with timestamps Abuse or report destination: <provider or security reporting channel> Case or reference ID: <submitted-report identifier> Owner: <incident owner> Escalation status: Evidence preserved, report pending review Follow-up date: 2026-08-13 ``` This example is fictional and redacted. Do not recreate a harmful page, submit credentials, download files, or interact with suspected malware. ## Choose the implementation approach Choose the reporting route from the evidence you have. - For active credential, payment, or malware risk, report the harmful URL to the hosting or platform provider when identifiable. Also use the relevant phishing-reporting channels. [CISA phishing guidance](https://www.cisa.gov/topics/cyber-threats-and-advisories/malware-phishing-and-ransomware) recommends reporting suspected phishing and preserving evidence for investigation. - For a domain where public registration or DNS evidence helps identify an abuse contact, use the registrar's published abuse process. [ICANN SSAC report SAC-115 on DNS abuse](https://www.icann.org/en/system/files/files/sac-115-en.pdf) describe DNS abuse categories that include phishing, malware, botnets, pharming, and spam when spam is used as a delivery mechanism for those threats. - For trademark or brand abuse without an immediate safety threat, have legal counsel assess the evidence and available remedies. [WIPO's UDRP overview](https://www.wipo.int/en/web/amc/domain-name-disputes/search/overview/index) explains the factors considered in Uniform Domain Name Dispute Resolution Policy cases. A single case can need more than one route. A host might remove a credential-harvesting page while the registrar leaves the registration active. A domain dispute may address the registration later, but it should not delay reporting active phishing. ![Flow showing evidence collection and escalation branches for a lookalike-domain incident](/images/editorial/how-can-i-take-down-lookalike-domains/how-can-i-take-down-lookalike-domains-evidence-escalation-flow.webp "1200x829") *Source: Palisade.* ## How to configure the response ### 1. Preserve evidence before contacting providers Capture the full suspicious URL, including its path and query string, plus the time observed in UTC. Save screenshots that include the browser address bar and the harmful content. Record every redirect destination. Keep customer reports in their original form where possible, but remove passwords, payment details, session cookies, private keys, API tokens, and other unnecessary private data before broad sharing. For a phishing email, preserve the original message and full headers. Do not rely only on a screenshot if the original message is available. [RFC 8601 defines the Authentication-Results header field](https://www.rfc-editor.org/rfc/rfc8601.html) and explains that it is receiver-generated information with a trust boundary. A header can help explain how a receiver evaluated a message, but it does not establish who registered a lookalike domain. If a staff member opened a suspected credential or malware page, follow your organization’s incident-response procedure. Do not use the suspicious site to collect more evidence. ### 2. Confirm the legitimate domain and observe public infrastructure Confirm that the suspicious domain is not an approved domain owned by your organization, a reseller, a campaign provider, or a business partner. Record the legitimate brand domain in the case record so reviewers can compare the names without relying on memory. Then collect publicly available DNS evidence. A DNS observation can establish that a queried name returned a record at a particular time, and may identify name servers, mail exchangers, or an IP address. It cannot establish the registrant's identity, prove the operator's intent, reveal every service behind the domain, or require any provider to take it down. Use a public lookup only with domain or DNS inputs you already have. The [Palisade DNS lookup](/tools/dns-lookup) can inspect public DNS records for the suspicious domain, and the [domain reputation checker](/tools/domain-reputation) can check public reputation signals. Save timestamps and observed results in the case record. ```bash dig +short A suspicious-yourdomain.com dig +short MX suspicious-yourdomain.com dig +short NS suspicious-yourdomain.com ``` > Do not treat an IP address or name server as proof of malicious ownership. Shared hosting, privacy services, CDNs, and infrastructure changes can make public observations incomplete or time-sensitive. If the site redirects, record the final destination. Do not attempt to log in, submit forms, upload files, download samples, or contact the suspicious operator. ### 3. Route the report to the party that can act Submit the smallest complete evidence package to the provider or channel that can investigate the reported behavior. State the affected brand, exact URL or domain, observation time, observed harm, and requested action. Keep the provider confirmation and case number. For an active page, report the content to the identified host, CDN, or platform using its documented abuse route. For a registration concern, use the registrar’s published abuse contact. ICANN’s Registrar Accreditation Agreement requires accredited registrars to publish an abuse contact and investigate reports of abuse involving registered names. [ICANN's registrar abuse-contact requirements](https://www.icann.org/resources/pages/registrars/consensus-policies-en) provide the applicable policy context. Use careful language. If your evidence supports suspected phishing, report suspected phishing. Do not state that a specific person committed a crime unless you have evidence and authority to make that claim. ```text Subject: Suspected phishing and brand impersonation at suspicious-yourdomain.com We observed https://suspicious-yourdomain.com/sign-in at <UTC timestamp>. The page appears to impersonate <business name> and requests credentials. Affected legitimate domain: yourdomain.com Evidence retained: <redacted screenshots, redirect chain, original email headers if applicable> Requested action: Please investigate the reported content under your abuse process and advise whether it has been disabled. Contact for follow-up: <authorized business contact> ``` A report requests an investigation. It does not prove that the receiving provider hosts the content, controls the registration, or will remove the domain. ### 4. Escalate active credential or payment risk If the page collects credentials, payment information, or malware downloads, prioritize reports that can reduce user exposure. Send the exact harmful URL and capture time to the relevant platform or security-reporting channel. Update the case record with the submission reference and a near-term follow-up date. If a phishing email was sent to your organization, report it through the recipient mailbox provider’s available phishing-reporting path as well as the infrastructure route when known. Preserve the original message separately from the report package. Tell affected employees, customers, or partners only through approved incident communications. Describe the known facts, the legitimate domain, and the safe action. Do not amplify the suspicious URL unnecessarily. ### 5. Escalate trademark or brand abuse For a copied brand site or confusing registration without an immediate phishing threat, preserve the mark evidence, the domain’s use of the mark, and the timeline. Legal counsel can assess whether the facts support a trademark complaint, a registrar policy report, or a domain-name dispute. Under the UDRP, a complainant generally must establish that the disputed domain is identical or confusingly similar to a mark in which it has rights, that the respondent lacks rights or legitimate interests, and that the domain was registered and is being used in bad faith. [WIPO's UDRP overview of panel views](https://www.wipo.int/en/web/amc/domain-name-disputes/search/overview/index) explains these factors. This is a legal framework, not a conclusion about any individual case. ### 6. Recheck the reported URL and close only on evidence Recheck the exact URL after the provider’s stated review period. Record whether the original content remains available, redirects elsewhere, returns an error, or has changed. Recheck from an approved and safe investigation environment. Do not mark the incident resolved merely because a public DNS record still exists or because a page appears unavailable once. A domain can remain registered after content removal, and a public check cannot prove what every visitor or receiver sees. ## How to validate the setup Validate the response at four layers. - DNS: Query authoritative DNS and at least one public resolver when DNS evidence is relevant. Record the observed names, records, and timestamps. - Provider: Retain submission confirmations, reference IDs, and written provider responses. A submitted report is not a completed takedown. - Message or page: Recheck the exact email path or reported URL without interacting with the harmful service. Preserve the observed result and time. - Ongoing review: Keep the case open until the incident owner records what changed, what remains, and whether legal, customer-support, or security follow-up is still required. A useful closure record includes the provider response, the final observed URL result, the last DNS observation when relevant, and a decision owner. This process proves only the evidence you captured and the actions you took. It cannot prove future availability, private provider decisions, or future mail placement. ![Checklist for validating a lookalike-domain takedown response across DNS, providers, reported content, and follow-up](/images/editorial/how-can-i-take-down-lookalike-domains/how-can-i-take-down-lookalike-domains-validation-checklist.webp "1200x524") *Source: Palisade.* ## Troubleshooting ### The registrar does not appear to host the harmful page Report the registration concern to the registrar, then separately identify and report the provider delivering the active content. Registrars and hosts have different control points. Keep both report references in the same case record. ### Public DNS records do not identify a clear hosting provider Record the DNS answers and their timestamps, but do not infer ownership from them. Look for a documented abuse route from the registrar or a visible platform provider. If the incident includes active phishing, use relevant security-reporting channels while attribution remains incomplete. ### The provider asks for more evidence Provide the exact URL, observation time, redacted screenshots, redirect chain, and affected legitimate domain. Supply original [email headers](/tools/email-header-analyzer) only through an approved secure route. Do not share customer credentials, tokens, or unrelated internal records. ### The page is removed but the domain remains registered Treat content removal and registration status as separate outcomes. Record the removed page, recheck for changed paths or redirects, and ask legal counsel whether the remaining registration warrants a trademark or domain-dispute review. ## Check the public evidence before escalating Before filing a registrar or hosting report, inspect the suspicious domain’s public DNS and reputation signals. This can help preserve a time-stamped record and identify a possible reporting route, but it cannot prove ownership, malicious intent, an active production path, or that a provider will remove the domain. [Look up the suspicious domain](/tools/dns-lookup) For recurring lookalike-domain incidents, Palisade is DMARC software that analyzes DMARC aggregate-report data, identifies unauthorized sending sources and alignment issues, and creates prioritized remediation tickets for your legitimate domains. It helps a team understand and improve DMARC enforcement. It does not take down separately registered lookalike domains, change a registrar’s decision, or guarantee inbox placement. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=existing-content-migration&utm_content=how-can-i-take-down-lookalike-domains) ## Sources and further reading - [ICANN SSAC report SAC-115 on DNS abuse](https://www.icann.org/en/system/files/files/sac-115-en.pdf) - [ICANN consensus policies for registrars](https://www.icann.org/resources/pages/registrars/consensus-policies-en) - [CISA phishing guidance](https://www.cisa.gov/topics/cyber-threats-and-advisories/malware-phishing-and-ransomware) - [WIPO Overview of WIPO Panel Views on Selected UDRP Questions](https://www.wipo.int/en/web/amc/domain-name-disputes/search/overview/index) - [RFC 8601: Authentication-Results header field](https://www.rfc-editor.org/rfc/rfc8601.html) ## Frequently asked questions ### Can I force a registrar to take down a lookalike domain? No. You can submit a documented abuse report or pursue an applicable legal process, but the registrar decides its response under its policies and obligations. A host or platform may be the faster route for an active harmful page. ### Should I contact the operator of a suspicious lookalike domain? No. Do not contact a suspicious operator directly as part of initial triage. Preserve evidence, use documented abuse channels, and follow your incident-response or legal process. ### Does a DNS lookup prove who owns a lookalike domain? No. A public DNS lookup can show records returned at the time of the query. It cannot reliably establish registrant identity, beneficial ownership, malicious intent, or control over every service associated with the domain. ### Can DMARC stop a lookalike domain from sending email? No. DMARC helps receivers evaluate mail that claims to come from your legitimate domain. It does not block a separately registered lookalike domain, although DMARC enforcement can reduce direct spoofing of your exact domain. ### Is a UDRP complaint the right response to phishing? Only when the facts and legal strategy support a domain-name dispute. For an active credential-harvesting or malware page, report the harmful URL through relevant provider and phishing-reporting channels immediately. A UDRP process is not an emergency takedown mechanism. --- # How can you protect your brand from impersonation with anti-spoofing? Canonical: https://www.palisade.email/learning/how-can-you-protect-your-brand-from-impersonation-with-anti-spoofing > Protect your brand from impersonation with anti-spoofing by aligning SPF and DKIM, enforcing DMARC carefully, and recording response evidence. Protect your brand from exact-domain email impersonation by configuring SPF and DKIM for every legitimate sender, then using DMARC reports to verify alignment before enforcement. Begin with DMARC monitoring, resolve legitimate failures, and progress to quarantine and reject only when production evidence supports each stage. DMARC reduces spoofing that uses your visible domain. It does not stop lookalike domains, display-name abuse, or guarantee inbox placement. ## Quick takeaways - SPF authorizes hosts to use a domain during SMTP, while DKIM verifies a domain's cryptographic signature. - DMARC passes when SPF or DKIM passes and its authenticated domain aligns with the visible From domain. - A `p=none` DMARC policy collects aggregate-report evidence before enforcement. - A public DNS result does not prove that an application signs production mail or uses the intended return-path domain. - The safe DMARC progression is monitor first, then quarantine, then reject. - DMARC policy requests receiver handling for failed mail, but each receiver applies its own local policy. ## Scope and prerequisites This guide covers impersonation that uses your organization's exact visible From domain. DMARC is the anti-spoofing control, supported by SPF and DKIM. For related phishing, transport, and message-security controls, use the [email security learning center](/learning). Choose one production domain and inventory every system that sends as that domain. Include employee mail, transactional applications, support platforms, marketing systems, security gateways, and services that send on your behalf. For each path, record the visible From domain, SMTP return-path domain, DKIM signing domain, DNS-zone owner, application owner, and test recipient. You need access to the authoritative DNS zone, each sender's authentication settings, and a mailbox that can receive DMARC aggregate reports. [RFC 9989 defines DMARC policy discovery, alignment, and reporting](https://www.rfc-editor.org/rfc/rfc9989.html). SPF and DKIM are inputs to DMARC, so preserve their existing records during the rollout. Define a rollback condition before enforcement. If a legitimate production-path message fails after a policy change, restore the previous known-safe policy while you investigate the sender configuration. Keep a copy of the current DMARC record before editing it. > Do not advance to `p=quarantine` or `p=reject` because a public DNS lookup looks correct. DNS cannot prove that every production application uses the intended return-path domain or DKIM signing domain. ## Choose the implementation approach Use monitoring when you cannot yet account for every source that sends with the domain. A `p=none` policy asks receivers to send aggregate reports without requesting quarantine or rejection of failing mail. Use those reports to compare observed sources with your inventory and investigate authentication or alignment failures. Use quarantine after report evidence shows that legitimate production paths have an aligned SPF or DKIM pass. Quarantine is an intermediate enforcement stage. It gives you another evidence window before requesting the strictest policy. Use reject when the evidence remains stable and every remaining failure has an explanation. DMARC receivers can consider the domain owner's policy, but [RFC 9989 states that receiver handling remains a local policy decision](https://www.rfc-editor.org/rfc/rfc9989.html). A reject policy cannot guarantee that every failed message is rejected or that every passing message reaches the inbox. The authentication controls have separate jobs: - [RFC 7208 defines SPF](https://www.rfc-editor.org/rfc/rfc7208.html) as a DNS-published mechanism for authorizing hosts to use a domain during SMTP. - [RFC 6376 defines DKIM](https://www.rfc-editor.org/rfc/rfc6376.html) signatures and DNS lookup of the public key used to verify them. - DMARC evaluates whether a passing SPF domain or DKIM signing domain aligns with the visible From domain. One aligned pass can produce a DMARC pass. - Lookalike domains and display-name impersonation need separate detection, reporting, and receiver-response procedures. The [CISA phishing guidance](https://www.cisa.gov/topics/cyber-threats-and-advisories/malware-phishing-and-ransomware) describes phishing as a broader threat than one authentication control can eliminate. ## How to configure DMARC anti-spoofing controls ### 1. Inventory each production sending path Create one entry for every application or provider that can send as `yourdomain.com`. Keep paths separate when they use different return paths, DKIM selectors, signing domains, or routing gateways. For each source, retain a recent redacted message header and the expected sender configuration. Do not place private keys, API tokens, customer addresses, or unredacted headers in tickets or shared documentation. ### 2. Configure aligned SPF and DKIM for each sender Publish the SPF authorization required by each sender, but preserve the domain's existing SPF record. SPF permits one `v=spf1` record at a domain. Publishing a second SPF record can cause an SPF evaluation error. Enable DKIM in every sending system and publish the exact selector record it generates. The selector and public-key value are account-specific. Obtain them from the sender that signs the mail. Do not invent a selector or reuse a record value from another account. A DMARC record shape is below. It is illustrative only. Do not publish it unchanged. ```text _dmarc.yourdomain.com TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com" ``` The `rua` mailbox receives aggregate reports. Confirm that your organization controls and reviews it. If reports go to a mailbox under another domain, RFC 9989 defines an external reporting authorization process. ### 3. Publish a monitoring DMARC record Publish one DMARC TXT record at `_dmarc.yourdomain.com` with `p=none` and a valid aggregate-report destination. Compare the new record with the current record before making a change. Do not replace a working policy with the illustrative record. Document whether the record applies to the organizational domain, a specific subdomain, or both. A subdomain can publish its own DMARC record and policy, so its sending paths may require separate evidence. ![Flow showing an anti-spoofing rollout from sender inventory through DMARC monitoring, remediation, quarantine, and reject](/images/editorial/how-can-you-protect-your-brand-from-impersonation-with-anti-spoofing/how-can-you-protect-your-brand-from-impersonation-with-anti-spoofing-policy-rollout.webp "1200x829") *Source: Palisade.* ### 4. Collect reports and repair legitimate failures Allow aggregate reports to accumulate, then group results by sending source, visible From domain, SPF result and domain, DKIM result and signing domain. Compare each reported source with the sending-path inventory. Investigate every failure before escalating policy. Common causes include an omitted sender, an SPF domain that does not align, a DKIM signature from an unrelated domain, or forwarding that changes the SMTP path. Aggregate reports identify reported use of the domain and authentication results. They do not prove the content of every message, a receiver's private filtering decision, or activity at receivers that do not send reports. ### 5. Advance the DMARC policy after evidence supports it Move from monitoring to quarantine when legitimate production paths have an aligned SPF or DKIM pass and unexpected sources have been investigated. Continue reviewing aggregate reports after the policy change. Move from quarantine to reject only when the same evidence remains stable. Use a narrower rollout when a domain has many independent owners or uncertain senders. The safe progression is monitor first, then quarantine, then reject. ![DMARC evidence and response record showing the fields to capture during an impersonation review](/images/editorial/how-can-you-protect-your-brand-from-impersonation-with-anti-spoofing/how-can-you-protect-your-brand-from-impersonation-with-anti-spoofing-dmarc-evidence-response-record.webp "1200x754") *Source: Palisade.* ## Maintain an impersonation evidence and response record Use this Palisade-authored framework to keep the technical evidence and operational response connected. The record does not claim that DMARC will remove a lookalike domain, force a mailbox provider's decision, or guarantee a takedown. Record these fields for each incident or control review: - Protected brand domains: the exact domains and subdomains covered by the review. - Observed spoof or lookalike identifier: the visible From domain, display name, lookalike domain, URL, or other redacted identifier. - Evidence source and time: the DMARC aggregate report, redacted delivered header, public DNS lookup, customer report, employee report, or provider case, with UTC time. - DNS and authentication status: the observed DMARC, SPF, DKIM, and alignment result relevant to the domain. - Customer or employee impact scope: confirmed recipients, reported exposure, or `unknown` when evidence does not establish scope. - Owner and escalation: the person or team responsible for the technical change, investigation, or communications response. - Reporting or takedown channel: the applicable registrar, hosting provider, mailbox provider, abuse process, or law-enforcement channel where appropriate. - Follow-up date: the next date to review evidence, policy status, and any external case. A compact fictional and redacted example: ```yaml protected_brand_domains: - yourdomain.com observed_identifier: "yourdornain.com" evidence_source_time: "employee report with redacted message header, 2026-08-12T14:00:00Z" dns_authentication_status: "yourdomain.com has DMARC p=quarantine; lookalike domain is outside DMARC control" impact_scope: "unknown" owner_escalation: "security operations, registrar abuse review" reporting_takedown_channel: "registrar abuse form" follow_up_date: "2026-08-14" ``` Technical anti-spoofing controls protect domains you control. Reporting and takedown actions address external infrastructure or content and depend on the receiving organization, provider, registrar, or other party's process and decision. ## How to validate the setup Validate the DMARC anti-spoofing setup at four separate layers. A passing result at one layer does not replace another. - DNS: Query the authoritative DNS server and a public resolver for `_dmarc.yourdomain.com`. Confirm that one intended DMARC record is returned. - Sender state: Confirm that each production sender has its intended SPF authorization or DKIM signing configuration. A sender's verified status is useful evidence, but it is not a delivered-message result. - Message: Send a new message through every production path and inspect the receiver-added `Authentication-Results` header. [RFC 8601 defines the Authentication-Results header field](https://www.rfc-editor.org/rfc/rfc8601.html). Record the visible From domain and the SPF or DKIM domain that passed. - DMARC reporting: Compare aggregate reports with the inventory. Each expected source needs an understood authentication and alignment result before strict enforcement. For the DNS layer, [inspect the published DMARC record](/tools/dmarc) before changing the policy. A public record check cannot confirm a sender's private configuration, prove a delivered message authenticated, monitor later DNS drift, or reveal a receiver's private filtering decision. ## Troubleshooting ### A DMARC record is published but a legitimate sender fails Inspect a new delivered message from the exact production path. Compare the visible From domain with the `smtp.mailfrom` SPF domain and the DKIM `d=` domain in the receiver's authentication results. A passing SPF or DKIM result that does not align with the visible From domain does not produce that aligned DMARC pass. ### SPF passes for some mail but fails after adding a sender Check that the domain has one combined `v=spf1` record. Merge the authorized mechanisms required by legitimate senders into that existing record according to their current documentation. Do not publish a second SPF record. ### DKIM passes but DMARC still fails Compare the DKIM `d=` domain with the visible From domain. DKIM can be cryptographically valid while remaining unaligned for DMARC. Confirm that the sender uses the intended signing domain and selector. ### A lookalike domain is still sending phishing mail DMARC at `yourdomain.com` cannot control a separate registered domain. Preserve the evidence, record the relevant reporting or takedown channel, and use the provider's or registrar's abuse process where applicable. Continue enforcing DMARC on domains you control because it reduces exact-domain impersonation, but do not describe that control as proof of lookalike removal. ### A receiver still accepts mail that fails DMARC DMARC policy is a request to receivers, not a guarantee of a specific filtering outcome. Confirm that the visible From domain and authentication evidence match the policy you published, then use the receiver's own reporting or support channel if you need to investigate its decision. ## Check the public DMARC record before enforcing policy Run the protected domain through the [DMARC checker](/tools/dmarc) to inspect its public DMARC record before moving from monitoring to quarantine or reject. Compare that record with aggregate-report evidence and a newly delivered production message. [Check the DMARC record](/tools/dmarc) The checker sees public DNS only. It cannot identify every production sender, repair alignment, prove a receiver's decision, or guarantee that impersonation attempts will stop. For teams that need to analyze aggregate-report data across recurring sender changes, Palisade is agentic DMARC software that identifies sending sources and authentication or alignment issues, creates prioritized remediation tickets, and proposes the next policy step for human review. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=email_authentication&utm_content=how-can-you-protect-your-brand-from-impersonation-with-anti-spoofing) For a broader response plan, see [How to Stop Email Spoofing and Protect Your Brand](/learning/what-is-email-spoofing-and-how-can-you-prevent-it). ## Sources and further reading - [RFC 9989: Domain-based Message Authentication, Reporting, and Conformance](https://www.rfc-editor.org/rfc/rfc9989.html) - [RFC 7208: Sender Policy Framework](https://www.rfc-editor.org/rfc/rfc7208.html) - [RFC 6376: DomainKeys Identified Mail Signatures](https://www.rfc-editor.org/rfc/rfc6376.html) - [RFC 8601: Authentication-Results header field](https://www.rfc-editor.org/rfc/rfc8601.html) - [CISA phishing guidance](https://www.cisa.gov/topics/cyber-threats-and-advisories/malware-phishing-and-ransomware) ## Frequently asked questions ### Does DMARC stop all brand impersonation? No. DMARC helps receivers identify mail that claims to come from a domain you control but fails aligned SPF and DKIM checks. It does not control lookalike domains, display-name impersonation, compromised accounts, or a receiver's private filtering decision. ### Should I start DMARC with reject? No. Start with `p=none` so aggregate reports can identify legitimate senders and alignment failures. Advance to quarantine and then reject only after report and delivered-message evidence supports each stage. ### Does a passing DMARC lookup prove my email is protected? No. A DNS lookup confirms the public record that resolves at the time of the check. It does not prove that every sender uses aligned SPF or DKIM, that a receiver honors the requested policy, or that future messages will authenticate. ### Can SPF alone protect my brand from spoofing? No. SPF evaluates the SMTP return-path domain, which can differ from the visible From domain. DMARC requires alignment, and an aligned DKIM pass can also satisfy DMARC when SPF does not. ### Can I report a lookalike domain for takedown? Yes, you can report a lookalike domain for takedown when you have relevant evidence and the registrar, hosting provider, mailbox provider, or other party offers an applicable abuse process. Reporting does not guarantee removal or a particular response time. Keep a dated record of the evidence, channel, case reference where available, owner, and follow-up date. --- # How do I fix the 'SPF PermError: too many DNS lookups' error? Canonical: https://www.palisade.email/learning/how-do-i-fix-spf-permerror-too-many-dns-lookups > SPF PermError: too many DNS lookups means SPF exceeded its 10-term DNS limit. Map the lookup chain, remove or separate senders, then retest. `SPF PermError: too many DNS lookups` means the receiver needed more than 10 SPF DNS-querying terms to evaluate the envelope-sender or HELO domain. Fix it by mapping the full reachable `include` and `redirect` chain, removing confirmed unused authorizations, consolidating supported senders, or separating a sender onto its own subdomain. Then send a new message through the same production path and inspect its SPF result. For the counting rules and nested examples, see [what counts toward SPF’s lookup limit](/learning/glossary/spf-lookup-limit). Use the procedure below when the reported failure is lookup exhaustion. ## Quick takeaways - [RFC 7208 limits SPF evaluation to 10 DNS-querying terms and modifiers](https://www.rfc-editor.org/rfc/rfc7208#section-4.6.4). - Nested `include` records count against the same lookup budget as the top-level SPF record. - `ip4`, `ip6`, and `all` do not consume the SPF DNS lookup budget. - The failed SPF identity can be the envelope sender or HELO domain, not the visible From domain. - Removing an active sender authorization can break legitimate mail, so identify its owner before publishing a change. - A public DNS check cannot prove the production application used the intended sending path. ## What does the failure mean? SPF authorizes the IP address that sent a message for the SMTP envelope sender or HELO identity. To prevent unbounded DNS work, [RFC 7208 section 4.6.4](https://www.rfc-editor.org/rfc/rfc7208#section-4.6.4) requires SPF evaluators to limit DNS-querying terms and modifiers to 10. When evaluation exceeds that limit, the SPF result is `permerror`. ```text SPF PermError: too many DNS lookups ``` The error proves that SPF evaluation exceeded the limit. It does not identify the exact nested `include`, `redirect`, or sender service that used the final permitted lookup. `include`, `a`, `mx`, `ptr`, `exists`, and `redirect` can require DNS processing during SPF evaluation. `ip4`, `ip6`, and `all` do not. An `mx` mechanism counts as one term toward the overall 10-term limit; its address lookups also have a separate limit under [RFC 7208 section 4.6.4](https://www.rfc-editor.org/rfc/rfc7208#section-4.6.4). The overall budget is not simply a count of DNS network requests. A separate `permerror` can occur when a domain publishes more than one SPF record. RFC 7208 also recommends a limit of two void lookups, such as `NXDOMAIN` or an empty answer. Do not assume that a short top-level record is healthy until you trace its reachable records. ![SPF lookup-budget flow showing a root SPF record expanding includes and redirect branches until it exceeds ten DNS-querying terms](/images/editorial/how-do-i-fix-spf-permerror-too-many-dns-lookups/how-do-i-fix-spf-permerror-too-many-dns-lookups-lookup-budget.webp "1200x676") *Source: Palisade.* ## What usually causes it? ### Nested `include` records exceed the budget An `include` causes the receiver to evaluate the referenced SPF policy. Its reachable DNS-querying terms count toward the same total. A top-level record with only a few includes can exceed 10 after those records expand. The [SPF lookup-limit guide](/learning/glossary/spf-lookup-limit) explains the limit and mechanisms in more detail. ### A `redirect` reaches another complex policy The `redirect` modifier directs SPF evaluation to another SPF record when no earlier mechanism matches. It counts toward the limit. A long redirected policy, especially one with nested includes, can create the failure even when the root record looks short. ### Retired services remain authorized A newsletter platform, CRM, help desk, or transactional provider may have left an old `include` behind. The SPF result alone cannot prove that a service is unused. If the service has no current owner, this is an operational inference that needs confirmation before you remove it. ### DNS-based mechanisms add hidden work `a`, `mx`, `ptr`, and `exists` mechanisms can consume lookups without appearing as an included vendor policy. [RFC 7208 strongly discourages `ptr`](https://www.rfc-editor.org/rfc/rfc7208#section-5.5). Replace it only after confirming the current sending IP address or supported provider configuration. ### Multiple SPF records exist A domain must publish one SPF record beginning with `v=spf1`. Multiple SPF records produce `permerror`, which can coexist with an over-limit policy. Check record count before changing mechanisms. ## How do I diagnose the failure? ### 1. Preserve the receiver's authentication evidence Save the raw source of a message that failed. Record the trusted receiver-added `Authentication-Results` header, SMTP envelope sender when available, HELO identity, sending application, outbound IP address, and recipient provider. [RFC 8601 defines `Authentication-Results`](https://www.rfc-editor.org/rfc/rfc8601.html). It can identify the SPF identity with properties such as `smtp.mailfrom` and `smtp.helo`. ```text Authentication-Results: receiver.example; spf=permerror smtp.mailfrom=yourdomain.com ``` This is illustrative only. Redact recipient addresses, message identifiers, and customer data before sharing a ticket. ### 2. Build a labelled DNS evidence record Query the exact SPF identity shown in the receiver result. Capture the evidence before remediation so another operator can reproduce both the lookup count and the authorization decision. ```text SPF owner queried: sender.example Test IP: 192.0.2.10 Root TXT: v=spf1 include:spf.mail.example include:spf.crm.example -all spf.mail.example TXT: v=spf1 a:m1.example a:m2.example a:m3.example a:m4.example -all spf.crm.example TXT: v=spf1 a:c1.example a:c2.example a:c3.example a:c4.example a:c5.example -all Assumption: each a: hostname resolves to 192.0.2.20, not the test IP. Evaluation path: 1 include:spf.mail.example 2-5 a:m1.example through a:m4.example; no match; included policy fails 6 include:spf.crm.example 7-10 a:c1.example through a:c4.example; no match 11 a:c5.example would exceed the limit; SPF returns permerror The -all mechanisms do not consume this budget. Representative result: spf=permerror smtp.mailfrom=sender.example ``` The names and results are illustrative only. The calculation boundary is the SPF evaluator's reachable execution path for the identity and message under test, not a count of words in the root TXT record. Record multiple SPF TXT values, void answers, and branches that are not reached for the test path separately. Use the [Palisade SPF checker](/tools/spf) to inspect the publicly published SPF record and its lookup path. It is a DNS lookup, not proof that an application used the expected envelope sender, that all production routes are represented, or that a receiver accepted a specific message. ### 3. Expand every reachable DNS-querying term Follow each `include` to its SPF record and continue through nested includes. Trace `redirect` only where its conditions apply. Count `a`, `mx`, `ptr`, and `exists` mechanisms that the evaluation can reach. Do not flatten a provider's published IP ranges into your record without a named maintenance owner. Provider infrastructure can change, and a static flattened record can become stale. ### 4. Verify the authorization owners Map each authorization to a current sending service, owner, and test path. Confirm whether it sends using the failed SPF identity. If ownership is unknown, preserve the term until you can test the suspected service. > Do not delete an authorization because its name looks unfamiliar. A syntactically valid SPF record can still cause SPF failure for an active sender after a careless removal. ### 5. Check duplicate records and void lookups Confirm that the root and any redirected SPF domain publish only one `v=spf1` TXT record. Then check that referenced DNS names resolve as expected. A deleted provider hostname or typo can cause a different SPF `permerror` even when the lookup count is below 10. ## How do I fix it? ### Remove confirmed unused senders Remove an `include` or other authorization only when its service is retired or has moved to another approved sending identity. Retest that service's known paths after the change. Confirming that a service is retired is the harder half, and DMARC aggregate reports are the evidence. An authorization whose sender has produced no passing SPF result across a long reporting window is a candidate for removal; one that carried mail last week is not. Palisade's hosted SPF sender list records the last day mail passed SPF through each entry and marks the entries that have been silent for the full window, so the decision rests on report history rather than memory. Where that view is not available, read the aggregate reports for the sending source directly before removing its authorization. This repair changes SPF authorization. It does not change the DMARC policy, DKIM signing, or a receiver's delivery decision. ### Consolidate authorized services When several active services use overlapping provider policies, move them to a supported shared authorization model if the provider documents one. Keep a service inventory beside the SPF record so later changes do not recreate the lookup chain. This is preferable to copying provider IP ranges into a static record unless your team owns the ongoing maintenance and change process. ### Use a dedicated sending subdomain When a marketing or transactional provider supports a custom return path, move that sender class to a subdomain such as `news.yourdomain.com`. The subdomain has its own SPF evaluation budget. ```text news.yourdomain.com. TXT "v=spf1 include:spf.provider.example -all" ``` This record is illustrative only. Use the provider-generated values for the real configuration. Confirm that the sender uses the subdomain as its envelope sender, then check DKIM alignment in a delivered message. ### Use managed delegation only with clear ownership If senders change frequently and an owner maintains the inventory, a delegated SPF record can keep the parent policy to one managed `include`. [Palisade Hosted SPF documentation](https://docs.palisade.email/page-breakdowns/hosted-spf/) describes Palisade's hosted SPF option. A single include is not by itself proof that the complete evaluation stays within the limit; verify the resulting chain after migration. Hosted SPF does not replace inventorying senders, approving authorization changes, or checking SPF and DKIM alignment in a real delivered message. It also does not control a receiver's private delivery decision. ![Decision flow for choosing removal, service consolidation, a dedicated sender subdomain, or managed SPF delegation](/images/editorial/how-do-i-fix-spf-permerror-too-many-dns-lookups/how-do-i-fix-spf-permerror-too-many-dns-lookups-safe-next-action.webp "1200x856") *Source: Palisade.* ## How do I validate the repair? Publish the smallest confirmed change, then query the authoritative DNS server and at least one public resolver to confirm the intended SPF record is visible. Recount the reachable DNS-querying terms for the same SPF identity. Send a new message from the same application, envelope sender, route, and recipient provider that produced the failure. Confirm the receiver's trusted `Authentication-Results` no longer reports `spf=permerror`. A passing SPF result still does not prove DMARC passes. Check whether the SPF-authenticated domain aligns with the visible From domain, or whether aligned DKIM supports DMARC. After DMARC aggregate-report data accumulates, review the affected source for SPF, DKIM, and alignment results. For teams responsible for several domains or sender changes, [Palisade DMARC software](/features/dmarc-agent) analyzes aggregate reports, identifies authentication and alignment issues, and creates prioritized remediation tickets. A human reviews the evidence and applies DNS or DMARC policy changes. ## Track the SPF sender inventory after the repair Use the public SPF lookup to confirm the record you just changed, then keep an operational record of which sources use that SPF identity. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=existing_content_migration&utm_content=how-do-i-fix-spf-permerror-too-many-dns-lookups) A public SPF check cannot inventory every production sender, monitor later authorization drift, prove alignment for a delivered message, or guarantee delivery. ## Sources and further reading - [RFC 7208 section 4.6.4: SPF processing limits](https://www.rfc-editor.org/rfc/rfc7208#section-4.6.4) - [RFC 7208 section 5.5: The SPF PTR mechanism](https://www.rfc-editor.org/rfc/rfc7208#section-5.5) - [RFC 8601: Authentication-Results header field](https://www.rfc-editor.org/rfc/rfc8601.html) - [Palisade SPF checker](/tools/spf) - [Palisade Hosted SPF documentation](https://docs.palisade.email/) ## Frequently asked questions ### Does every `include` count as one SPF lookup? No. An `include` itself requires SPF evaluation of another domain, and DNS-querying terms inside that policy also count. Count the full reachable chain, not only top-level includes. ### Can I fix SPF PermError by changing DMARC to `p=none`? No. DMARC policy changes requested handling for DMARC failures. It does not reduce SPF DNS lookups or change an SPF `permerror`. ### Should I flatten my SPF record? Flatten your SPF record only when a named owner can maintain the resulting IP authorizations and provider changes. Static flattened ranges can become stale. Removing unused senders, consolidating supported services, or using a dedicated subdomain is often easier to operate safely. ### Can a DNS checker prove the fix worked for production mail? No. A DNS checker can show the published SPF record and its public lookup path. Send a new message through the same production route and inspect the receiver's `Authentication-Results` header. ### Can SPF pass while DMARC fails? Yes. SPF can pass for an envelope-sender domain that does not align with the visible From domain. DMARC can still pass through aligned DKIM, but validate the exact delivered message and later review aggregate reports. --- # How do I send a secure email in Gmail? Canonical: https://www.palisade.email/learning/how-do-i-send-a-secure-email-in-gmail > How do I send a secure email in Gmail? Use Confidential mode for access controls, or Google Workspace encryption when your organization enables it. To send a secure email in Gmail, use Confidential mode in Gmail on the web when you need expiry, revocation, or limits on common recipient actions. If your organization uses Google Workspace and has enabled hosted S/MIME or client-side encryption, use the organization-managed option that fits the recipient and policy. The available controls, certificates, and encryption choices depend on the account and Workspace configuration. ## Quick takeaways - Gmail Confidential mode can set an expiration date, revoke access, and disable forwarding, copying, printing, and downloading. - Confidential mode cannot stop a recipient from taking a screenshot or photograph of the message. - Google Workspace hosted S/MIME uses certificates to sign and encrypt supported messages. - Gmail client-side encryption protects the message body, inline images, and attachments, but not the subject, recipients, or timestamps. - A Gmail security indicator does not prove that the delivered message followed the expected sending path or passed DMARC. - DMARC evaluates aligned SPF or DKIM authentication for the visible From domain. It is separate from access controls and message encryption. ## What should I check before configuring Gmail? First, identify the sending path. Gmail Confidential mode is a per-message control in Gmail on the web. Hosted S/MIME and client-side encryption are Google Workspace capabilities that an administrator must configure, and their availability can depend on the organization's edition, organizational unit, certificates, and external key service. Google's [Gmail encryption overview](https://support.google.com/mail/answer/6330403) distinguishes transport encryption, hosted S/MIME, and client-side encryption. Also separate employee mailbox mail from marketing or transactional mail. A Gmail setting does not configure another platform that uses the same visible domain. For a custom domain, identify the DNS owner and the system that signs every production path. > Copy DNS values from the account and domain you are configuring. Do not publish selectors, targets, tokens, or hostnames from another account or from an online example. Plan a fresh, non-sensitive test message to a mailbox where you can inspect the delivered source or confirm the recipient experience. That message is evidence of the actual route. It is more useful than assuming an enabled control applied to every message. ## Which setup method should I use? Use [Gmail Confidential mode](https://support.google.com/mail/answer/7674059?hl=en) for an individual message that needs an expiry date, revocation, or limits on forwarding, copying, printing, and downloading. Google documents that those limits do not prevent screenshots, screen recording, or a recipient from reproducing the content. Use hosted S/MIME when the Google Workspace organization manages certificates and the recipient's certificate arrangement supports encrypted delivery. Google documents hosted S/MIME administration and certificate management in its [hosted S/MIME setup guidance](https://knowledge.workspace.google.com/admin/gmail/advanced/turn-on-hosted-s-mime-for-message-encryption). Use client-side encryption when the organization has deployed it and needs message content encrypted before it reaches Google. Google's [Gmail client-side encryption instructions](https://support.google.com/mail/answer/13317990) state that it encrypts the body, inline images, and attachments. The subject, recipients, and timestamps remain unencrypted. ![Google Gmail Help example showing a Confidential mode expiration notice in the compose interface](/images/editorial/how-do-i-send-a-secure-email-in-gmail/google-gmail-confidential-mode-help.png "1280x633") *Source: [Send and open confidential emails](https://support.google.com/mail/answer/7674059?hl=en), checked 2026-08-11.* ### Decision and evidence record Record the decision before sending the message. This prevents a Gmail control from being treated as proof of a different security property. - **Sensitivity and recipient requirement:** State whether the recipient needs an expiring access link, certificate-based encrypted exchange, or organization-approved client-side encryption. - **Chosen method:** Record Confidential mode, hosted S/MIME, or client-side encryption. - **Sender context:** Record the Gmail account, visible From address, and relevant Google Workspace edition or organizational unit. - **Recipient capability or access requirement:** For Confidential mode, record the intended access and passcode choice. For an organization-managed encryption option, confirm the recipient arrangement documented for that method. - **Proof of the sent-message state:** Save a redacted delivered-message header, recipient-side confirmation, or evidence that expiration or revocation worked. - **Documented limitation:** Record the limitation that applies, such as Confidential mode's inability to prevent screenshots or client-side encryption's unencrypted subject line. ![Decision record for choosing Gmail Confidential mode or an organization-managed encryption option](/images/editorial/how-do-i-send-a-secure-email-in-gmail/how-do-i-send-a-secure-email-in-gmail-security-methods.webp "1200x676") *Source: Palisade.* If the reader needs access controls for one message, choose Confidential mode and test the expiry or revocation result with safe sample content. If the reader needs an organization-managed encryption option, confirm that Google Workspace has enabled hosted S/MIME or client-side encryption for the account before composing the message. ## How do I configure Gmail's secure email features? ### 1. Open the correct Gmail or Google Workspace settings For Confidential mode, sign in to Gmail on the web, select **Compose**, then select the confidential-mode control in the compose window. This path is documented in Google's [Confidential mode instructions](https://support.google.com/mail/answer/7674059?hl=en). For hosted S/MIME, Google documents the administrator path as **Admin console > Apps > Google Workspace > Gmail > User settings**. Select the organization or domain that will use S/MIME. Google requires the Gmail Settings administrator privilege for this configuration. For client-side encryption, use Google's current [Gmail client-side encryption deployment instructions](https://support.google.com/mail/answer/13317990). Do not infer availability from another organization's Gmail account. ### 2. Select the method that matches the message For Confidential mode, set the expiration and choose an SMS passcode only when the recipient workflow requires it. For client-side encryption in Gmail on the web, Google documents the compose path as **Compose > Message security > Additional encryption > Turn on**. Keep sensitive content out of the subject line because client-side encryption does not encrypt it. For hosted S/MIME, choose encryption only after the organization has enabled it and the sender and recipient certificate arrangement supports encrypted delivery. ### 3. Configure organization-owned certificates when using hosted S/MIME Enable **S/MIME encryption for sending and receiving emails** for the selected Google Workspace organization. Google's [hosted S/MIME guidance](https://knowledge.workspace.google.com/admin/gmail/advanced/turn-on-hosted-s-mime-for-message-encryption) says administrators can add certificates through the Gmail S/MIME API. Users can add a personal certificate for a Gmail web **Send mail as** account through **Settings > See all settings > Accounts > Send mail as > Edit info**. Do not copy certificates, private keys, public keys, or encryption settings from another organization. The certificate material must belong to the sender and recipient arrangement under test. ### 4. Send a fresh test message through the intended path Send a non-sensitive message from the exact Gmail account and route that will be used in production. Use a recipient that can receive the method you selected. For Confidential mode, test the expiration or revocation behavior. For hosted S/MIME or client-side encryption, confirm the recipient-side arrangement before accepting the test as successful. A message sent before an administrator change took effect does not validate the new configuration. ### 5. Preserve the evidence from the test Keep the sender account, visible From domain, recipient type, chosen method, relevant administrator setting, and time sent with the change record. Retain redacted delivered headers for hosted S/MIME or client-side encryption tests. For Confidential mode, retain proof of the tested access control. ```text Sending account: sender@yourdomain.com Visible From domain: yourdomain.com Security method: Confidential mode | hosted S/MIME | client-side encryption Recipient capability or access requirement: documented internally Delivered-message evidence: redacted headers or recipient confirmation Documented limitation: recorded for the selected method ``` ## How does this setup affect DMARC? Gmail access controls and encryption do not replace DMARC. DMARC checks whether SPF or DKIM authentication aligns with the visible From domain. [RFC 9989 defines relaxed and strict DMARC alignment](https://datatracker.ietf.org/doc/html/rfc9989). A valid DKIM signature for an unrelated domain does not produce an aligned DKIM result. When the Gmail account sends from a custom domain, inspect the published policy with Palisade's [DMARC checker](/tools/dmarc). A public DNS check cannot prove that a specific Gmail message used the expected account, encryption option, signing domain, or delivery path. For the broader protocol context, see the [email authentication learning hub](/learning). ## How do I validate the setup? ### Check public DNS If the Gmail account sends from a custom domain, query the DMARC record through the authoritative DNS service and at least one public resolver. ```bash dig +short TXT _dmarc.yourdomain.com ``` Compare the answer with the intended DMARC policy. This confirms public DNS. It does not confirm the behavior of a delivered Gmail message. ### Check the Google Workspace status For hosted S/MIME, confirm that the setting is active for the correct organization or organizational unit. For client-side encryption, confirm that the intended account can use the approved feature. A green administrator status confirms the current configuration state. It does not prove the delivered-message result. ### Inspect a delivered message Inspect a new message from the exact account and route. For DMARC-related evidence, review the receiver-added `Authentication-Results` field and the expected signing information. [RFC 8601 defines Authentication-Results and its trust boundary](https://www.rfc-editor.org/rfc/rfc8601.html). For the selected Gmail method, also retain the recipient-side evidence that applies: a Confidential mode access result, a supported S/MIME certificate result, or the client-side encryption state. Do not treat a compose-window indicator as evidence for a message sent through another path. ### Review DMARC reports After aggregate reports arrive, review whether Gmail traffic passes SPF or DKIM and aligns with the visible From domain. Separate legitimate Gmail traffic from other systems that use the domain. If Gmail messages are blocked for authentication reasons, compare the delivered headers and DMARC data with the guidance in [Gmail's blocked-sender authentication fix](/email-deliverability/gmail-blocked-sender-is-unauthenticated). ## Troubleshooting ### Confidential mode is unavailable in the compose window Confirm that you are using Gmail on the web and that you opened a new compose window. Follow Google's documented [Confidential mode compose flow](https://support.google.com/mail/answer/7674059?hl=en). If an organization policy affects the account, ask the Google Workspace administrator to confirm the permitted configuration. ### A recipient can still copy the message with a screenshot This is an expected limitation. Google documents that Confidential mode cannot prevent screenshots, screen recording, or a recipient from reproducing message content. Use a process that fits the sensitivity of the information rather than treating the restriction as proof of recipient control. ### Client-side encryption does not appear Confirm that the organization has deployed client-side encryption and that the selected account is eligible. Google documents the compose control only for supported Google Workspace deployments. Do not send sensitive text in the subject while investigating because the subject is outside the encrypted content. ### Hosted S/MIME is enabled but the recipient cannot receive encrypted mail Check the sender and recipient certificate arrangement, then test again with a recipient that supports the organization's documented exchange method. The administrator setting alone does not establish that the recipient path can use encrypted delivery. ### The Gmail message passes DKIM but DMARC fails Compare the visible From domain with the `d=` domain from the delivered message. DKIM can pass while failing DMARC alignment. Review the DMARC policy and the exact message path before changing DNS. For a related deliverability symptom, see [why emails go to spam in Gmail](/email-deliverability/why-are-my-emails-going-to-spam-in-gmail). ## Check the DMARC record for the Gmail sending domain If your Gmail account sends from a custom domain, check its public DMARC record before changing enforcement. The record helps you identify the published policy that receivers can query, while your redacted message headers show what happened on the test path. [Check the Gmail sending domain's DMARC record](/tools/dmarc) A record check cannot prove that Confidential mode, hosted S/MIME, or client-side encryption was used for a particular message. It also cannot monitor later configuration changes or guarantee delivery. If your team needs to review DMARC aggregate-report data across Gmail and other senders, Palisade is agentic DMARC software that analyzes those reports, identifies authentication or alignment issues, and proposes a next policy step for human review. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=email_authentication&utm_content=how-do-i-send-a-secure-email-in-gmail). ## Sources and further reading - [Google Gmail Help: Send and open confidential emails](https://support.google.com/mail/answer/7674059?hl=en) - [Google Gmail Help: Learn about Gmail encryption](https://support.google.com/mail/answer/6330403) - [Google Workspace Admin Help: Turn on hosted S/MIME](https://knowledge.workspace.google.com/admin/gmail/advanced/turn-on-hosted-s-mime-for-message-encryption) - [Google Gmail Help: Send and receive emails with client-side encryption](https://support.google.com/mail/answer/13317990) - [RFC 9989: DMARC](https://datatracker.ietf.org/doc/html/rfc9989) - [RFC 8601: Message Header Field for Indicating Message Authentication Status](https://www.rfc-editor.org/rfc/rfc8601.html) ## Frequently asked questions ### Can I send a secure email in Gmail without Google Workspace? Yes. Gmail Confidential mode is available in Gmail on the web and can apply expiry, revocation, and limits on common recipient actions. Google documents that it cannot stop screenshots, screen recording, or a recipient from reproducing the message. ### Is Gmail Confidential mode encrypted email? No. Confidential mode provides documented recipient-access controls such as expiry, revocation, and restrictions on common actions. Choose a Google Workspace encryption option only when the organization has enabled it and the recipient arrangement supports it. ### Does Gmail client-side encryption encrypt the subject line? No. Google documents that Gmail client-side encryption encrypts the message body, inline images, and attachments. The subject, recipients, and timestamps remain unencrypted. ### Does hosted S/MIME work for every recipient? No. Hosted S/MIME needs the organization's certificate configuration and a recipient arrangement that supports encrypted delivery. Validate a fresh message with the actual recipient path. ### Does Gmail encryption make DMARC pass? No. DMARC requires aligned SPF or DKIM authentication for the visible From domain. Encryption and Confidential mode address different parts of email security. ### Can I recall a Gmail confidential email after it is opened? Only access revocation is documented for Gmail Confidential mode. Google does not describe it as a way to remove copied content, screenshots, photographs, or information a recipient has already reproduced. --- # How do MSPs run an email security assessment for a new client? Canonical: https://www.palisade.email/learning/how-do-msps-run-an-email-security-assessment-for-a-new-client > MSPs run a client email security assessment by collecting domain evidence, assigning owners, validating sending paths, and tracking exceptions. MSPs should run a new-client email security assessment as a repeatable evidence-and-ownership workflow, not as a one-time DNS scan. Define the client domains and sending paths in scope, collect public DNS and delivered-message evidence, identify who controls each finding, and keep unresolved risks in a dated register. The result is a client-approved remediation plan that can continue into an ongoing service. ## Quick takeaways - A useful assessment separates public DNS evidence, sender-platform status, delivered-message evidence, and DMARC report evidence. - The client decides which sending systems are legitimate and accepts business risk, unless the service agreement delegates those decisions. - The MSP coordinates the assessment, evidence record, remediation queue, and escalation path. - A public checker can inspect a published record, but it cannot prove a production sending path or a mailbox provider's private delivery decision. - Every unresolved finding needs an owner, a next action, a client decision where needed, and a review date. - A portfolio report should show evidence and decisions rather than claim that one score proves complete email security. ## Operating context and ownership A client assessment becomes an MSP operating task because every client has different domains, sender platforms, approval paths, DNS ownership, and business-critical sending periods. The MSP needs a consistent record across the portfolio, while each client retains its own business context. This is a Palisade-authored operating framework, not an external requirement. It is designed to make assessment findings portable between onboarding, tickets, client reviews, and recurring security work. The MSP owns the process: collecting evidence, documenting findings, coordinating requests, and reporting progress. The client confirms whether a sender is legitimate, provides business-risk context, and approves changes unless those responsibilities are explicitly delegated. The DNS host controls record publication. The sending-platform owner controls platform configuration. Receiving mailbox providers make their own handling decisions. [DMARC in RFC 9989](https://datatracker.ietf.org/doc/html/rfc9989) evaluates whether SPF or DKIM produces an aligned result under the domain's published DMARC policy. That protocol result does not disclose a receiver's private reputation logic or guarantee inbox placement. For broader service design, see the [Palisade MSP resources](/for-managed-service-providers), email threats MSPs should prioritize, and [why MSPs should offer email security services](/learning/why-should-msps-offer-email-security-services). ![Assessment flow showing client scope and approvals, MSP evidence collection, control-owner remediation, and exception review](/images/editorial/how-do-msps-run-an-email-security-assessment-for-a-new-client/how-do-msps-run-an-email-security-assessment-for-a-new-client-assessment-flow.webp "1200x829") *Source: Palisade.* ## Evidence to collect Create one intake record for each in-scope client domain. Keep the detailed operating record separate from the client-facing summary because a sender inventory and exception register may contain sensitive operational context. Collect public DNS evidence for DMARC, SPF, and DKIM where a selector is known. Capture the source and time for every result. Also request redacted evidence from actual delivered messages and any available sender-platform verification status. These sources answer different questions. ![Evidence checklist for an MSP email security assessment, covering DNS, sender platforms, delivered messages, and DMARC reports](/images/editorial/how-do-msps-run-an-email-security-assessment-for-a-new-client/how-do-msps-run-an-email-security-assessment-for-a-new-client-evidence-checklist.webp "1200x524") *Source: Palisade.* Use the following record as a fictional, redacted example. It is a Palisade-authored operating artifact, not a DNS record or a universal compliance requirement. ```yaml client: example-client domain: yourdomain.com scope: included_paths: - employee-mail - billing-platform - marketing-platform excluded_paths: - acquired-brand.example dns_evidence: captured_at: 2026-08-12T10:30:00Z source: authoritative-DNS-and-public-resolver dmarc: published-record-captured spf: published-record-captured dkim: selector-and-record-confirmation-pending message_evidence: captured_at: 2026-08-12T11:00:00Z source: redacted-header-from-production-path sender_inventory_owner: client-email-administrator unresolved_findings: - billing-sender-owner-not-confirmed business_risk_context: invoices-send-on-the-first-business-day remediation_owner: billing-platform-owner escalation_path: MSP-service-lead-to-client-technical-approver approval_change_reference: CHG-EXAMPLE-1042 review_on: 2026-08-19 ``` For each known or observed sender, record its purpose, visible From domain, return-path domain where available, client contact, platform owner, evidence state, evidence date, next action, and review date. Useful evidence states include `client-confirmed`, `message-verified`, `report-observed`, `unknown`, `retired`, and `out-of-scope`. Use an [email security score check](/tools/email-security-score) only as a public baseline for one domain. A public DNS and reputation check does not prove the production sending path, continuous state, a receiver's private decision, or future placement. > Do not recommend a DMARC enforcement change from a public-record check alone. Get client approval and validate the affected production sending path before changing policy. ## How to run the workflow ### 1. Confirm scope and authority - Owner: MSP service lead. - Input: Client contacts, domain list, service agreement, and known sending systems. - Output: Approved scope and named decision owners. Ask the client to identify domains used for employee mail, marketing, invoicing, support, applications, acquired brands, and inactive properties. Record exclusions instead of removing them from view. An excluded domain can still become a later assessment wave. Confirm who can approve remediation, publish DNS, and authorize access to each sender platform. If there is no client decision owner, record the finding as blocked. A technical observation without someone authorized to act on it is not a remediation plan. ### 2. Build the sender inventory - Owner: MSP assessment operator. - Input: Client-provided sender list, public DNS evidence, redacted message headers, and available DMARC reports. - Output: A sender inventory with dated confidence labels. Normalize service categories across the MSP portfolio while retaining client language. A client may call a sender "accounts receivable," while portfolio reporting can classify it as billing. Do not treat a domain with no stated sender as inactive. Mark it `unconfirmed` until the client verifies it. Likewise, a platform named by the client but absent from current message or report evidence is `client-confirmed`, not `message-verified`. ### 3. Record observable authentication gaps - Owner: MSP assessment operator. - Input: DNS evidence, sender status, and redacted evidence from actual delivered messages. - Output: A prioritized finding record. Write findings so another operator can verify closure. "Observed billing sender has no confirmed owner; client must identify the platform administrator and supply a production-path test message" is actionable. "Improve email security" is too broad to assign or test. A finding should include the domain, sender or service, observed condition, evidence date, remediation owner, client decision needed, completion test, and escalation path. The test may be an authoritative DNS answer, current sender-platform status, a delivered message from the same path, or later DMARC aggregate-report evidence. ### 4. Assign remediation at the control point - Owner: MSP service lead. - Input: Prioritized findings and the ownership record. - Output: A client-approved remediation queue. Assign DNS publication to the DNS owner. Assign sender configuration to the team that administers the platform. Assign legitimacy decisions and business-risk acceptance to the client. The MSP keeps the coordination record and defines the closure evidence. This avoids a common handoff failure: a request to "fix DMARC" may actually require a platform setting, DNS access, client approval, and a production-path retest. If an SPF record needs maintenance because a newly approved sender must be authorized, use the sender's official configuration instructions and preserve DNS lookup limits. Do not add a sender solely because it appears in a list of possible includes. ### 5. Validate each repair in four layers - Owner: Responsible change owner, reviewed by the MSP. - Input: Approved remediation, implementation evidence, and a same-path test. - Output: A dated validation record or an open exception. Validate only the claim each layer can support: - DNS: Query the authoritative DNS path and at least one public resolver to confirm the intended record is published. - Vendor: Review the sender platform's current authentication or verification status when it provides one. - Message: Inspect a real delivered message from the exact production path. [RFC 8601 defines Authentication-Results header fields](https://www.rfc-editor.org/rfc/rfc8601.html) for communicating authentication results to later message handlers. - DMARC: Review aggregate-report evidence after reports have accumulated for the domain and sending path. A green sender-platform indicator is not a delivered-message test. A passing DNS record is not proof that the platform is using the configured signing or return-path settings. Aggregate data also needs review because it can reveal sources that were absent from the initial inventory. ### 6. Close or escalate the finding - Owner: MSP service lead and client technical approver. - Input: Validation record, remaining uncertainty, and business-impact context. - Output: Closed finding, accepted exception, or escalation ticket. Close a finding only when the recorded completion test passes. If a finding cannot be repaired, document the client decision, residual risk, compensating action where one exists, and review date. Keep client data, credentials, private keys, tokens, and unredacted message headers within that client's approved systems. ## Exceptions and escalation Use a simple decision path for every unresolved item: - If the sender is unknown, ask the client to confirm whether it is legitimate before changing DNS or policy. - If the sender is legitimate but lacks an aligned authentication path, assign configuration work to the sender owner and set a production-path retest. - If DNS ownership is unclear, escalate to the client technical approver before proposing a record change. - If a business-critical sender has no safe test window, keep it as an exception with business context and a dated review. - If the evidence conflicts, preserve both sources and request a new delivered-message sample or report period. The MSP can recommend a priority and coordinate communication. The client decides whether to accept business risk. A sender provider controls its own product configuration, and mailbox providers retain control over their handling decisions. ## Reporting and success measures Use a monthly operational report and a client review cadence appropriate to the service agreement. The report should include: - In-scope domains and their assessment state. - Confirmed, unknown, retired, and unverified senders. - Findings by owner, evidence age, and next review date. - Changes awaiting client approval and changes validated after implementation. - Exceptions, client decisions, and escalation status. - Gaps in evidence, such as domains without a delivered-message sample or reports that have not yet accumulated. Do not present a single score as proof that all client mail is secure. A score can help prioritize public-record checks, but it cannot establish that every future message will authenticate or that a receiving provider will deliver it. ## Turn assessment evidence into a recurring client queue A one-time assessment often exposes a recurring portfolio gap: new senders, stale records, unresolved alignment issues, and policy decisions that need evidence over time. Palisade is agentic DMARC software that analyzes DMARC aggregate-report data, identifies sending sources and authentication or alignment issues, and creates prioritized remediation tickets. It can propose the next DMARC policy stage when evidence indicates readiness, while a human reviews the evidence and applies any change. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=msp_business&utm_content=how-do-msps-run-an-email-security-assessment-for-a-new-client) Palisade does not confirm a client's business authorization, change DMARC policy without human review and approval, prove every production path from a public check, or guarantee a receiver's delivery decision. For a provider-specific implementation of these authentication checks, see [MSP email sender inventory](/learning/msp-email-sender-inventory). ## Sources and further reading - [RFC 9989: Domain-based Message Authentication, Reporting, and Conformance](https://datatracker.ietf.org/doc/html/rfc9989) - [RFC 8601: Message Header Field for Indicating Message Authentication Status](https://www.rfc-editor.org/rfc/rfc8601.html) - [Palisade documentation](https://docs.palisade.email/) ## Frequently asked questions ### Does a DNS check complete an MSP email security assessment? No. A DNS check can confirm what is publicly published, but it cannot show whether a sender platform uses the intended production path, whether a delivered message passes authentication, or how a mailbox provider handles that message. ### Should an MSP change DMARC policy during the initial assessment? Only after the client has approved the change and the affected sending paths have evidence. DMARC policy changes should have a documented rollback condition, ownership record, and same-path validation plan. ### Who decides whether an unknown sender is legitimate? The client should make that business decision because it knows whether the sender supports a valid process. The MSP can provide evidence, identify the control owner, and record the risk of leaving the sender unresolved. ### Can a green sender-platform status replace a message-header check? No. A platform status can show its own verification state, while a delivered-message header provides evidence from the exact path used to send the message. Both can be useful, but they support different claims. ### What should an MSP report when evidence is incomplete? Report the evidence gap directly: what is missing, which domain or sender it affects, who owns the next action, any client-supplied business-risk context, and the next review date. Do not convert missing evidence into a passing security score. --- # Microsoft SMTP 5.4.1 Relay Access Denied Canonical: https://www.palisade.email/learning/how-do-you-fix-microsoft-smtp-5-4-1 > Diagnose Microsoft SMTP 5.4.1 Relay Access Denied from the full NDR. Identify the rejecting host, check destination acceptance and connectors, then retest. `550 5.4.1 Relay Access Denied` means the server named in the complete rejection refused to accept or relay mail for the recipient domain as presented. Preserve the full NDR, identify that rejecting host, and trace the destination path before changing DNS or authentication. If the response instead says `Recipient address rejected: Access denied. AS(201806281)`, use the [exact Microsoft DBEB guide](/resources-post/how-to-fix-550-5-4-1-recipient-address-rejected-access-denied). ## Quick takeaways - Microsoft SMTP `5.4.1` needs the full rejection text, remote server, and message context for a useful diagnosis. - `Recipient address rejected: Access denied. AS(201806281)` is a separate DBEB branch covered by the [recipient-address guide](/resources-post/how-to-fix-550-5-4-1-recipient-address-rejected-access-denied). - `Relay Access Denied` can indicate that the receiving server will not accept or relay mail for the recipient domain as presented. - SPF, DKIM, and DMARC changes do not create a missing recipient object or configure an onward relay route. - A public MX lookup can identify the advertised destination, but it cannot prove the production route or a Microsoft tenant's private decision. - Validate any repair with a new message sent through the same application, sender, recipient, and route. ## What does the failure mean? Microsoft's [Exchange Online non-delivery report guidance](https://learn.microsoft.com/en-us/troubleshoot/exchange/email-delivery/ndr/non-delivery-reports-in-exchange-online) recommends using the complete response, generating server, remote server, recipient, and original headers when investigating a non-delivery report. The final three digits alone are insufficient. This page owns relay and ambiguous full-NDR variants. Separate them from the exact recipient-address branch before investigating: ```text 550 5.4.1 Recipient address rejected: Access denied 550 5.4.1 Relay Access Denied ``` Microsoft documents [Directory-Based Edge Blocking](https://learn.microsoft.com/en-us/exchange/mail-flow-best-practices/use-directory-based-edge-blocking) as rejecting messages for invalid recipients in accepted domains. The exact `Recipient address rejected: Access denied. AS(201806281)` branch belongs in the [DBEB troubleshooting guide](/resources-post/how-to-fix-550-5-4-1-recipient-address-rejected-access-denied). Continue here when the NDR says `Relay Access Denied`, names another gateway, or does not contain enough text to assign the branch yet. [RFC 3463's enhanced status code definitions](https://www.rfc-editor.org/rfc/rfc3463.html) classify `5.x.x` responses as permanent failures. A configuration, recipient, or routing change is normally needed before the same message can succeed. The RFC does not map `5.4.1` to one Microsoft tenant condition. Create a response evidence packet before retrying. It should contain: - Exact full SMTP response and enhanced status code. - Timestamp and timezone. - Sending IP address and sending service or provider. - Sending domain and authenticated identifiers, such as the SMTP envelope sender and visible From domain. - Recipient domain and the intended recipient scope, such as one mailbox, group, alias, or external routing destination. - Sender application and relevant tenant or connector context. - The result of one controlled retry through the same approved path. Use a redacted record that retains the fields needed to compare attempts: ```text Illustrative redacted SMTP response fragment Timestamp: 2026-08-12 14:32:18 UTC Remote server: recipient-mail.example Sending service: approved-mail-provider.example Recipient scope: mailbox-alias@example.com Response: 550 5.4.1 Recipient address rejected: Access denied Controlled retry: same response ``` The sender-side packet can show the sending path and authentication evidence. It cannot reveal Microsoft recipient policy, directory state, connector configuration, or another tenant's private evaluation. Those items need evidence from the organization that controls the receiving domain. ![Decision flow for sorting Microsoft SMTP 5.4.1 into recipient, relay, sender-path, and receiving-admin evidence branches](/images/editorial/how-do-you-fix-microsoft-smtp-5-4-1/how-do-you-fix-microsoft-smtp-5-4-1-response-evidence-flow.webp "1200x829") *Source: Palisade.* ![Evidence checklist for diagnosing Microsoft SMTP 5.4.1](/images/editorial/how-do-you-fix-microsoft-smtp-5-4-1/how-do-you-fix-microsoft-smtp-5-4-1-evidence-checklist.webp "1200x696") *Source: Palisade.* ## What usually causes it? ### The NDR is actually the recipient-address DBEB variant For `550 5.4.1 Recipient address rejected: Access denied. AS(201806281)`, Exchange Online may not find a valid recipient for the address in an accepted domain. That exact variant has its own [recipient-object, accepted-domain, and directory-sync procedure](/resources-post/how-to-fix-550-5-4-1-recipient-address-rejected-access-denied). Do not diagnose that DBEB branch from this broader relay page. The complete Microsoft suffix and rejecting hostname are the evidence that decides the handoff. ### The accepted-domain design does not match the recipient architecture Microsoft distinguishes [Authoritative and Internal relay accepted domains](https://learn.microsoft.com/en-us/exchange/mail-flow-best-practices/manage-accepted-domains/manage-accepted-domains). An Authoritative domain accepts delivery for recipients known to Exchange Online. An Internal relay domain can send unknown recipients onward to another mail system through a connector. If recipients remain outside Microsoft 365 but the domain is configured as Authoritative, an unknown address can be rejected. Changing the domain type is a routing change, not a shortcut for one bounce. ### An onward relay connector is missing or mismatched An Internal relay configuration needs a connector that can deliver unknown recipients to the intended downstream mail system. A `Relay Access Denied` response can also come from a gateway that is not configured to accept the recipient domain. That second mapping is an inference until the NDR's remote server, message trace, and gateway logs identify the rejecting host. Do not assume Microsoft 365 issued the response because the sender or recipient uses Microsoft 365. ### The message reached an unintended receiving host If the NDR names an unexpected remote server, inspect the public MX records and any application or connector routing that can override them. The [email transport security hub](/learning/infrastructure) has related guidance for SMTP transport controls and delivery failures. A public DNS result shows the advertised route for a new sender. It does not prove the route used by the failed message, continuous DNS state, or the receiving service's private policy decision. ## How do I diagnose the failure? ### 1. Preserve the original non-delivery report Save the complete NDR or delivery-status notification before resending. Record the rejected address, Message-ID, timestamp, generating server, remote server, full SMTP response, and original message headers. Keep a redacted copy for escalation and an access-controlled original for the responsible administrators. The [Exchange Online NDR reference](https://learn.microsoft.com/en-us/troubleshoot/exchange/email-delivery/ndr/non-delivery-reports-in-exchange-online) identifies the response and server details needed for diagnosis. ### 2. Separate recipient rejection from relay rejection Treat `550 5.4.1 Recipient address rejected: Access denied` as a recipient-directory branch. Treat `550 5.4.1 Relay Access Denied` as a destination acceptance and routing branch. Do not merge them because both include `5.4.1`. SPF, DKIM, and the DMARC policy do not make an absent recipient appear or authorize a server to relay mail. ### 3. Check sender-side authentication and service ownership Confirm which provider submitted the message, the sending IP, envelope sender, visible From domain, and application that generated it. If the NDR or headers identify an authentication failure separate from `5.4.1`, repair that documented authentication problem with the sending service owner. For a sender-owned DNS question, use the [Palisade DNS lookup](/tools/dns-lookup) to inspect public records. A DNS lookup cannot inspect Microsoft tenant policy, production connector routing, raw message content, or why this individual recipient was rejected. Only investigate SPF lookup limits when an SPF evaluator directly reports that condition. Do not add Hosted SPF or rewrite SPF records as a response to a recipient-directory or relay rejection. ### 4. Verify the recipient scope outside autocomplete Compare the rejected address with a known-good address obtained through a trusted channel. Check the local part, domain, punctuation, aliases, and copied whitespace. If another recipient at the same domain receives the same message from the same sender, the public route likely reaches that domain. That result still does not prove the rejected mailbox, alias, group, or contact exists. ### 5. Ask the receiving administrator to inspect the exact object For the recipient-address branch, the receiving organization's administrator should verify that the exact address belongs to the intended mailbox, shared mailbox, group, mail contact, mail user, or public folder. They should also check for duplicate proxy-address conflicts and, for synchronized users, the source directory and cloud representation. > Do not create a duplicate mailbox or proxy address to clear one rejection. Duplicate addresses can produce ambiguous delivery and synchronization failures. ### 6. Trace the destination acceptance path For a relay-related response, ask the administrator responsible for the recipient domain to review its accepted-domain type, connectors, message trace, and any gateway named in the NDR. If the full response instead contains Microsoft's DBEB wording and `AS(201806281)`, hand it to the [550 5.4.1 recipient-address owner](/resources-post/how-to-fix-550-5-4-1-recipient-address-rejected-access-denied). If the remote server is outside the recipient's expected environment, compare the failed route with the intended MX route and any application-specific smart host or connector configuration. ## How do I fix it? ### Hand off the exact recipient-address variant If the full NDR says `Recipient address rejected: Access denied. AS(201806281)`, stop the relay investigation. The sender should verify the address and give the NDR to the recipient's Microsoft 365 administrator, who can follow the [exact DBEB repair sequence](/resources-post/how-to-fix-550-5-4-1-recipient-address-rejected-access-denied). That handoff preserves query ownership: this page diagnoses relay and ambiguous routes; the exact page diagnoses missing recipients, proxy addresses, accepted-domain state, and directory synchronization. ### Repair the accepted-domain and connector path If a valid recipient must be delivered to another mail system, the receiving administrator should confirm the accepted-domain type and connector route against Microsoft's [accepted-domain guidance](https://learn.microsoft.com/en-us/exchange/mail-flow-best-practices/manage-accepted-domains/manage-accepted-domains). Correct the connector or destination configuration that the trace identifies. > Do not change an accepted domain from Authoritative to Internal relay without confirming every downstream recipient route. That change can affect mail flow for the whole domain. This repair changes routing and destination acceptance. It does not repair message authentication. ### Escalate a persistent response with receiving-side evidence If the same response persists after the sender verifies its address, service ownership, and route, provide the receiving Microsoft 365 administrator with the evidence packet and controlled retry result. They can inspect recipient objects, message trace, accepted domains, connectors, and Microsoft support options available to their tenant. The sender cannot determine a recipient tenant's unpublished policy from a public DNS lookup or a single bounce. ## How do I validate the repair? Send a new message through the same application, sending service, sender domain, recipient address, and intended route. Compare the new result with the saved evidence packet. Validate at the applicable layers: - DNS: confirm public MX or sender DNS only when the repair involved those records. - Vendor: have the receiving administrator confirm the relevant recipient object, accepted domain, or connector state. - Message: inspect the NDR or delivered message from the same production path. - DMARC: if the sending domain uses DMARC, review aggregate-report data after it accumulates to confirm the sending source's authentication and alignment pattern. A successful retry to one recipient does not prove all aliases, routes, or future messages will succeed. ## Check the public route, then close the ongoing sender gap If the failed message may have reached the wrong host, inspect the recipient domain's public MX records before changing sender configuration. [Check the recipient MX route](/tools/mx) An MX check cannot prove the production sending route, inspect a Microsoft tenant's recipient directory, or explain a private relay decision. If your team needs to identify sending sources and recurring DMARC authentication or alignment issues across domains, [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=email_transport_security&utm_content=how-do-you-fix-microsoft-smtp-5-4-1). Palisade analyzes DMARC aggregate-report data and proposes remediation work for human review. It does not change Microsoft recipient settings, configure a third-party relay, or guarantee delivery. ## Sources and further reading - [Microsoft: Non-delivery reports in Exchange Online](https://learn.microsoft.com/en-us/troubleshoot/exchange/email-delivery/ndr/non-delivery-reports-in-exchange-online) - [Microsoft: Use Directory-Based Edge Blocking](https://learn.microsoft.com/en-us/exchange/mail-flow-best-practices/use-directory-based-edge-blocking) - [Microsoft: Manage accepted domains in Exchange Online](https://learn.microsoft.com/en-us/exchange/mail-flow-best-practices/manage-accepted-domains/manage-accepted-domains) - [Microsoft: Add or remove email addresses for mailboxes](https://learn.microsoft.com/en-us/exchange/recipients-in-exchange-online/manage-user-mailboxes/add-or-remove-email-addresses) - [RFC 3463: Enhanced Mail System Status Codes](https://www.rfc-editor.org/rfc/rfc3463.html) ## Frequently asked questions ### Does Microsoft SMTP 5.4.1 always mean the recipient does not exist? No. `5.4.1` is an enhanced status code, not a complete diagnosis. `Recipient address rejected: Access denied` points toward recipient validation, while `Relay Access Denied` points toward destination acceptance or routing evidence. ### Can SPF, DKIM, or DMARC fix `550 5.4.1 Recipient address rejected: Access denied`? No. Those controls authenticate sending domains and messages. They do not create a mail-enabled recipient, restore a missing alias, or change a receiving tenant's directory decision. ### Can an MX lookup explain `Relay Access Denied`? Only partly. An MX lookup can show the domain's public advertised mail exchangers. It cannot prove that the failed message used MX delivery, that no connector overrode the route, or why the receiving server refused relay. ### Should the sender create a new mailbox for the failed address? No. The receiving administrator should first confirm whether the exact address belongs on an existing mail-enabled object and whether a duplicate proxy address or synchronization issue exists. ### Can changing an accepted domain to Internal relay fix the error? Only when the recipient architecture requires unknown recipients to be routed to another mail system and the required connector path is configured. It is a domain-wide routing decision that needs receiving-side evidence, not a general response to one rejection. --- # How does IP spoofing work and how can you stop it? Canonical: https://www.palisade.email/learning/how-does-ip-spoofing-work-and-how-can-you-stop-it > IP spoofing works by forging a packet's source address. Learn how ingress filtering, source validation, and authentication reduce its impact. IP spoofing works when a sender places a forged source IP address in an IP packet, making the packet appear to come from another system. It is most useful where a target accepts traffic without proving the sender controls that address, or where attackers want replies sent to a victim. Stop it by filtering invalid source addresses at network boundaries and by requiring cryptographic or stateful authentication where identity matters. ## Quick takeaways - IP spoofing changes the source-address field in an IP packet. It does not give an attacker control of the forged address. - A spoofed source address can make reply traffic go to an unrelated host. - Ingress filtering drops traffic whose source address should not arrive on a given interface. - Egress filtering helps prevent networks from sending packets with source addresses they do not own. - TCP's return traffic makes blind source-address spoofing harder for connections that require a completed handshake. - Email domain spoofing is a separate problem. SPF, DKIM, and DMARC validate authorized use of an email domain, not the network origin of every IP packet. ## How IP spoofing works An IP packet includes a source address and a destination address. The source address tells the receiving system where return traffic should go, but IP itself does not authenticate that field. [RFC 2827 describes the risk of packets with forged source addresses](https://datatracker.ietf.org/doc/html/rfc2827): an attacker can send traffic that claims to originate from an address assigned to another network. Consider a packet sent to `198.51.100.20` with a source address forged as `203.0.113.44`. The target may send any response to `203.0.113.44`, not to the attacker. That behavior supports reflection attacks, where a third-party service sends traffic toward the spoofed victim address. Source-address spoofing is different from taking over an IP address. The attacker can choose a value for the packet header, but they normally cannot receive responses routed to an address they do not control. This limits attacks against protocols that need a two-way exchange. TCP, for example, uses a handshake and sequence numbers, so a remote attacker who cannot observe the replies has difficulty completing a normal TCP connection. The problem changes for protocols that answer an unauthenticated request, especially UDP-based services. A forged request can cause a service to send its response to the victim. The Internet Engineering Task Force documents source-address validation as a way to reduce this class of abuse in [RFC 8704](https://datatracker.ietf.org/doc/html/rfc8704). ![Flow showing a forged-source packet, a target service, and the response sent to the victim address](/images/editorial/how-does-ip-spoofing-work-and-how-can-you-stop-it/how-does-ip-spoofing-work-and-how-can-you-stop-it-spoofing-flow.webp "1200x676") *Source: Palisade.* ## When IP spoofing matters, and when it does not Use this decision rule: treat a source IP address as a routing clue unless the protocol or network control independently validates it. IP spoofing is a material concern when: - A public-facing service responds to requests without confirming the requester controls the source address. - A router accepts packets from outside the network that claim to originate from internal or private address ranges. - An organization allows outbound traffic with source addresses that its network has not assigned. - An application grants trust solely because a request appears to come from a particular IP address. It is less effective when the target requires a completed exchange that the attacker cannot observe, or when the network rejects packets whose source addresses fail route-based validation. Those controls reduce risk, but they do not make an IP address proof of a user's identity. Do not confuse IP spoofing with email spoofing. A fraudulent message can use a visible From address that resembles a trusted domain even if its sending infrastructure uses a valid IP address. [Email authentication](/learning) addresses that separate identity problem through SPF, DKIM, and DMARC. For a broader explanation of deceptive identity techniques, see [what exactly spoofing is and how to stop it](/learning/what-exactly-is-spoofing-and-how-can-you-stop-it). ## Worked example: identify traffic that should be dropped A perimeter router should reject a packet arriving from the public internet when its claimed source address belongs to the organization's own internal range. It should also reject source ranges that are not valid on that interface under the organization's routing design. ```text Illustrative inbound packet Source IP: 10.20.30.40 Destination IP: 198.51.100.20 Ingress interface: public-internet Decision: drop Reason: 10.20.30.40 is an internal private address and must not arrive from the public-internet interface. ``` The exact prefixes and interfaces depend on your network design. Do not copy example ranges into a production access-control list without reviewing routing, remote-access paths, cloud connectivity, and legitimate asymmetric traffic. [RFC 3704 defines ingress filtering](https://datatracker.ietf.org/doc/html/rfc3704) as filtering based on the expected relationship between a packet's source address and the interface where it arrives. Strict reverse-path checks can drop valid traffic in networks with asymmetric routing, so operators need to choose a method that fits the actual return paths. A useful evidence set includes: - The packet capture or flow record showing source address, destination address, protocol, ports, and ingress interface. - The route or prefix assignment that shows whether the claimed source is valid on that interface. - Firewall or router logs showing whether a source-validation rule accepted or dropped the packet. - For an application-level incident, logs that show whether the service authenticated the requester beyond its IP address. ## What to do next Start at the network edge. Review inbound rules for traffic that claims to originate from your own address space, private-use ranges, loopback ranges, or prefixes that are invalid for the interface. Then review outbound rules so hosts cannot send packets with source addresses outside the prefixes your network owns or delegates. For services where the caller's identity affects authorization, require an authentication mechanism that the source IP address cannot provide on its own. The appropriate control depends on the protocol, such as mutual TLS, signed requests, or an authenticated session. Test the real request path after each change. A configuration review alone does not prove that every ingress path applies the rule. If the concern is a message that impersonates your organization, inspect the domain rather than the packet source. [How to stop spoofing attacks](/learning/what-exactly-is-spoofing-and-how-can-you-stop-it) covers domain-focused defenses, while [how malspam works and how to stop it](/learning/how-does-malspam-work-and-how-to-stop-it) covers malicious email campaigns. ### Check the domain controls behind suspected email spoofing If recipients are receiving messages that use your domain in the visible From field, check the domain's published DMARC record before changing email policy. The record shows the public policy and reporting destination your domain currently publishes. [Check the DMARC record](/tools/dmarc) A public DNS check cannot prove where one message originated, whether a receiver accepted it, or whether every production sender passes DMARC alignment. For an ongoing DMARC rollout, Palisade is agentic DMARC software that analyzes aggregate-report data, identifies sending sources and authentication or alignment issues, and creates prioritized remediation tickets. It can propose the next policy step when the evidence supports it, while your team reviews the evidence and applies the DNS change. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=existing-content-migration&utm_content=how-does-ip-spoofing-work-and-how-can-you-stop-it) Palisade does not block spoofed network packets, change a DMARC policy without human review, or guarantee a receiver's delivery decision. ## Sources and further reading - [RFC 2827: Network ingress filtering](https://datatracker.ietf.org/doc/html/rfc2827) - [RFC 3704: Ingress filtering for multihomed networks](https://datatracker.ietf.org/doc/html/rfc3704) - [RFC 8704: Requirements for unicast source-address validation](https://datatracker.ietf.org/doc/html/rfc8704) - [Palisade DMARC checker](/tools/dmarc) ## Frequently asked questions ### Can an attacker receive replies sent to a spoofed IP address? No. Replies route to the forged address, so an attacker who does not control or observe that address cannot normally receive them. That is one reason spoofing is more useful for one-way traffic and reflection attacks than for ordinary TCP sessions. ### Does a firewall stop all IP spoofing? No. A firewall can enforce anti-spoofing rules at the paths it controls, but source validation must cover relevant ingress and egress paths. Application authentication is still needed when access decisions require a reliable identity. ### Is IP spoofing the same as email spoofing? No. IP spoofing forges a packet's source IP address. Email spoofing impersonates an email identity, often the visible From domain. SPF, DKIM, and DMARC help receivers evaluate whether the email domain use is authorized. ### Can reverse-path filtering break legitimate traffic? Yes. Strict reverse-path filtering can reject valid packets when the return route differs from the incoming route. RFC 3704 describes multiple filtering approaches, so the chosen method should match the network's routing design. ### Does DMARC stop IP spoofing attacks? No. DMARC applies to email authentication and the visible From domain. It does not validate arbitrary IP packets or replace router ingress and egress filtering. --- # Inbox placement test: what it shows and what it cannot prove Canonical: https://www.palisade.email/learning/inbox-placement-test > Inbox placement test results show how a sample email reached seed mailboxes at one time, plus the evidence needed before changing a campaign. An inbox placement test sends a representative message to seed mailboxes and records whether those copies reach the inbox, spam folder, or go missing. It is useful provider-specific evidence for that message, test configuration, and time. It cannot forecast every recipient's outcome, reveal a mailbox provider's classifier logic, or guarantee where a later campaign will land. ## Quick takeaways - An inbox placement test records folder outcomes for seed addresses, not every subscriber. - Use a message and sending path that match the campaign or incident under investigation. - Record the exact message version, authenticated identifiers, send time, and seed group before interpreting a result. - A passing SPF, DKIM, or DMARC result does not determine inbox versus spam placement. - Compare seed-list observations with real-recipient complaint, bounce, and delivery evidence. - Retest after one evidence-supported change so the result remains comparable. ## What this tool checks An inbox placement test checks how a sample message is handled at a testing service's seed mailboxes. [Amazon Pinpoint's inbox placement test documentation](https://docs.aws.amazon.com/pinpoint/latest/userguide/channels-email-deliverability-dashboard-pipt.html) describes sending a sample message to special addresses at major email domains and reporting inbox, spam, missing, SPF, and DKIM outcomes by provider. This is narrower than the broader subject of [email deliverability](/email-deliverability). SMTP acceptance, delivery, and inbox placement are related observations, but an inbox placement test focuses on the folder result recorded for test copies. A seed-list result does not expose every recipient's engagement history, mailbox rules, complaint behavior, or a provider's private filtering decision. [Kit's guidance for analyzing inbox placement tests](https://help.kit.com/en/articles/4478092-inbox-placement-tests-how-to-analyze-the-results) notes that seed addresses do not have real subscriber engagement, so seed-test data does not always correlate with actual deliverability. If you already have a received copy of the message, Palisade's [email spam checker](/tools/email-deliverability-test) can inspect message-level SPF, DKIM, DMARC, sending-IP blocklist, and content signals. It does not operate a seed list, report Gmail or Outlook folder placement, continuously monitor the sending path, or guarantee inbox placement. ## How to run the check ### 1. Define the exact message and sending path Use a message that matches the campaign or incident you need to investigate. Keep the visible From address, envelope sender where available, DKIM signing domain, sending application, message content, links, and sending infrastructure consistent with the production path. Do not substitute a stripped-down test email for a campaign message. Different headers, links, or sending infrastructure make the result less useful. You can independently inspect the public DMARC record for the visible From domain: ```bash # Illustrative only. This confirms a public DNS answer, not inbox placement. dig +short TXT _dmarc.yourdomain.com ``` A public DNS lookup does not prove that the production sender used the expected return path, signed the message, or reached a particular folder. ### 2. Send the representative message to the supplied seed addresses Use the placement-testing service's supplied seed addresses and documented method. The provider's own seed list is necessary when you need its reported provider and folder outcomes. Send the message through the same application and route you intend to assess. If you must use a test path, label it as a test path rather than treating it as evidence of the production campaign. ### 3. Record the test evidence before changing anything Keep one record for every run. This makes later comparisons possible and prevents an overall placement percentage from hiding a changed sender, message, or audience. ```text INBOX PLACEMENT TEST EVIDENCE Message or campaign ID: campaign-2026-08-12-rev-b Visible From domain: yourdomain.com Envelope sender domain: mail.yourdomain.com DKIM d= domain and selector: yourdomain.com / selector1 Seed or test recipient group: provider seed group A Send time: 2026-08-12T14:30:00Z Observed result by receiver: inbox / spam / missing SMTP or bounce evidence: redacted delivery event or bounce category Authentication evidence: SPF, DKIM, and DMARC results from a delivered copy Change before retest: one documented variable Retest date: 2026-08-13 ``` Use redacted identifiers only when sharing this record outside the team. Do not include recipient addresses, authentication tokens, private headers, or customer data. An illustrative redacted result fragment might look like this: ```text Message ID: campaign-2026-08-12-rev-b Provider group: test-provider-a Observed folder: spam SPF / DKIM / DMARC: pass / pass / pass SMTP evidence: accepted by receiving system Retest condition: no change recorded ``` This fragment is an observation for one message, test configuration, and time. It is not a forecast for all recipients or an explanation of the receiving provider's classifier. ![Flow showing a representative message sent to seed addresses, provider folder observations, and comparison with authentication and sender-quality evidence.](/images/editorial/inbox-placement-test/inbox-placement-test-flow.svg "1200x626") *Source: [Amazon Pinpoint inbox placement tests](https://docs.aws.amazon.com/pinpoint/latest/userguide/channels-email-deliverability-dashboard-pipt.html), checked 2026-07-28.* ![Evidence flow for interpreting an inbox placement test as a time-bound observation.](/images/editorial/inbox-placement-test/inbox-placement-test-evidence-flow.webp "1200x676") *Source: Palisade.* ## How to interpret the results ### Inbox at the observed seed addresses An inbox result means the tested copy reached the inbox at the seed mailboxes reported for that run. It is evidence that the message and path worked under those conditions. Do not treat the result as a campaign-wide placement guarantee. Real subscribers have different engagement, complaint, and mailbox histories than seed addresses. ### Spam at one or more observed seed addresses A spam result identifies a provider, message version, and sending path that need more evidence. It does not identify one universal cause. First compare the tested message with the intended production path. Then inspect the delivered copy's authentication results, [check whether public blocklists name the sending domain](/tools/domain-reputation), and review sender-quality evidence for the same program, such as complaint and bounce trends. If real recipients also see spam placement, use the evidence-led workflow in [why outbound email goes to spam](/learning/why-do-your-emails-go-to-spam-and-how-can-you-fix-it). ### Missing at the observed seed addresses A missing result means the testing service did not report the expected copy in inbox or spam according to its method. Confirm the service's own definition, then inspect sent-message logs, delivery events, SMTP responses, and any bounce evidence. A missing seed observation does not prove that all mail was rejected or that a particular receiver policy caused the result. The provider's own dashboard or delivery logs may be the only source that can explain an account-specific decision. ### Passing authentication beside poor placement SPF, DKIM, and DMARC results are authentication evidence. They do not dictate a receiving provider's folder decision. For Gmail senders, [Google's sender guidelines](https://support.google.com/a/answer/81126) direct senders to keep the Postmaster Tools spam rate below 0.3% and recommend staying below 0.10%. This is Gmail-specific guidance. It does not convert a seed-list outcome into a prediction of real-recipient placement. ## How to act on the result ### Authentication mismatch If the delivered copy does not match the intended visible From domain, envelope sender, or DKIM signing domain, stop treating the seed result as a clean campaign test. Correct the demonstrated configuration mismatch, then send a new representative message through the same path. Validate DNS through the authoritative server and at least one public resolver. Next, confirm the sender's current status in its own interface, inspect a delivered message's authentication results, and review DMARC aggregate reports after data accumulates. A green DNS or vendor result alone does not prove the production message used that configuration. ### A single-provider observation If only one provider group reports spam or missing placement, preserve the result and avoid broad DNS or content changes. Compare the provider observation with the same message's SMTP evidence, authentication results, complaint trend, and bounce pattern. Escalate to the provider's own dashboard or support path if you need an account-specific explanation. A public checker cannot inspect a receiver's private policy decision. ### A repeatable pattern If comparable tests repeatedly show the same provider and folder outcome, review the real-recipient program data for the same sender and message class. Check list source, recent volume changes, complaint behavior, bounce patterns, and whether the production path actually matches the tested path. Make one change supported by the evidence, document it in the test record, and retest. Readers evaluating whether a placement-monitoring category fits their program can use [the email deliverability service guide](/learning/best-email-deliverability-service) to distinguish placement monitoring from message authentication diagnostics and related services. ## How to retest Repeat the same seed-list method after the documented change. Keep the same representative sender, message class, and sending path where possible. Compare provider and folder outcomes with the earlier evidence record rather than relying on one summary percentage. Then inspect a newly delivered copy of that same message. Confirm SPF, DKIM, and DMARC results from the actual sending path. Review real-recipient complaint and bounce data separately. These are distinct evidence layers, and disagreement between them is useful evidence. ## Check the message-level signals behind the placement snapshot After recording the seed-list result, inspect a received copy of the same representative message for the controllable technical signals Palisade can assess. [Check the message-level signals Palisade can inspect](/tools/email-deliverability-test) Palisade's test can inspect SPF, DKIM, DMARC, blocklist, and content signals from a received message. It does not operate a seed list, determine a receiving provider's folder, explain a provider classifier, or guarantee inbox placement. ## Sources and further reading - [Amazon Pinpoint inbox placement tests](https://docs.aws.amazon.com/pinpoint/latest/userguide/channels-email-deliverability-dashboard-pipt.html) - [Kit guidance for analyzing inbox placement tests](https://help.kit.com/en/articles/4478092-inbox-placement-tests-how-to-analyze-the-results) - [Google sender guidelines](https://support.google.com/a/answer/81126) - [Palisade email spam checker](/tools/email-deliverability-test) ## Frequently asked questions ### Does an inbox placement test guarantee campaign inbox placement? No. It records how a specific message reached the service's seed mailboxes at a particular time. Recipient engagement, mailbox history, sending conditions, and provider decisions can differ for a live campaign. ### Does a passing SPF, DKIM, and DMARC result mean the message will reach the inbox? No. Passing authentication shows that the message met those authentication checks. Receiving providers can use other signals when deciding placement. ### Should I change DNS after one spam result? Only when the evidence shows an authentication or configuration problem. A single spam observation without a demonstrated DNS mismatch does not establish that a DNS change is the right repair. ### What should I collect with a seed-list result? Record the exact message or campaign ID, sender domains, authenticated identifiers, seed group, send time, provider and folder observation, SMTP or bounce evidence, authentication results, and planned retest date. ### Can Palisade test Gmail or Outlook inbox placement? No. Palisade's email deliverability test inspects message-level authentication, blocklist, and content signals from a received message. It does not report Gmail or Outlook folder placement. --- # Instantly email warmup Canonical: https://www.palisade.email/learning/instantly-email-warmup > Instantly email warmup uses pool-based message activity and a Health Score, but it does not prove campaign authentication or inbox placement. Instantly email warmup is an account-level feature that exchanges automated warmup messages within Instantly's pool and reports a Health Score. Instantly documents that score as a recent warmup inbox-versus-spam signal. It can show activity within the feature, but it does not prove that a real campaign is authenticated, reaches a particular recipient inbox, or will have the same result with a specific audience. ## Quick takeaways - Instantly Warmup applies to an enabled email account, not every system that can send with the same visible From domain. - Instantly says enabled accounts exchange warmup emails within its user pool, with automatic opens and replies. - Instantly describes Health Score from warmup emails that reached inboxes versus spam folders during the prior seven days. - A Health Score is not proof of SPF, DKIM, or DMARC alignment on a real campaign message. - A vendor status or warmup signal does not reveal a receiver's private filtering decision for a future campaign. - Validate public DNS, the sending provider, a delivered production-path message, and DMARC reports separately. ## What should I check before configuring Instantly? First, identify the exact sending path you are assessing. Instantly Warmup concerns the connected outreach account. Marketing outreach, transactional email, employee mail, and another ESP can all use the same visible From domain while having different authentication and reputation evidence. You need access to the intended Instantly account and to a mailbox that can receive a real test message with raw headers available. If the sending domain needs authentication changes, you also need access to the authoritative DNS zone and the sending provider's account-specific setup values. Instantly's [Warm-Up explanation](https://help.instantly.ai/en/articles/5975329-how-warm-up-works-and-why-it-s-important) describes pool activity, not DNS configuration for your domain. > Copy DNS values from the account and domain you are configuring. Do not publish selectors, targets, tokens, or hostnames from another account or from an online example. Keep the question narrow. A warmup signal may help you understand activity for one connected account. It cannot establish list consent, campaign content quality, recipient engagement, a private receiver decision, or the behavior of another outbound route. ## Which setup method should I use? Use Instantly Warmup when you want to review the vendor's documented account-level warmup activity. Use a delivered message from the real campaign route when the question is whether that route authenticates correctly or reaches a test mailbox as expected. Instantly's [Email Accounts dashboard documentation](https://help.instantly.ai/en/articles/11991261-getting-started-with-the-email-accounts-dashboard) describes the account dashboard that exposes Warmup-related information. The screenshot is evidence of the vendor's account-level view. It is not evidence that a campaign reached an inbox. ![Instantly Email Accounts dashboard showing account-level Warmup information and Health Score](/images/editorial/instantly-email-warmup/instantly-email-accounts-warmup-dashboard.png "1260x373") *Source: [Getting started with the Email Accounts dashboard](https://help.instantly.ai/en/articles/11991261-getting-started-with-the-email-accounts-dashboard), checked 2026-07-28.* Do not use a dedicated IP choice in another sending service as a substitute for authentication or message validation. That infrastructure choice and Instantly's Warmup feature answer different questions. ## How do I configure SPF and DKIM for Instantly? Instantly Warmup does not publish SPF or DKIM records for your domain. Configure authentication in the service that sends the campaign, then validate a newly delivered message from that same route. Instantly documents Warmup controls under [Email Accounts > Settings](https://help.instantly.ai/en/articles/7988514-warmup-settings), but those controls do not create a DKIM selector, publish DNS, or change a DMARC policy. ### 1. Identify the campaign's actual sending domain Record the visible From domain, the connected Instantly account, the provider account, and the campaign or mailbox route in scope. A connected inbox might send through Google Workspace, Microsoft 365, or another SMTP service. The service that signs the message must provide the authentication instructions. ### 2. Review the connected account's Warmup settings Open **Email Accounts > Settings** for the connected account, following Instantly's [Warmup Settings documentation](https://help.instantly.ai/en/articles/7988514-warmup-settings). Confirm the selected account before interpreting its Warmup activity or changing its settings. The documented path was verified from Instantly's Help Center. Warmup settings affect feature activity for the selected account. They do not establish authentication for the campaign route. ### 3. Retrieve authentication values from the actual sending provider Open the current documentation and account interface for the provider that sends the campaign. Copy its account-generated SPF and DKIM values into the approved DNS change. The record shapes below are illustrative only. They show the records to identify, not records to publish. **Record type:** `TXT` **Host (illustrative only):** ```text yourdomain.com ``` **Value (illustrative only):** ```text v=spf1 include:provider.example ~all ``` **Record type:** `TXT` **Host (illustrative only):** ```text selector1._domainkey.yourdomain.com ``` **Value (illustrative only):** ```text v=DKIM1; k=rsa; p=<provider-generated-public-key> ``` > Do not publish these examples. Copy the complete values generated by the service that sends your campaign. If an SPF record already exists, add authorized mechanisms to that single SPF record rather than publishing a second SPF record. Some DNS providers append the zone name to the host field. Check the final fully qualified owner before saving. Entering a full domain in a host field that appends `yourdomain.com` can create a duplicated and invalid owner name. ### 4. Verify the records in the sending provider Wait for the provider to accept the published records, then review its authentication status. A passing provider indicator shows that the provider accepted its current configuration. It does not prove that a campaign message used the expected return path or DKIM signature. If the provider reports a DNS error, compare its complete account-generated values against the authoritative DNS response before editing anything. ### 5. Send a real test message through the campaign path Send a new message through the same account, provider, and route intended for production. Deliver it to a mailbox where you can inspect raw source. Check the `DKIM-Signature` field and the receiver-added authentication assessment. [RFC 8601 defines the Authentication-Results field and explains its trust boundary](https://www.rfc-editor.org/rfc/rfc8601.html). A header copied into a message by an untrusted sender is not equivalent to an assessment added by the receiving system. Retain only a redacted header copy in the change record. ## How does this setup affect DMARC? DMARC evaluates whether SPF or DKIM passes with an identifier aligned to the visible From domain, then applies the domain's published DMARC policy. [RFC 9989 defines the relationship between the RFC5322.From domain, SPF, DKIM, alignment, and DMARC policy](https://www.rfc-editor.org/rfc/rfc9989.html). Instantly Warmup does not publish a DMARC record or establish DMARC alignment for a campaign. Use Palisade's [DMARC checker](/tools/dmarc) to inspect the public DMARC record for the visible From domain before changing policy. A public DNS result cannot prove which identifier a particular campaign used, whether that message passed alignment, or which folder a recipient selected. For the broader setup context, use the [vendor email authentication learning hub](/learning/esp-setup). A warmup signal can coexist with a real-message authentication failure. ![Evidence boundary between Instantly Warmup activity and the separate evidence needed for campaign authentication and placement](/images/editorial/instantly-email-warmup/instantly-email-warmup-evidence-boundary.webp "1200x442") *Source: Palisade.* ## How do I validate the setup? ### Check public DNS Query the SPF, DKIM, and DMARC owners used by the campaign domain. Compare the authoritative DNS answer with at least one public resolver. ```bash dig +short TXT yourdomain.com dig +short TXT selector1._domainkey.yourdomain.com dig +short TXT _dmarc.yourdomain.com ``` These checks show what public DNS returns at the time of the query. They do not show private routing, a recipient's filtering decision, or future campaign placement. ### Check the vendor status Review the sending provider's authentication status, then review the selected Instantly account's Warmup status. Instantly's [campaign-readiness guidance](https://help.instantly.ai/en/articles/13938078-when-your-email-account-is-ready-for-campaigns) includes its own recommendations for warmup duration and Health Score. Treat those as Instantly feature guidance, not a mailbox-provider guarantee. A green status in either system is not a delivered-message check. ### Inspect a delivered message Inspect a new message from the exact production route. Confirm the visible From domain, the envelope or return-path identifier where available, the DKIM `d=` domain and selector, and the trusted `Authentication-Results` values. For DMARC, the relevant result is whether an SPF or DKIM pass aligns with the visible From domain. A DKIM pass for an unrelated domain can be valid cryptographically but still fail DMARC alignment. ### Review DMARC reports After aggregate reports accumulate, review the sources that use the sending domain and their authentication and alignment results. This separates the selected Instantly-connected route from other legitimate or unknown sources using the same domain. Warmup activity does not replace this inventory. It measures a different set of exchanges. ## Record the evidence before deciding what changed Use a short evidence record when reviewing a Health Score or an isolated delivery observation. It prevents a warmup signal from being treated as proof about a different account, domain, or campaign. ```text Sending domain: outreach.yourdomain.com Visible From address: sender@outreach.yourdomain.com Authenticated identifiers observed: SPF smtp.mailfrom=..., DKIM d=..., selector=... Provider and campaign context: connected account and campaign name or ID Observed volume and timing: message count, send window, and warmup period Test evidence: redacted delivered headers and recipient-folder observation Question to answer: Does this production route pass DMARC and reach this test mailbox? ``` This is an illustrative operational record, not an Instantly interface or a vendor-required format. Record the exact question before drawing a conclusion. A Health Score can establish Instantly's reported warmup activity for its pool over the metric's stated period. It cannot establish the reputation of every sender using the domain, the treatment of a particular campaign, or the placement decision of a particular mailbox. One inbox observation can be useful evidence for that one route and test recipient. It is still not a receiver-wide result. ## Troubleshooting ### The Health Score is high but a campaign message fails DMARC Inspect a newly delivered campaign message and compare the visible From domain with the SPF and DKIM identifiers. A warmup score does not create alignment or change DNS. Correct the authentication configuration in the service that actually sends the campaign, then retest the same path. ### The sending domain changed after warmup began Treat the new domain as a separate authentication and message-validation scope. Check its published SPF, DKIM, and DMARC records, verify the provider configuration for that domain, and send a new message from the new route. Do not use the previous account's warmup history as evidence for the new domain. ### A test message went to spam in one mailbox Keep the raw headers, send time, sender account, recipient mailbox, and campaign context. Confirm authentication first. Then determine whether the observation is isolated or repeats across controlled tests. For an evidence-led diagnosis of real-message filtering, see [why emails go to spam and how to fix it](/learning/why-do-your-emails-go-to-spam-and-how-can-you-fix-it). Do not infer a universal reputation or placement result from one folder outcome. ### DNS looks correct but the provider remains unverified Check the authoritative record owner and the complete account-generated value. Look for a duplicated DNS suffix, a truncated TXT value, an existing conflicting record, or a change made in the wrong zone. If the record is correct publicly, follow the provider's documented verification process before replacing it. ### Warmup activity does not answer the operational question If the unresolved question is whether warmup is a useful service category, review [does email warmup work?](/learning/does-email-warmup-work) and [email warmup service: compare the evidence before choosing](/learning/email-warmup-service). If the question is campaign authentication or a specific message result, continue with DNS, provider, and delivered-message evidence instead. ## Sources and further reading - [Instantly: How Warm-Up Works and Why it's Important](https://help.instantly.ai/en/articles/5975329-how-warm-up-works-and-why-it-s-important) - [Instantly: Warmup Settings](https://help.instantly.ai/en/articles/7988514-warmup-settings) - [Instantly: When Your Email Account Is Ready for Campaigns](https://help.instantly.ai/en/articles/13938078-when-your-email-account-is-ready-for-campaigns) - [Instantly: Getting started with the Email Accounts dashboard](https://help.instantly.ai/en/articles/11991261-getting-started-with-the-email-accounts-dashboard) - [RFC 8601: Authentication-Results](https://www.rfc-editor.org/rfc/rfc8601.html) - [RFC 9989: DMARC](https://www.rfc-editor.org/rfc/rfc9989.html) ## Frequently asked questions ### Does Instantly email warmup guarantee inbox placement? No. Instantly's Health Score reports warmup-pool activity over its stated measurement period. It does not guarantee where a real campaign will land for a specific recipient, audience, provider, or future send. ### Does a high Instantly Health Score prove SPF, DKIM, and DMARC pass? No. SPF, DKIM, and DMARC need separate DNS and delivered-message evidence from the production campaign route. A warmup metric does not publish DNS records or prove identifier alignment. ### Can I use one warmup result for every sender using my domain? No. Each sending route can use different providers, envelope identifiers, DKIM selectors, content, and recipient patterns. Validate every materially different route that sends with the domain. ### What should I check after changing a campaign sending domain? Check the new domain's public SPF, DKIM, and DMARC records, the sending provider's verification state, and a newly delivered message from the exact route. Existing warmup history for another domain is not proof for the new one. ### Does one message in spam prove the domain has a reputation problem? No. It proves an observed folder result for that message and mailbox. Preserve the redacted headers and sending context, confirm authentication, then repeat controlled tests before making broader conclusions. --- # Mailchimp one-click unsubscribe: headers, body links, and validation Canonical: https://www.palisade.email/learning/mailchimp-one-click-unsubscribe > Mailchimp's body unsubscribe link takes two clicks, which does not disable header-based one-click. Verify the header in a real campaign, not a preview. Mailchimp's two-click unsubscribe page for a link in an email body does not replace or disable header-based one-click unsubscribe. Mailchimp says the body or footer link opens a confirmation page to limit accidental opt-outs, while Gmail and Yahoo evaluate one-click capability from message headers. Send a safe test through the same Mailchimp campaign path and inspect its raw source before treating the requirement as met. ## Quick takeaways - Mailchimp sends a body or footer unsubscribe link through a confirmation page, so that path takes two recipient clicks. - Mailchimp says that body-link safeguard does not affect the header-based process Gmail and Yahoo use for one-click unsubscribe. - Header-based one-click capability is governed by [RFC 8058](https://www.rfc-editor.org/rfc/rfc8058.html), not by the number of clicks in the email body. - Google applies its one-click requirement to covered bulk senders of marketing and subscribed messages, while still requiring a visible body unsubscribe link. - A delivered message can show the headers Mailchimp emitted. It cannot prove that a mailbox will render a control or that an endpoint completed an opt-out. ## Who is affected? This page is for Mailchimp operators sending marketing campaigns to Gmail or Yahoo recipients. Mailchimp's [About Unsubscribes documentation](https://mailchimp.com/help/about-unsubscribes/) requires an unsubscribe method in its email campaigns and explains that its body-link confirmation step is intended to reduce accidental unsubscribes caused by bot or filter clicks. That documented body-link behavior is distinct from the source-code headers used for the provider-controlled one-click process. The recipient's mailbox decides whether to show an unsubscribe control. You should keep Mailchimp's visible link in the message and verify the headers in a received copy. If the question is how the RFC header pair and endpoint work, use the vendor-neutral [one-click unsubscribe guide](/learning/one-click-unsubscribe). If you are reviewing the wider provider checklist, see [sender requirements](/learning/google-is-making-email-sender-requirements-stricter-starting-nov-2025). Unsubscribe evidence is separate from domain authentication and inbox placement. The [Mailchimp SPF and DKIM setup guide](/learning/how-do-i-set-up-spf-and-dkim-for-mailchimp) covers authentication records, while the [Mailchimp spam-placement guide](/learning/why-does-mailchimp-email-go-to-spam-after-it-is-marked-delivered) covers a different recipient-side outcome. ## What are the requirements? ### Mailchimp's body link is a separate path Mailchimp says a subscribed contact who selects the unsubscribe link in a marketing email's body or footer reaches an unsubscribe page and must select unsubscribe again. Mailchimp also states that this two-click process does not affect the one-click unsubscribe process available through [email headers](/tools/email-header-analyzer), which Gmail and Yahoo require rather than a one-click body link. [Mailchimp's unsubscribe guidance](https://mailchimp.com/help/about-unsubscribes/) is the controlling source for that product-specific distinction. ![Decision flow separating Mailchimp's body-link confirmation path from the header-based provider one-click path and its separate evidence boundary.](/images/editorial/mailchimp-one-click-unsubscribe/mailchimp-one-click-unsubscribe-decision-flow.svg "1200x549") *Source: Original Palisade decision flow based on [Mailchimp's About Unsubscribes documentation](https://mailchimp.com/help/about-unsubscribes/) and [RFC 8058](https://www.rfc-editor.org/rfc/rfc8058.html). It illustrates documented paths and evidence boundaries, not a Mailchimp or mailbox interface.* ### Header-based one-click needs the RFC pair RFC 8058 specifies a `List-Unsubscribe` field containing an HTTPS URI and a `List-Unsubscribe-Post` field containing `List-Unsubscribe=One-Click`. The RFC requires valid DKIM coverage for both fields. A mailbox provider may use that pair to perform an HTTPS POST to the listed URI after its recipient chooses the provider's control. Mailchimp's body-link confirmation page neither proves nor disproves that those headers were included in a particular campaign. ```text List-Unsubscribe: <https://unsubscribe.example.invalid/token/opaque-value> List-Unsubscribe-Post: List-Unsubscribe=One-Click ``` This is an illustrative RFC-shaped header pair, not a Mailchimp value to copy. The delivered message is the evidence for the actual sending path. ### Google's scope still includes a visible link [Google's email sender guidelines](https://support.google.com/a/answer/81126) apply one-click unsubscribe to marketing and subscribed messages from senders that deliver more than 5,000 messages per day to personal Gmail accounts. Those covered messages must also include a clearly visible unsubscribe link in the message body. The header capability and the body link therefore serve separate requirements, even when they both lead to an opt-out. ## When does the requirement take effect? Google lists February 1, 2024 as the effective date for its bulk-sender requirements. The relevant current scope is the sender's daily volume to personal Gmail accounts and the message type, not whether Mailchimp's body link needs a confirmation click. Recheck [Google's live sender guidelines](https://support.google.com/a/answer/81126) if campaign volume, recipient mix, or provider policy changes. Mailchimp's cited documentation does not state that every campaign path always emits an RFC 8058 header pair. Treat a raw message from the same account, campaign type, From identity, and audience path as the test evidence. Mailchimp Transactional is a separate product with its own [outbound-email documentation](https://mailchimp.com/developer/transactional/docs/outbound-email/), so do not use transactional documentation as proof of a Marketing campaign's headers. ## How do I implement the requirement? ### 1. Keep the Mailchimp body unsubscribe link Use Mailchimp's required unsubscribe mechanism in the campaign body or footer. Do not remove it because a mailbox might offer a header-based control. Mailchimp documents the body link as the platform's unsubscribe process, and Google separately requires a visible link for covered bulk marketing and subscribed messages. ### 2. Send a safe campaign-path test Send a test through the exact Mailchimp product, campaign type, From identity, and authenticated domain you use in production. Address it to a mailbox you control and do not trigger an opt-out against a customer address. This test is needed because a campaign's actual source, rather than the visual editor or body link, establishes which headers were emitted. ### 3. Escalate missing or unclear header evidence to Mailchimp support If the raw source lacks either RFC 8058 header, preserve the test headers and campaign context before contacting Mailchimp support. Do not add a self-hosted unsubscribe endpoint or hand-edit a campaign as a workaround unless Mailchimp documents that option for the exact product path. A different path could create an inconsistent suppression process. ## How do I validate compliance? Open the received message's original source and look for `List-Unsubscribe` and `List-Unsubscribe-Post: List-Unsubscribe=One-Click`. For an RFC 8058 implementation, the first field needs an HTTPS URI and the second has the exact one-click value. Also check the DKIM signature's `h=` list for both header names, as RFC 8058 requires. Keep the headers as evidence, but do not publish recipient-specific URLs or tokens. Then verify the limits of that result. A test source can show whether Mailchimp emitted the relevant header pair. It cannot prove that Gmail, Yahoo, or another mailbox will render a specific control, that the provider's POST succeeded, or that all audience and suppression records updated. Keep the body link available and investigate any recipient-specific unsubscribe result through the authorized account workflow. ## Continue the provider-requirement review After you capture the campaign headers, use the [Gmail and Yahoo sender requirements checklist](/learning/google-is-making-email-sender-requirements-stricter-starting-nov-2025) to review the remaining sender requirements. That checklist does not inspect a private Mailchimp account, a received message, endpoint response, or audience state, so retain the raw-message evidence from this test. ## Sources and further reading - [Mailchimp: About Unsubscribes](https://mailchimp.com/help/about-unsubscribes/) - [RFC 8058: Signaling One-Click Functionality for List-Unsubscribe Email Header Fields](https://www.rfc-editor.org/rfc/rfc8058.html) - [Google: Email sender guidelines](https://support.google.com/a/answer/81126) - [Mailchimp Transactional: Outbound Email](https://mailchimp.com/developer/transactional/docs/outbound-email/) ## Frequently asked questions ### Does Mailchimp's two-click unsubscribe page fail the one-click requirement? No. Mailchimp says its two-click process affects the unsubscribe link in the email body or footer, while Gmail and Yahoo evaluate one-click capability through email headers. Check the delivered source rather than counting clicks on the body link. ### Can I remove Mailchimp's unsubscribe link if headers are present? No. Mailchimp requires its unsubscribe method in email campaigns, and Google requires a clearly visible body unsubscribe link for covered bulk marketing and subscribed messages. Header-based one-click capability supplements that visible path. ### Does a List-Unsubscribe header prove that one-click works? No. A `List-Unsubscribe` field alone is not the RFC 8058 pair. Confirm `List-Unsubscribe-Post: List-Unsubscribe=One-Click` and DKIM coverage for both fields, then keep the result separate from a mailbox's rendering or endpoint outcome. ### Does this apply to Mailchimp Transactional email? Not automatically. Mailchimp Transactional has separate documentation and an API or SMTP sending path. Test its delivered messages independently and use its documentation only for its own product scope. ### Should I click an unsubscribe control while testing? Only with an authorized test recipient and a documented test plan. Header inspection is safe evidence for the emitted message. An unsubscribe action can change recipient or audience state, so do not use a customer address for this test. --- # Mailgun email warmup: when to warm a dedicated IP Canonical: https://www.palisade.email/learning/mailgun-email-warmup > Mailgun senders on shared IPs do not need new-IP warmup. Learn when a new dedicated IP needs a controlled ramp and what to verify. Mailgun says senders use a shared IP by default, and that a shared IP does not need new-IP warmup. If your Mailgun traffic moves to a new dedicated IP, use a controlled increase of legitimate mail to engaged recipients and monitor the actual sending path. A new domain can need similar care. Neither a Mailgun warmup plan nor a ramp proves that a production message authenticates correctly, has consent, or will reach an inbox. ## Quick takeaways - Mailgun's shared-IP default does not need a new-IP warmup. - A new dedicated IP is the case Mailgun documents for a gradual ramp. - Start with legitimate mail to engaged recipients, then review the same sending path as volume changes. - A new domain may need its own reputation-building care even when the IP is established. - Warmup activity does not replace authentication, consent, delivery, complaint, or recipient-path evidence. ## When does Mailgun email warmup apply? The first decision is the IP model, not a generic warmup calendar. Mailgun's [IP warm-up guidance](https://help.mailgun.com/hc/en-us/articles/1260803448249-Can-you-describe-the-IP-warm-up-process) says a shared IP does not need an IP warm-up, while a new dedicated IP needs to be warmed before use. The same guidance says the pace depends on the sender's program and calls for a gradual increase rather than an immediate full-volume launch. That distinction matters because a shared IP and a dedicated IP expose different evidence problems. Mailgun notes that activity from other senders can affect a shared IP. With a new dedicated IP, your own production traffic is the path being introduced. Do not copy another account's quota, date, or plan into either case. For the vendor-neutral operating rule, see the [email warmup schedule](/learning/email-warmup-schedule). ![Decision card separating Mailgun shared-IP sending from new dedicated-IP warmup and showing the production evidence required in either case.](/images/editorial/mailgun-email-warmup/mailgun-email-warmup-decision-card.svg "1200x601") *Source: Original Palisade deterministic decision card based on Mailgun's [IP warm-up guidance](https://help.mailgun.com/hc/en-us/articles/1260803448249-Can-you-describe-the-IP-warm-up-process) and [domain warm-up guidance](https://www.mailgun.com/blog/deliverability/domain-warmup-reputation-stretch-before-you-send/). It separates sending-path decisions from production evidence; it is not a Mailgun interface, account plan, or inbox-placement prediction.* ## What should a dedicated-IP ramp use as evidence? Mailgun advises increasing the volume sent through a dedicated IP step by step and focusing on recipients who find the mail valuable. Its [current warm-up article](https://www.mailgun.com/blog/deliverability/domain-warmup-reputation-stretch-before-you-send/) also distinguishes IP warmup from domain warmup and notes that a new domain can need a related controlled approach. Those are provider-specific recommendations, not a universal schedule or a guarantee. Use the ramp to produce evidence from real mail. Google's [email sender guidelines](https://support.google.com/mail/answer/81126?hl=en) advise senders to increase volume slowly, avoid sudden spikes, and monitor delivery, spam rate, server responses, and sending-[domain reputation](/tools/domain-reputation). They also require authentication for the actual messages sent to Gmail. That makes a warmup plan an operating process, not a substitute for testing the production identity. ```text MAILGUN SENDING-PATH REVIEW IP model: shared IP or new dedicated IP Sending identity: From domain and Mailgun route under review Authentication: SPF, DKIM, and DMARC on a representative delivered message Audience: legitimate recipients who expect the mail Observed results: delivery, SMTP responses, complaints, and available reputation signals Decision: hold or investigate when the same path worsens; do not infer inbox placement from a warmup plan ``` ## What Mailgun warmup cannot prove Mailgun's documentation describes a provider-side warmup process and the signals it recommends watching. It does not publish a rule that a warmup state proves the authentication result of your message, recipient consent, or a future inbox decision. That conclusion is an inference from the different evidence scopes, not a claim about Mailgun's private placement logic. Confirm the `From` domain and authentication result on a representative delivered message before changing volume. [What DMARC does](/learning/what-is-dmarc) explains why alignment is evaluated against the visible domain, while [email deliverability](/email-deliverability) covers the wider outcome beyond provider acceptance. If real messages are already filtering, investigate the message, consent, and sender history instead of treating more warmup activity as the repair. Mailgun's public [IP warmup glossary](https://www.mailgun.com/glossary/ip-warmup/) describes warmup as a gradual increase in volume for a new IP. It does not turn automated mailbox activity into equivalent evidence. If you are assessing that separate mechanism, read [automated email warmup](/learning/email-warmup-service). ## Check the public authentication baseline before a ramp Before you raise volume on a domain you manage, use the [Email Security Score](/tools/email-security-score) to inspect its published SPF, DKIM, DMARC, and BIMI posture. That is a useful first check when the available evidence is a domain name. It cannot inspect the Mailgun account, confirm dedicated-IP allocation, read recipient consent, validate a delivered-message route, or determine inbox placement. If recurring DMARC-report evidence later shows unknown senders or alignment failures, [Palisade's remediation guide](https://docs.palisade.email/guides/fixing-authentication-issues/) describes how Palisade's DMARC Agent analyzes aggregate-report data, identifies sending sources and authentication or alignment issues, and creates prioritized remediation tickets. A human reviews the evidence and applies changes. Palisade does not operate Mailgun, warm an IP, change DNS automatically, or guarantee delivery or placement. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=email_deliverability&utm_content=mailgun-email-warmup) only when that recurring sender-evidence work remains after the immediate check. ## Sources and further reading - [Mailgun: Can you describe the IP warm-up process?](https://help.mailgun.com/hc/en-us/articles/1260803448249-Can-you-describe-the-IP-warm-up-process) - [Mailgun: Domain warm-up and reputation](https://www.mailgun.com/blog/deliverability/domain-warmup-reputation-stretch-before-you-send/) - [Mailgun: IP warmup glossary](https://www.mailgun.com/glossary/ip-warmup/) - [Google: Email sender guidelines](https://support.google.com/mail/answer/81126?hl=en) - [Palisade: Fixing authentication issues](https://docs.palisade.email/guides/fixing-authentication-issues/) ## Frequently asked questions ### Do I need to warm up a Mailgun shared IP? No. Mailgun says shared-IP sending does not need a new-IP warmup. Still check the authentication and outcomes for your own production path, because another sender's shared-IP activity can affect that IP's reputation. ### When should I warm a Mailgun dedicated IP? When you begin sending through a new dedicated IP. Mailgun documents a gradual increase for this case. Set the pace from the account's current guidance and results from legitimate, engaged-recipient mail rather than copying a universal calendar. ### Does a new Mailgun domain need warmup? Yes, it may. Mailgun says a newer domain can need a similar process to establish domain reputation. Keep that distinct from the dedicated-IP question, and use the actual domain and message evidence to decide the next change. ### Does Mailgun warmup guarantee inbox placement? No. A provider warmup process does not control a receiver's inbox decision. Authentication, consent, message quality, complaints, reputation, and recipient-provider signals remain relevant to a particular message. ### Can an Email Security Score validate Mailgun warmup? No. The score can inspect public authentication records for a domain. It cannot read Mailgun account settings, a dedicated-IP assignment, warmup status, recipient consent, or a recipient mailbox result. --- # Managed DMARC service SLA Canonical: https://www.palisade.email/learning/managed-dmarc-service-sla > Use a managed DMARC service SLA to define evidence, client approvals, response commitments, exclusions, and escalation across client domains. A managed DMARC service SLA should define the domains covered, the evidence that starts work, the MSP's response commitment, the client's approval duties, and the outcomes outside the service's control. For a multi-client portfolio, use the same record for each domain but keep sender authorization, DNS changes, and DMARC policy decisions with the client. [RFC 9989](https://www.rfc-editor.org/rfc/rfc9989.html) defines the protocol, not service-level targets. ## Quick takeaways - State whether the SLA covers monitoring, investigation, change coordination, reporting, or only selected domains. - Start an obligation from a recorded observation, ticket, or approved change request rather than an assumed sender or threat. - Separate an MSP recommendation from the client approval required to change DNS, sender settings, or DMARC policy. - Make exclusions explicit: receiver decisions, sender-vendor fixes, and delivery outcomes are not controlled by the SLA. - Review open exceptions by client, domain, owner, and next review date. ## Operating context and ownership This framework is for an MSP operating DMARC across multiple client domains. The service lead owns the SLA record and client communication. An authentication specialist reviews report evidence. The client service owner confirms business purpose and accepts risk. The DNS or sender owner applies approved changes. One person may fill more than one role, but each responsibility should still be named. DMARC aggregate reports are feedback about receiver-observed mail and policy results, not a list of pre-authorized services. [RFC 9990](https://www.rfc-editor.org/rfc/rfc9990.html) defines the aggregate-report data model. The service model below is a Palisade operating recommendation, not an RFC requirement or a guaranteed response time. ## Evidence to collect Create one service record for every material item. It should preserve the observation, the commitment that applies, and the decision still needed. A sender inventory provides the supporting ownership record, so link the SLA item to the relevant [MSP email sender inventory](/learning/msp-email-sender-inventory) entry rather than accepting a provider name as proof of authorization. ```yaml client: "Northwind Manufacturing" domain: "example.invalid" service_area: "aggregate-report review" evidence: "new source with repeated DMARC failure" recorded_at: "2026-07-29" msp_commitment: "classify evidence and request owner context" client_responsibility: "confirm sender purpose and approve any change" escalation_trigger: "business-critical sending path may be affected" excluded_outcome: "receiver delivery decision" next_review: "2026-08-05" ``` The values are illustrative. They do not prescribe an SLA clock, a risk threshold, or an account configuration. Where an item needs a policy decision, compare the observation with the domain's current policy and alignment rules in [RFC 9989](https://www.rfc-editor.org/rfc/rfc9989.html) before asking for a change. ![Managed DMARC SLA matrix showing evidence input, MSP commitment, client responsibility, escalation trigger, and excluded outcome.](/images/editorial/managed-dmarc-service-sla/managed-dmarc-service-sla-matrix.svg "1360x950") *Source: Original deterministic Palisade operating framework based on [RFC 9989](https://www.rfc-editor.org/rfc/rfc9989.html) and [RFC 9990](https://www.rfc-editor.org/rfc/rfc9990.html). It illustrates service boundaries, not a protocol requirement.* Use the matrix to write the agreement in operational language. For example, “review” means classify the supplied evidence and ask a focused question. It does not mean that the MSP authorizes a sender, changes a DNS zone, or promises that a receiver will accept mail. ## How to run the workflow ### 1. Define the client and domain scope List the covered domains, sender populations, report destinations, service hours, and named client contacts. Then state what is outside scope, such as domains managed by another provider or sender-vendor remediation. The scope should distinguish ongoing review from the separate implementation work in [Managed DMARC setup](/learning/how-can-i-set-up-managed-dmarc-with-palisade). ### 2. Classify the evidence before promising an action Record whether the trigger is an aggregate-report observation, a client ticket, a planned sender change, or a missed review. A report can show a source and an authentication outcome, but the client or sender owner still supplies the business context. Give the item a status such as evidence-limited, awaiting owner confirmation, approved for change coordination, or exception. This prevents a generic alert from becoming an unapproved configuration task. ### 3. Apply the matching service commitment For a routine observation, commit to reviewing the record and requesting missing context. For a suspected impact to a critical sending path, commit to notifying the named client contact and preparing a scoped decision. For approved changes, commit to coordination and a post-change evidence check. Do not write a blanket “resolve” commitment unless the agreement also names the systems and authority needed to resolve it. ### 4. Obtain the client decision and hand off the change Present the evidence, recommendation, possible consequence, and proposed owner. The client decides whether a sender remains authorized and whether a change is acceptable. The DNS or sender owner performs the external change. Use the [DMARC QBR reporting workflow](/learning/dmarc-qbr-reporting) to carry open decisions and their dates into the recurring review, instead of treating an SLA acknowledgement as closure. ### 5. Recheck and close the service record After an approved change, recheck the relevant public record, delivered-message evidence when available, and later aggregate-report data. Close the record only when the agreed evidence has been reviewed. If the observation persists or evidence is unavailable, retain it as an exception with an owner and review date. ![Portfolio escalation flow from receiver observation through MSP classification, client decision, approved change coordination, and later evidence review.](/images/editorial/managed-dmarc-service-sla/managed-dmarc-service-sla-escalation.svg "1200x900") *Source: Original deterministic Palisade operating framework based on the [RFC 9990 aggregate-report model](https://www.rfc-editor.org/rfc/rfc9990.html). It is a decision flow, not evidence that a receiver will take a specific action.* ## Investigate this with your coding agent When the SLA record already points to a client-approved, non-production runbook repository, an agent can check whether the template preserves the same fields for every tenant. Provide redacted examples only. ```agent Problem: Review a non-production managed-DMARC SLA template for missing ownership, exception, and approval fields. Evidence: A redacted SLA record, a redacted exception register, and the current template path. Repository scope: The client-approved non-production runbook or policy-template repository only. Constraints: Inspect before editing. Do not apply changes until I approve the proposed diff. Do not access credentials, client data, production DNS, or another tenant's files. Requested output: Identify missing fields, propose the smallest template diff, explain affected workflow steps, and include rollback instructions. Verification: Run the repository's template tests or render a redacted fixture and compare required fields. Stop if: Client approval, credentials, unredacted data, cross-tenant access, or a production mutation is required. ``` ## Exceptions and escalation An exception should name the affected domain or sender, the missing evidence or accepted risk, the client approver, the expiry, and the return path. A temporary exception is not permission to broaden SPF, DKIM, or DMARC policy. Keep the record open when the sender owner cannot explain the path, when a client has not approved a change, or when a change could affect legitimate mail. Escalate a material item when an unfamiliar source recurs, a critical sending path may be affected, or a policy decision could broaden the impact of a failure. The escalation package should contain the report period, observed identity and result, prior changes, a recommendation, and the decision requested. The MSP can coordinate that package; it cannot determine sender authorization or make the external change without the delegated owner. ## Reporting and success measures Report service performance as operational evidence: covered domains with a named owner, items waiting for client input, open exceptions with a future date, and approved changes that received a later evidence check. Do not use a portfolio-wide “DMARC success” score that hides unresolved domains or implies a delivery guarantee. For commercial packaging, keep the SLA's commitments separate from price and tier design. The [MSP DMARC management pricing guide](/learning/how-should-msps-price-dmarc-management-services) covers that commercial decision. A recurring review process can then connect each client record to the right service tier without changing its approval boundary. ## Turn the SLA record into recurring evidence work If your team has repeated sender and alignment items across clients, Palisade's [DMARC Agent guidance](https://docs.palisade.email/guides/fixing-authentication-issues/) describes turning aggregate-report findings into source-specific authentication tickets with recommended actions. It does not authorize senders, change client DNS, approve DMARC policy, or guarantee delivery. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=msp_operations&utm_content=managed-dmarc-service-sla) ## Sources and further reading - [RFC 9989: Domain-based Message Authentication, Reporting, and Conformance](https://www.rfc-editor.org/rfc/rfc9989.html) - [RFC 9990: DMARC Aggregate Reporting](https://www.rfc-editor.org/rfc/rfc9990.html) - [Palisade documentation: fixing authentication issues](https://docs.palisade.email/guides/fixing-authentication-issues/) ## Frequently asked questions ### What should a managed DMARC service SLA include? A managed DMARC service SLA should include covered domains, evidence inputs, the MSP commitment, client and change-owner responsibilities, escalation triggers, exclusions, and review cadence. It should also identify the record used to preserve decisions and exceptions for each client. ### Does an SLA let an MSP change a client's DMARC policy? No. An SLA can define how the MSP presents evidence and coordinates an approved change. The client and delegated DNS or sender owner must still authorize and apply changes to their environment. ### Can aggregate reports prove a sender is authorized? No. Aggregate reports provide receiver-observed authentication and policy data. They can identify a source for investigation, but client business context and sender-owner confirmation are still needed to authorize that source. ### Should every client have the same response target? Not necessarily. A shared record structure makes work comparable, but response commitments should reflect the client's domains, contacts, service scope, and risk acceptance. Do not turn a framework example into an implied contractual target. ### What belongs in a managed DMARC exception? An exception should identify the affected domain or sender, the evidence gap or accepted risk, the client approver, an expiry, and the next review. That makes a deferred decision visible rather than letting it disappear from the operating record. --- # Mimecast competitors: who else serves the same job Canonical: https://www.palisade.email/learning/mimecast-competitors > Mimecast competitors grouped by deployment model: MX path gateways, API connected filters, native Microsoft and Google controls, and the DMARC layer. Mimecast's closest competitors sort into four groups by how they attach to mail. Proofpoint and Cloudflare Email Security can sit inline in the MX path, the way Mimecast's gateway does. Barracuda and Abnormal connect over an API and leave MX records alone. Microsoft Defender for Office 365 and Google Workspace controls ship with the mailbox you already pay for. DMARC platforms work on the authentication layer and replace none of the above. Which group you shop in depends on your goal: replacing Mimecast outright, or filling a gap next to it. ## Quick takeaways - Deployment model is the first split. A gateway takes the MX record, an API connector does not, and several vendors sell both. - Proofpoint, Barracuda, Abnormal and Cloudflare all document products that do the filtering job Mimecast's gateway does. - Microsoft 365 and Google Workspace already filter mail for their own mailboxes, so part of the work comes with the seat. - Microsoft is the only vendor here publishing a per user list price for email security. - Mimecast also sells archive, awareness training and governance products, so a filter alone is not a full swap. - DMARC sits outside the core filtering package at every vendor here, Mimecast included. ## Who this comparison is for This is for an IT team or an MSP that runs Mimecast, or has it on a shortlist, and wants the real field before a renewal conversation. It also helps when the trigger is narrower than the contract: a DMARC requirement, an archive requirement, or a mail flow change. ![Who competes with Mimecast, grouped by how they deploy](/images/editorial/mimecast-competitors/mimecast-competitors-field.webp "1200x488") *Source: Palisade.* Cheapest is not a question published material can answer, because Mimecast shows no list price. What can be answered is which products do the same job in the same place in the mail path. The [Palisade comparison hub](/compare) collects the vendor pages, and the guide to [email security software](/learning/email-security-software) covers the category types in depth. ## How the options were evaluated Every claim below was read off the vendor's own product, plans or documentation pages on August 12, 2026. Reseller listings and review sites were excluded, because they commit the vendor to nothing. - Where the product attaches: the MX path, an API, or the mail platform itself. - What the vendor publishes commercially: list prices, tier names, or sales contact language. - Whether DMARC is inside the core package or sold beside it. - Whether the catalogue covers archiving, awareness training and compliance review. An absence of published documentation is an open question, not a missing feature. ![Mimecast competitor deployment models and evaluation criteria](/images/editorial/mimecast-competitors/mimecast-competitors-deployment-models.webp "1200x829") *Source: Palisade.* *Source: Palisade.* ## Gateways that sit in the MX path A gateway takes delivery first, so [the MX records a domain publishes](/tools/mx) name whichever product holds that position. Mimecast describes its own [MX based deployment](https://www.mimecast.com/products/email-security/integrated-cloud-email-security/) as perimeter protection that blocks mail in line, with all incoming mail routing through its secure gateway before the mailbox sees it. That is the shape a direct replacement has to match, and why a swap is a cutover project rather than a settings change. Proofpoint sells the same shape. Its [Core Email Protection page](https://www.proofpoint.com/us/products/threat-defense) lists flexible deployment via API or secure email gateway, so one product covers both paths. Its [buying page](https://www.proofpoint.com/us/products/how-to-buy/collaboration-security) names four packages, Core, Tier 2, Tier 3 and Prime, with no figure against any. It does say budgetary pricing follows user licence count and contract term, with exceptions for consumption, the most specific cost driver statement in this group. Cloudflare Email Security can also take the inline position. Its [documentation](https://developers.cloudflare.com/cloudflare-one/email-security/) lists pre-delivery deployment through MX or inline placement as one of three options. No price appears. ## Platforms that connect by API Barracuda states that [Email Protection](https://www.barracuda.com/products/email-protection) connects to Microsoft 365 or Google Workspace with no mail exchange changes, and calls the result operational in minutes rather than weeks. Its coverage list includes phishing, malware, spam, account takeover, domain fraud with DMARC, and post-delivery weaponization. Its [plans page](https://www.barracuda.com/products/email-protection/plans) names Advanced, Premium and Premium Plus, with no price figure. Abnormal takes the same position. Its [inbound email security page](https://abnormal.ai/products/inbound-email-security) says the product deploys in 60 seconds via API with no MX changes, and describes its target as attacks with no payload, no prior signature and nothing for a rule to flag. The same page states that Abnormal with Microsoft or Google replaces a secure email gateway, which is positioning rather than a tested result. Cloudflare belongs here too, since it also documents an API mode and a post-delivery mode using BCC and journaling. And Mimecast documents an API path of its own. Deployment model is a configuration choice as often as a vendor choice, so ruling a vendor out on that basis will mislead you. ## Controls you may already own Microsoft's [Exchange Online Protection documentation](https://learn.microsoft.com/en-us/defender-office-365/eop-about) states that anti-malware, anti-spam and anti-phishing filtering are included in all organizations with cloud mailboxes and on by default. The wording is blunt: you cannot turn them off, though preset or custom threat policies can override them. That baseline runs behind whatever gateway you route through. The paid step up carries the only published per seat figure in this article. Microsoft lists Defender for Office 365 [Plan 1 at $2.00 and Plan 2 at $5.00 per user per month](https://www.microsoft.com/en-us/security/business/siem-and-xdr/microsoft-defender-office-365), both paid yearly. Its [plan documentation](https://learn.microsoft.com/en-us/defender-office-365/mdo-about) splits them: Plan 1 covers prevention and detection with Safe Attachments, Safe Links and impersonation protection, and Plan 2 adds phishing simulations, post-breach investigation, hunting and automation. Google Workspace bundles filtering into the seat as well. Every published tier on its [pricing page](https://workspace.google.com/pricing) lists phishing and spam protection that Google states blocks more than 99.9% of attacks, while data loss prevention, S/MIME and context aware access sit under Enterprise only. If Mimecast was held for baseline filtering, some of it is already paid for. ## The layer that none of these replace DMARC, SPF and DKIM decide whether a receiver believes mail claiming to come from your domain. That work points outward at your own senders, and an inbound filter does not do it, whichever way it is deployed. Mimecast's product structure agrees. [DMARC Analyzer](https://www.mimecast.com/products/dmarc-analyzer/) is a separately named product listed apart from Advanced Email Security, documenting aggregate, forensic and TLS reporting, SPF delegation, a record generator, record checkers and a recommendation engine. What the page does not claim is that Mimecast publishes or changes your DNS records for you. The record edits stay with your team. The pattern repeats. Proofpoint puts this work in Email Fraud Defense and places hosted DMARC, DKIM and SPF in Prime, the top of its four packages. Barracuda lists DMARC reporting on its tiers. Microsoft tells administrators to publish those records themselves. If DMARC is the reason Mimecast is under review, the [Mimecast DMARC alternative](/mimecast-dmarc-alternative) page covers that narrower question. ## What Mimecast sells beyond filtering Mimecast's [product index](https://www.mimecast.com/products/) lists Advanced Email Security next to Engage Security Awareness, Incydr Data Protection, the Aware Governance and Compliance Suite, DMARC Analyzer and Email Archive. A team that bought several of those is not made whole by a filter, however well it performs. Part of the field covers that ground and part does not. Proofpoint's [product index](https://www.proofpoint.com/us/products) lists Archive, Capture, Discover, Supervision and Track on the compliance side, plus ZenGuide for risk based learning. Barracuda puts cloud archiving and security awareness training in Premium Plus. Microsoft's Defender Plan 2 includes phishing simulations, and Google reserves Vault retention and eDiscovery for higher tiers. Abnormal lists AI Phishing Coach and AI Governance. Cloudflare documents filtering, and neither archiving nor training. ## Where Palisade fits Palisade is DMARC automation. It is not a gateway, it does not sit in the MX path, and it does not filter, sandbox or quarantine inbound mail, so it replaces none of the products above. Its [documentation](https://docs.palisade.email/) covers DMARC, SPF, DKIM, BIMI and MTA-STS, hosted records, aggregate report processing, sender classification and PSA ticketing. The agent investigates every sender, drafts every fix and proposes each policy step, and you approve before anything ships. That is the narrow case: you keep whichever filter you land on, and the authentication work stops living in a spreadsheet. For a public read on a domain first, the [Email Security Score](/tools/email-security-score) tool reports the DMARC, SPF, DKIM, MX and MTA-STS state visible in DNS. ## How to choose Start from what triggered the review. If it was cost, every vendor here except Microsoft routes you to a salesperson, so the comparison you can run is between quotes. If it was a mail flow constraint, the API vendors and the API paths inside Mimecast and Proofpoint remove the cutover. If it was overlap, check what Microsoft 365 or Google Workspace already runs by default. If it was DMARC, buy for the authentication layer and leave the filter alone. Then put the same questions to every vendor on the shortlist: - Which named package and modules are in this quote, and what is excluded? - Is DMARC in the core package, a separate product, or an add-on fee? - Who publishes and changes the SPF, DKIM and DMARC records, us or you? - Which deployment path carries production mail, and what is validated before cutover? - Which archive, training and compliance modules replace the ones we use today? - What drives renewal cost: seats, term, consumption, or repackaging? ## Sources and further reading - [Mimecast plans](https://www.mimecast.com/products/mimecast-plans/) - [Mimecast deployment options](https://www.mimecast.com/products/email-security/integrated-cloud-email-security/) - [Mimecast DMARC Analyzer](https://www.mimecast.com/products/dmarc-analyzer/) - [Mimecast product index](https://www.mimecast.com/products/) - [Proofpoint buying options](https://www.proofpoint.com/us/products/how-to-buy/collaboration-security) - [Proofpoint Core Email Protection](https://www.proofpoint.com/us/products/threat-defense) - [Barracuda Email Protection plans](https://www.barracuda.com/products/email-protection/plans) - [Abnormal inbound email security](https://abnormal.ai/products/inbound-email-security) - [Microsoft Defender for Office 365 pricing](https://www.microsoft.com/en-us/security/business/siem-and-xdr/microsoft-defender-office-365) - [Cloudflare Email Security documentation](https://developers.cloudflare.com/cloudflare-one/email-security/) ## Frequently asked questions ### Who are Mimecast's main competitors? Proofpoint, Barracuda, Abnormal and Cloudflare Email Security all sell products that do the filtering job Mimecast's gateway does. Microsoft Defender for Office 365 and Google Workspace compete from a different angle, because their filtering attaches to the mailbox platform you already pay for. ### Is there a cheaper alternative to Mimecast? Not on published evidence. Mimecast shows no list price on any plan, and Proofpoint's enterprise packages, Barracuda's tiers, Abnormal and Cloudflare publish none either. Microsoft is the exception, listing Defender for Office 365 Plan 1 at $2.00 and Plan 2 at $5.00 per user per month paid yearly. ### Can Microsoft 365 replace Mimecast? Only for part of the job. Microsoft documents anti-malware, anti-spam and anti-phishing filtering as on by default for every organization with cloud mailboxes, and Defender adds sandboxing, impersonation protection and, at Plan 2, investigation and simulation. It does not replace an archive, a compliance workflow, or DMARC records. ### Do I have to change MX records to switch off Mimecast? Not necessarily. Barracuda, Abnormal and Cloudflare document API or post-delivery deployments that need no MX change, and Mimecast and Proofpoint each document an API path beside the gateway path. The cutover applies only when the replacement runs inline, so confirm which path a quote assumes. ### Does replacing Mimecast cover DMARC? No. Mimecast sells DMARC Analyzer as its own product, separate from Advanced Email Security, and its competitors follow the same split. Proofpoint places hosted DMARC, DKIM and SPF in its top package through Email Fraud Defense, and Microsoft directs administrators to publish those records themselves. --- # Mimecast pricing: what is published and what drives cost Canonical: https://www.palisade.email/learning/mimecast-pricing > Mimecast pricing is quote-only. See what Mimecast publishes, the modules and deployment choices that affect cost, and questions to ask sales. Mimecast pricing is not published as a list price. Mimecast names its plans and products, but its current plans page uses "Contact for pricing," "Custom pricing available," and "Custom options available" instead of dollar amounts. Choose Mimecast if its email security, insider-risk, or security-behaviour products match the scope you need. Choose a focused DMARC platform if the purchase is specifically about operating DMARC across domains. ## Quick takeaways - Mimecast publishes plan names and feature packaging, but no public dollar price, currency, per-user rate, or price range. - A reseller, marketplace, or review-site estimate is not Mimecast's published list price. - The quote can vary with the product family, feature tier, deployment model, and paid services selected. - DMARC Analyzer is a separate Mimecast product with its own trial call to action and no published price. - Mimecast's older service matrix identifies DMARC visibility and reporting as a paid module outside one plan, but its tier names predate the August 2025 plan transition. - A public email-security scan can establish published DNS controls, but it cannot establish the price, production mail flow, or receiver decisions behind a Mimecast quote. ## Who this comparison is for This comparison is for an IT buyer, security owner, or MSP who needs to budget for Mimecast and has found plan names but no public price card. It also helps teams decide whether they are evaluating a secure email gateway, an API-connected email-security deployment, DMARC reporting, or a separate operational need. Mimecast is broader than DMARC. Its MX-based email-security product scans incoming, outbound, and internal mail, including attachments and URLs. Its integrated cloud email-security product supports both MX-based and API-based deployment. A DMARC purchase has a different job: identify the services sending for a domain, assess authentication and alignment, then move safely toward enforcement. For broader managed DMARC product evaluation, use Palisade's [DMARC comparison hub](/compare). If the question is specifically whether a DMARC-focused workflow is a better fit than Mimecast's DMARC product, see the [Mimecast DMARC alternative comparison](/mimecast-dmarc-alternative). ## How the options were evaluated The criteria below were checked against Mimecast and Palisade first-party pages on August 12, 2026: - Published price: whether the vendor provides a dollar amount, currency, rate, or range that a buyer can use without requesting a quote. - Scope: whether the documented product is email security, insider-risk management, security behaviour management, or DMARC operations. - Quantity and service levers: documented limits, included capabilities, migration costs, implementation services, or modules that can affect the final commercial scope. - Deployment: whether the product uses MX routing, an API connection, or another documented deployment choice. - Boundary: what the documented offering does not establish or perform. A documented feature counts as published evidence. An absent price is recorded as absent, not estimated. A capability that Mimecast does not describe remains an open question for the sales process. ![Decision flow for assessing a Mimecast quote by product scope, deployment, modules, and paid services](/images/editorial/mimecast-pricing/mimecast-pricing-quote-decision.webp "1200x829") *Source: Palisade.* ## Mimecast plans and quote-based pricing Mimecast's [plans page](https://www.mimecast.com/products/mimecast-plans/) names threat-protection tiers as Critical, Advanced, and Premium. It names insider-risk-management tiers as Professional, Enterprise, and Gov, and security-behaviour-management tiers as Core and Pro. The same page does not publish a dollar price for any of them. Its price fields direct buyers to contact Mimecast or describe custom pricing or options. - Best fit: Teams buying a broader email-security, insider-risk, or security-behaviour package and prepared to scope it with Mimecast sales. - Relevant evidence: [Mimecast plans](https://www.mimecast.com/products/mimecast-plans/) describes Critical as the broad email-security tier, with features such as AI-powered BEC protection, URL analysis, attachment sandboxing, malware scanning, spam filtering, continuity, and collaboration-tool protection. Advanced adds data protection, while Premium extends across collaboration tools, checked August 12, 2026. - Tradeoff: A buyer cannot calculate a vendor-supported annual or per-user cost from the public plans page. Any public figure from a reseller or review site is not a Mimecast-published list price. Documented quantities and access levels can shape the quote. Mimecast states that insider-risk Professional includes 30 days of historical activity, while Enterprise includes 90 days. Professional includes one SaaS or cloud-app exfiltration detector, while full API access is listed for Enterprise. Those differences are commercial scoping questions, even though the public page does not attach a price to them. Plan timing also matters. Mimecast states that, from August 15, 2025, new customers must purchase the new email-security plans, while existing purchases remain online, uninterrupted, and unchanged. Mimecast also states that migration to the new plans can involve an additional cost and that standard price-increase terms apply. Ask sales which plan structure applies to the account, whether migration is included, and which terms govern renewal. The public route to a number is Mimecast's [quote-request page](https://www.mimecast.com/get-a-quote/), which offers a customised plan and quote without publishing a price or range. ## Mimecast deployment and DMARC costs Mimecast's [integrated cloud email security page](https://www.mimecast.com/products/email-security/integrated-cloud-email-security/) documents two deployment models. MX-based deployment routes incoming mail through Mimecast's gateway. API-based deployment connects without MX-record changes and is described as avoiding mail-flow disruption. The correct model depends on the email environment and desired controls, so it belongs in the quote request. - Best fit: Buyers who need Mimecast's documented gateway or integrated cloud email-security capabilities as part of the commercial scope. - Relevant evidence: [Mimecast Email Security MX Based Protection](https://www.mimecast.com/products/email-security/secure-email-gateway/) is documented as a cloud-native secure email gateway that scans inbound, outbound, and internal mail, including attachments and URLs, checked August 12, 2026. - Tradeoff: A DMARC requirement should be scoped separately. A gateway purchase does not state a public price for DMARC reporting or show that every DMARC-related service is included. Mimecast [DMARC Analyzer](https://www.mimecast.com/products/dmarc-analyzer/) is a named product for visibility into senders using a domain, aggregate, forensic, and TLS reports, plus self-service tools, summaries, filters, and a recommendation engine. Its page offers a free 14-day DMARC trial, but no price. Mimecast's [service matrix version 4.1](https://assets.mimecast.com/api/public/content/0e60226dd6e641b5937ec5440ec56527?v=a6cf7965&download=true), dated July 2020, identifies DMARC visibility and reporting as standard in one plan and available for an additional fee in four others. Its plan names predate the 2025 transition, so the useful current conclusion is limited: Mimecast has published DMARC as separately chargeable packaging, not as a universally included gateway feature. The same matrix lists real-time domain monitoring, unlimited monthly DMARC-compliant email volume, subdomain detection, RUA and encrypted RUF overviews, setup wizards, SPF delegation, record tools, and a DNS timeline within DMARC Analyzer. It marks managed deployment help and onboarding implementation as additional-fee services. > Do not assume that a generated DMARC, SPF, or DKIM record is deployed. Mimecast documents analysis, generation, and recommendations for DMARC Analyzer. The domain owner must still control and validate the DNS change. ## Palisade for DMARC automation Palisade is a narrower fit for teams buying DMARC operations rather than inbound email filtering. It is agentic DMARC software for IT teams and MSPs that analyzes DMARC aggregate-report data, identifies sending sources and authentication or alignment issues, creates prioritized remediation tickets, and proposes the next policy step for human review. - Best fit: Teams that want an AI agent to do the DMARC work across one domain or many domains. - Relevant evidence: [Palisade pricing](https://www.palisade.email/pricing) publishes a free plan at $0 for one domain and up to 1,000 emails a month, IT-team plans from $19 a month based on monthly email volume, MSP pricing per client domain with a free NFR domain, and enterprise custom terms, checked August 12, 2026. - Tradeoff: Palisade is not a secure email gateway and does not filter inbound mail. It also does not autonomously change a DMARC policy. A human reviews the evidence and applies the DNS change. ![Scope comparison between Mimecast email security and Palisade DMARC automation](/images/editorial/mimecast-pricing/mimecast-pricing-scope-comparison.webp "1200x466") *Source: Palisade.* Palisade's published pricing provides a starting point that Mimecast's public plans page does not. That does not make it a substitute for Mimecast filtering plans. The products solve overlapping DMARC visibility needs, but different email-security jobs. ## How to choose Start by writing down the operational problem, then request a quote only after the required product scope is clear. - Choose Mimecast when the purchase includes documented secure email gateway controls, API-connected cloud email security, insider-risk management, security-behaviour management, or a combined security package. - Choose Palisade when the requirement is recurring DMARC analysis, source identification, remediation prioritisation, and human-reviewed progression toward DMARC enforcement. - Ask Mimecast whether DMARC Analyzer is included, separately priced, or subject to an additional service fee for the exact package. - Ask which deployment model is proposed, what migration costs apply, and whether onboarding or managed deployment assistance is separately charged. - Record every quantity limit, retained-history period, API entitlement, and collaboration-tool scope in the quote. ```yaml option: Mimecast checked_on: 2026-08-12 best_fit: "Broad email security and separately scoped DMARC operations" verified_evidence: - "Public plans have no published dollar price or range" - "MX-based and API-based deployment are documented" - "DMARC Analyzer is a named product with no published price" open_question: "Quoted price, minimum commitment, included modules, and implementation fees" option: Palisade checked_on: 2026-08-12 best_fit: "DMARC automation for IT teams and MSPs" verified_evidence: - "Published free, IT team, MSP, and enterprise pricing paths" - "DMARC aggregate-report analysis and prioritised remediation workflow" - "Human review before policy changes" open_question: "Exact monthly-volume or multi-domain scope for the account" ``` ## Check the domain controls behind the quote Before treating a DMARC module as the answer, run the domain through Palisade's [Email Security Score](/tools/email-security-score). It checks publicly resolvable email-security controls, which helps identify whether DMARC, SPF, DKIM, BIMI, MX, MTA-STS, or TLS-RPT has an obvious public DNS gap before you scope a remediation workflow. A public scan does not prove which production senders fail alignment, confirm Mimecast packaging, monitor later DNS changes, or guarantee inbox placement. Those questions require message evidence, vendor confirmation, and DMARC reporting over time. ## Sources and further reading - [Mimecast plans and product tiers](https://www.mimecast.com/products/mimecast-plans/) - [Mimecast quote request](https://www.mimecast.com/get-a-quote/) - [Mimecast integrated cloud email security deployment options](https://www.mimecast.com/products/email-security/integrated-cloud-email-security/) - [Mimecast DMARC Analyzer](https://www.mimecast.com/products/dmarc-analyzer/) - [Mimecast service matrix version 4.1](https://assets.mimecast.com/api/public/content/0e60226dd6e641b5937ec5440ec56527?v=a6cf7965&download=true) - [Palisade pricing](https://www.palisade.email/pricing) ## Frequently asked questions ### Does Mimecast publish its pricing? No. Mimecast's current plans page publishes tier names and feature descriptions, but it does not publish dollar amounts, currencies, per-user rates, or price ranges. The public route to a commercial number is a customised quote request. ### What affects a Mimecast quote? Mimecast's published materials indicate that product family, tier, deployment model, included capabilities, retention period, API access, DMARC packaging, and paid implementation or managed services can affect scope. The vendor does not publish a formula that converts those variables into a price. ### Is Mimecast DMARC Analyzer included with email security? Not universally. Mimecast documents DMARC Analyzer as a separate product. Its July 2020 service matrix shows DMARC visibility and reporting as standard in one historical plan and available for an additional fee in others. Confirm current packaging in the quote because the plan names changed for new customers after August 2025. ### Does Mimecast change DNS records for DMARC? No published Mimecast page checked states that Mimecast changes customer DNS records or hosts SPF, DKIM, or DMARC records. Mimecast documents analysis, record-generation tools, and recommendations. The customer must apply and validate DNS changes. ### Is Palisade an alternative to Mimecast email filtering? No. Palisade is a DMARC automation platform, while Mimecast's email-security products include gateway and cloud email-security capabilities. Palisade can fit a DMARC operating need, but it does not filter inbound mail or replace a secure email gateway. --- # Mimecast vs Barracuda: how the two compare Canonical: https://www.palisade.email/learning/mimecast-vs-barracuda > Mimecast vs Barracuda compares documented email-security scope, deployment choices, plan disclosures, and fit for IT teams, security buyers, and MSPs. Choose Mimecast if your evaluation starts with its documented support for Microsoft 365, Google Workspace, and on-premise email environments. Choose Barracuda if you need to evaluate its published Email Protection plan structure and deployment choices, including API, inline, and MX-record approaches. Neither product is universally better. The useful decision comes from matching the product scope, deployment path, operating model, and commercial details your organization can verify. ## Quick takeaways - Mimecast and Barracuda both publish email-security products, but their public product pages organize the offer differently. - Mimecast's Advanced Email Security page names Microsoft 365, Google Workspace, and on-premise email as supported environments. - Barracuda publishes Advanced, Premium, and Premium Plus Email Protection plans with documented capability differences. - Barracuda documents API, inline, and traditional MX-record deployment options for its Email Protection plans. - A vendor feature page does not prove how either product will behave in your tenant, mail flow, or incident process. - DMARC operations deserve their own evaluation because threat protection and DMARC enforcement are different operating jobs. ## Who this comparison is for This comparison is for an IT or security team, or an MSP evaluating a commercial email-security platform for an existing mail environment. It is also useful when the buyer needs to separate several questions that are often bundled into one request: - Which mail environments must the product support? - Does the deployment model fit the current mail flow and change-control process? - Which capabilities are included in the plan under review? - Does the buyer need email threat protection, DMARC operations, backup, archiving, or a combination? - Which details still require a vendor quote, demonstration, or tenant-specific validation? The broader [Palisade comparison hub](/compare) covers related vendor decisions. This article is narrower. It compares what Mimecast and Barracuda publicly document about their email-security offers, then identifies the questions that documentation alone cannot settle. ## How the options were evaluated The criteria below were checked against current first-party Mimecast and Barracuda product and pricing pages on August 12, 2026. A capability is treated as documented only when the vendor page describes it. Missing public detail is recorded as an open question, not as evidence that the capability is absent. - Product scope: What the vendor's cited product page says the product protects or includes. - Mail-environment fit: Which email environments the cited page identifies. - Deployment: Which connection or mail-routing approaches the vendor documents. - Packaging: Whether the vendor publishes named plans and which capabilities its plan page assigns to them. - Commercial clarity: Whether the public pricing page provides an evaluable price or routes the buyer to a quote. - Operating boundary: What still needs validation in the buyer's own tenant, delivered messages, and operational workflow. This method avoids feature-count scoring. Two products can both describe protection against similar threats while requiring different deployment changes, plan selections, or administrative processes. ![Mimecast and Barracuda on their own documented terms](/images/editorial/mimecast-vs-barracuda/mimecast-vs-barracuda-decision-flow.webp "1200x738") *Source: Palisade.* ## Mimecast - Best fit: Teams that need to evaluate an email-security product against Microsoft 365, Google Workspace, or on-premise email. Mimecast's [Advanced Email Security product page](https://www.mimecast.com/products/email-security/) explicitly names those environments. - Relevant evidence: The same Mimecast page describes Advanced Email Security as protection against dangerous email-borne attacks and states that it scans email, attachments, and URLs for threats including impersonation fraud, ransomware, phishing, and spear-phishing. It also presents integrations and deployment options as product-page topics, checked August 12, 2026. - Tradeoff: The cited public product page is an overview, not a buyer-specific implementation plan. Confirm the deployment design, exact included capabilities, licensing basis, support terms, and commercial terms with Mimecast before selecting it. Mimecast may fit a buyer whose initial requirement is environment coverage across the email systems named on the vendor's page. That is an editorial fit inference based on the documented scope, not a claim about ease of deployment or total cost. A buyer assessing DMARC separately should use the dedicated [Mimecast DMARC alternative evaluation](/mimecast-dmarc-alternative). Email threat protection can sit beside DMARC work, but neither a product overview nor a published DNS record proves which production senders authenticate and align for a domain. ## Barracuda - Best fit: Teams that need to compare named Email Protection plans and choose among documented API, inline, or MX-record deployment approaches. Barracuda's [Email Protection plan page](https://www.barracuda.com/products/email-protection/plans) identifies Advanced, Premium, and Premium Plus plans and describes those deployment options. - Relevant evidence: Barracuda documents spam, malware, ransomware, phishing, business email compromise, link protection, attachment sandboxing, DMARC reporting and analysis, email encryption, email continuity, and data-loss prevention on its plan page, checked August 12, 2026. The same page lists Microsoft 365 backup in Premium and Premium Plus, and cloud archiving in Premium Plus. - Tradeoff: Plan names do not remove the need to verify the exact offer. Barracuda's [pricing page](https://www.barracuda.com/pricing) indicates that minimums apply and includes purchase paths that can lead to a custom quote. Check the applicable region, user count, bundle, reseller or MSP arrangement, and contract terms before treating public pricing as a final cost. Barracuda may fit a buyer whose first constraint is choosing a documented Email Protection package and deployment route. That is an editorial fit inference. It does not establish that a particular deployment can be introduced without mail-flow changes or that every listed capability is appropriate for the buyer's environment. For a DMARC-specific operating decision, compare the evidence and workflow in the [Barracuda DMARC alternative evaluation](/barracuda-dmarc-alternative). A DMARC report feature is not the same thing as an operating process for identifying all senders, fixing alignment failures, and deciding when a domain is ready for a policy change. ## How to choose Start with the non-negotiable constraint. If the mail environment includes an on-premise system alongside Microsoft 365 or Google Workspace, Mimecast's cited product page directly documents that environment scope. If the buyer needs to select among Barracuda's named Email Protection tiers or assess API, inline, and MX-record deployment options, Barracuda's cited plan page provides more public detail for that comparison. Then use this checklist: - Confirm the exact mail environment, including any hybrid or on-premise components. - Identify whether the mail-flow design permits an MX-record change, requires an API connection, or needs a different approach. - Map every required capability to a named plan or written proposal. - Ask each vendor to document excluded capabilities, regional availability, support coverage, implementation responsibilities, and renewal terms. - Test the proposed deployment with a controlled message path before changing production mail flow. - Keep DMARC sender inventory, alignment evidence, and policy rollout as a separate workstream. Use the same evidence record for both options: ```yaml option: Mimecast checked_on: 2026-08-12 best_fit: "Evaluation involving Microsoft 365, Google Workspace, or on-premise email" verified_evidence: - "Advanced Email Security page names those email environments" - "Product page describes scanning email, attachments, and URLs" open_question: - "Exact deployment design, packaging, pricing, and support terms for this tenant" --- option: Barracuda checked_on: 2026-08-12 best_fit: "Evaluation requiring named Email Protection plans and documented deployment choices" verified_evidence: - "Plan page lists Advanced, Premium, and Premium Plus" - "Plan page documents API, inline, and traditional MX-record deployment options" open_question: - "Applicable price, minimums, implementation scope, and contract terms for this buyer" ``` > Do not change MX records or route production mail from a feature comparison alone. Validate the authoritative DNS change, the vendor's configuration status, a real message from the production sending path, and DMARC aggregate-report evidence after messages accumulate. ## Check the domain controls around the platform decision Before choosing an email-security platform, run your sending domain through the [Email Security Score](/tools/email-security-score) to inspect public DMARC, SPF, DKIM, BIMI, MX, MTA-STS, and TLS-RPT evidence. This gives the buying team a documented baseline for the domain controls that sit around the platform decision. A public DNS score cannot evaluate Mimecast or Barracuda, prove a production message path, reveal a mailbox provider's private filtering decision, or guarantee inbox placement. It also cannot replace tenant-specific vendor validation. ## Sources and further reading - [Mimecast Advanced Email Security](https://www.mimecast.com/products/email-security/) - [Barracuda Email Protection plans](https://www.barracuda.com/products/email-protection/plans) - [Barracuda Email Protection features](https://www.barracuda.com/products/email-protection/features) - [Barracuda pricing plans](https://www.barracuda.com/pricing) ## Frequently asked questions ### Is Mimecast better than Barracuda? No. The documented pages support different decision paths. Mimecast explicitly names Microsoft 365, Google Workspace, and on-premise email on its Advanced Email Security page. Barracuda publishes named Email Protection plans and multiple deployment options. Choose based on the environment, required plan scope, deployment constraints, and commercial terms you can verify. ### Does Barracuda Email Protection support MX-record deployment? Yes. Barracuda's Email Protection plan page states that its plans offer API, inline, or traditional MX-record deployment options. Confirm the required DNS and mail-flow changes for the selected plan before making a production change. ### Does Mimecast support Google Workspace? Yes. Mimecast's Advanced Email Security product page names Google Workspace among the email environments it secures. The public page does not establish the exact implementation design or commercial terms for an individual Google Workspace tenant. ### Can this comparison determine which product costs less? No. Barracuda publishes pricing information but also states that minimums apply and provides custom-quote paths. The cited Mimecast product overview does not provide enough public pricing detail for a like-for-like cost comparison. Request written proposals with the same user count, term, scope, and support assumptions. ### Do Mimecast or Barracuda replace DMARC enforcement work? No. Email-security controls and DMARC enforcement solve related but different problems. A DMARC program still needs DNS validation, delivered-message authentication evidence, aggregate-report analysis, and a controlled policy rollout. Palisade can analyze DMARC aggregate-report data, identify sources and alignment issues, create prioritized remediation tickets, and propose the next policy step for human review. --- # MSP email security stack Canonical: https://www.palisade.email/learning/msp-email-security-stack > Build an MSP email security stack with accountable layers, evidence records, exception routing, and client review measures. An MSP email security stack is an operating model for protecting each client’s sending identity, inbound mail, accounts, and recovery path with named owners and evidence. It is not a list of products. Start with a per-client baseline, connect every layer to a decision record, and route exceptions to the person who can authorize or change that tenant. This makes a shared service repeatable without treating client domains as interchangeable. ## Quick takeaways - Define the stack by security outcome, evidence record, owner, and exception path before selecting or standardizing tools. - Keep authentication, inbound defense, account protection, resilience, and service operations as separate layers. - Use a client-specific sender inventory and a delivered-message check before altering DNS or DMARC policy. - Keep authorization with the client and configuration control with the DNS or sender owner. - Treat review cadence and service thresholds as MSP operating recommendations, not mailbox-provider requirements. ## Operating context and ownership The multi-client difference is accountability. A single business can decide informally which platform sends mail. An MSP needs a record that survives technician changes, new senders, and a client acquisition. Begin with a [client email security assessment](/learning/how-do-msps-run-an-email-security-assessment-for-a-new-client), then turn its findings into the recurring service model described here. Use five layers. Authentication covers SPF, DKIM, DMARC, domain alignment, and the identities used by outbound services. Inbound defense covers the client’s chosen mail filtering and user-reporting process. Account protection covers privileged access, MFA, recovery contacts, and change approval. Resilience covers backup, continuity, and an incident contact path. Service operations connects all of these to inventory, evidence, exceptions, and client reporting. The protocol layers have real boundaries. [RFC 9989](https://www.rfc-editor.org/rfc/rfc9989.html) defines DMARC’s policy framework, with aggregate and failure reporting split into [RFC 9990](https://www.rfc-editor.org/rfc/rfc9990.html) and [RFC 9991](https://www.rfc-editor.org/rfc/rfc9991.html), while [RFC 8461](https://www.rfc-editor.org/rfc/rfc8461.html) defines MTA-STS policy discovery for SMTP transport. Neither standard assigns the client business owner, approves a DNS change, or supplies an MSP service cadence. The layer-to-owner model below is a Palisade operating recommendation. ## Evidence to collect For every client domain, retain a sender record, public DNS result, one real delivered message from each material path, named client approver, and named change owner. A [sender inventory](/learning/msp-email-sender-inventory) is where that evidence stays connected to a domain and a business purpose. For a delivered message, record the result seen by the receiving system rather than relying only on a sender-side dashboard. [RFC 8601](https://www.rfc-editor.org/rfc/rfc8601.html) defines `Authentication-Results` and cautions that its assertions depend on a trust boundary. Preserve the source of the header with the record. This is evidence for a decision, not evidence that an MSP may make a change without approval. ```yaml client: northwind.example domain: example.com layer: authentication evidence: DNS result, delivered message, aggregate report period client_approver: client-security-owner change_owner: dns-administrator exception_state: pending-sender-confirmation next_review: 2026-10-01 ``` The managed stack should have an evidence object at every layer. For example, a filter alert without an owner cannot become a client decision, and a DNS change request without a delivered-message retest cannot close an authentication issue. ![Matrix showing five MSP email-security layers with their evidence records, MSP responsibilities, and client or provider responsibilities.](/images/editorial/msp-email-security-stack/msp-email-security-stack-matrix.svg "1360x1149") *Source: Original Palisade operating framework informed by [RFC 9989](https://www.rfc-editor.org/rfc/rfc9989.html), [RFC 8461](https://www.rfc-editor.org/rfc/rfc8461.html), and [RFC 8601](https://www.rfc-editor.org/rfc/rfc8601.html). It maps accountability and does not prove a control is effective for a particular tenant.* ## How to run the workflow ### 1. Set the client boundary and baseline List domains, sending subdomains, mailboxes in scope, administrative owners, and the client’s approval path. Distinguish services the MSP operates from services the client or a third party controls. A baseline is not an authorization to standardize every tenant at once. ### 2. Map the managed email-security stack For each layer, identify one required evidence record and one primary owner. Use the [email security protocols guide](/learning/email-security-protocols) to keep protocol mechanisms separate from the operational model. Do not collapse authentication into a generic “email security” checkbox: it needs DNS, message, and report evidence that inbound filtering cannot substitute. ### 3. Validate actual sending paths Compare public records with a production message from the claimed path. Google’s current [email sender guidelines](https://support.google.com/mail/answer/81126) say bulk senders to personal Gmail accounts need SPF, DKIM, and DMARC, and require alignment for direct mail. Record this as a provider requirement only where the client’s traffic is in scope. Do not represent it as a universal approval to change every client’s policy. ### 4. Create a controlled change queue Give each change a client, domain, affected identity, evidence, approver, implementation owner, rollback condition, and retest method. Run changes per tenant and preserve the before-and-after evidence. The MSP coordinates the queue; the client approves business risk and the authorized owner applies the change. ### 5. Review exceptions before expanding coverage An unknown sender, an unapproved policy change, or a suspected compromise needs a different route. Preserve evidence first, identify the owner, obtain the required approval, then make a narrow client-specific change and retest that path. This avoids turning a portfolio convenience into a cross-tenant DNS change. ## Investigate this with your coding agent Use this handoff when the service record already identifies a configuration repository or runbook that owns a proposed client-specific change. Supply redacted evidence only, and keep client authorization outside the prompt. ```agent Problem: A client-specific email-security exception has evidence but no verified configuration change proposal. Evidence: Redacted domain, sending identity, DNS result, Authentication-Results outcome, approved change ticket, and expected owner. Repository scope: The client-scoped infrastructure-as-code directory or email-security runbook only. Constraints: Inspect before editing. Do not apply changes until I approve the proposed diff. Do not access credentials, production systems, other client directories, or make DNS, sender, policy, or tenant changes. Requested output: Identify the relevant files, explain the smallest proposed change, list rollback steps and unknowns, and provide a minimal diff for review. Verification: Run the repository's existing validation, then require public DNS and a same-path delivered-message retest after human approval. Stop if: Credentials, unredacted customer data, production mutation, missing client approval, or ambiguous ownership is required. ``` ## Exceptions and escalation Route an unknown sender to the client service owner and sender owner. Route an unapproved policy change to the DNS change owner and client approver. Route suspected credential compromise or account takeover through the client’s incident process before routine remediation. In each case, record who received the escalation, the evidence retained, the containment decision, and the next review time. ![Exception-routing flow from evidence collection through approval, one-tenant change, retest, and outcome record.](/images/editorial/msp-email-security-stack/msp-email-security-stack-exception-flow.svg "1200x926") *Source: Original Palisade operating framework informed by [CISA phishing guidance](https://www.cisa.gov/sites/default/files/2025-03/Phishing%20Guidance%20-%20Stopping%20the%20Attack%20Cycle%20at%20Phase%20One%20508.pdf). It is an approval-gated routing model and never authorizes a production DNS or tenant change.* Use an exception register rather than a generic urgent flag. The register should show the client, domain, affected layer, observed evidence, business impact known so far, assigned owner, decision deadline, approval state, and retest result. It lets a QBR distinguish an unresolved decision from a completed control change. ## Reporting and success measures Report by client first, then roll up only measures that retain their meaning: domains with verified authentication paths, open exceptions with owners, overdue reviews, privileged account controls awaiting verification, and changes with a passed same-path retest. Avoid a single portfolio score that lets one unresolved client disappear behind a broad average. For a domain-level starting posture, use [Email Security Score](/tools/email-security-score) after the evidence checklist. It can help inspect several visible controls on one client domain before the next review. It does not map every sender, configure controls, validate every client tenant, or prove why an individual message was delivered or blocked. For recurring client conversations, tie the measures to decisions: approve a planned remediation, retain an exception, assign an owner, or close a retested change. The [DMARC QBR reporting guide](/learning/dmarc-qbr-reporting) can help structure the authentication evidence portion of that review. Stronger authentication supports safer sender identification and better deliverability conditions, but it does not guarantee inbox placement or receiver behavior. Palisade's [DMARC Agent guidance](https://docs.palisade.email/guides/fixing-authentication-issues/) describes how incoming DMARC reports can become issue tickets with affected sources and recommended next actions for human review. It does not authorize senders, change external DNS, make client risk decisions, or guarantee delivery. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=msp_operations&utm_content=msp-email-security-stack) when the recurring bottleneck is reviewing report evidence and assigning client-specific remediation. ## Sources and further reading - [RFC 9989: Domain-based Message Authentication, Reporting, and Conformance (DMARC)](https://www.rfc-editor.org/rfc/rfc9989.html) - [RFC 8461: SMTP MTA Strict Transport Security](https://www.rfc-editor.org/rfc/rfc8461.html) - [RFC 8601: Authentication-Results header field](https://www.rfc-editor.org/rfc/rfc8601.html) - [Google email sender guidelines](https://support.google.com/mail/answer/81126) - [CISA phishing guidance](https://www.cisa.gov/sites/default/files/2025-03/Phishing%20Guidance%20-%20Stopping%20the%20Attack%20Cycle%20at%20Phase%20One%20508.pdf) ## Frequently asked questions ### Is an MSP email security stack a product list? No. A usable stack names the security layers, evidence records, owners, approval path, and exception handling for each client. Products may support those layers, but a product list alone does not tell a technician who may approve a change or how to verify its result. ### Should every client use the same email-security settings? Not necessarily. Standardize the operating record and review process first. Client domains, senders, mailboxes, risk tolerance, contracts, and administrative ownership can differ, so a configuration change must remain scoped to the approved tenant and supported by its evidence. ### Can a published DMARC record prove that all senders are secure? No. A published record shows a policy and reporting destination, not every active sender, its business authorization, or its delivered-message outcome. Pair DNS with sender inventory, client confirmation, and production-message evidence before changing policy. ### Who should approve a DNS or policy change? Only the client’s authorized approver and the designated change owner should approve and apply it under the client’s process. The MSP can prepare evidence, propose a scoped change, and coordinate retesting, but should not treat portfolio management as delegated authority. ### What should an MSP show in a QBR? Show client-specific decisions: verified sending paths, open exceptions, overdue ownership confirmations, planned changes, and retest outcomes. Explain what evidence supports each item and what decision the client needs to make. Avoid presenting a portfolio-wide score as proof that every client is protected. --- # Why does a Google DMARC report show DKIM fail? Canonical: https://www.palisade.email/learning/noreply-dmarc-support-google-com-dkim-fail > Interpret a Google DMARC aggregate report with DKIM fail, identify the sender, make a narrow repair, and validate the same path. A DMARC aggregate report from `noreply-dmarc-support@google.com` with `dkim=fail` is evidence about a group of messages, not proof that your Google Workspace DKIM setup is broken. First identify the reported `source_ip`, `header_from`, DKIM `domain`, and `selector`. Then decide whether the source is authorized, whether another aligned identifier passed, and whether a fresh message from that same path reproduces the failure before changing DNS or policy. ## Quick takeaways - The report sender identifies the reporting organization, while the report row identifies mail Google observed for your domain. - A `policy_evaluated/dkim` result is a DMARC alignment result; `auth_results/dkim/result` is the reported DKIM verification result. - An unknown source is an inventory or abuse investigation first, not a DKIM-record change. - A legitimate source needs a cause-specific repair: signing configuration, a missing or wrong public key, or a message changed after signing. - Do not weaken `p`, `adkim`, or `aspf` merely to make one row look better. ![Decision map for interpreting a Google DMARC aggregate-report row with DKIM fail, starting with the source IP and ending with a same-path retest.](/images/editorial/noreply-dmarc-support-google-com-dkim-fail/noreply-dmarc-support-google-com-dkim-fail-decision-map.svg "1200x1062") *Source: Original Palisade deterministic decision map based on the aggregate-report fields in [RFC 9990](https://www.rfc-editor.org/rfc/rfc9990.html).* ## What does the failure mean? Google can send aggregate DMARC feedback to the `rua` address in your DMARC record. Under [RFC 9990](https://www.rfc-editor.org/rfc/rfc9990.html), that XML report groups messages by information including the connecting `source_ip`, `header_from`, policy result, and authentication results. It is an aggregate view of the report period, so use the count and date range to scope the investigation rather than treating it as a copy of one message. The two DKIM fields answer different questions. `row/policy_evaluated/dkim` records the DKIM identifier-alignment outcome used for DMARC. `auth_results/dkim/result` records DKIM verification for the reported signing `domain` and `selector`. A row can therefore show DKIM verification failure, a valid-but-misaligned signature, or a DMARC pass through aligned SPF. Do not infer which one occurred from `dkim=fail` alone. ```xml <!-- Synthetic, redacted example. It is not a live Google report. --> <report_metadata> <email>noreply-dmarc-support@google.com</email> <date_range><begin>0</begin><end>86400</end></date_range> </report_metadata> <record> <row><source_ip>203.0.113.42</source_ip><count>7</count> <policy_evaluated><disposition>none</disposition><dkim>fail</dkim><spf>pass</spf></policy_evaluated> </row> <identifiers><header_from>example.com</header_from></identifiers> <auth_results><dkim><domain>example.com</domain><selector>mail1</selector><result>fail</result></dkim></auth_results> </record> ``` ## What usually causes it? ### The source is not in your authorized sender inventory If `source_ip` does not match an approved mail system, do not assume it is a broken legitimate sender. Preserve the row, check the source with the service owner or your mail logs, and look for repeated volume. Aggregate reports are intended to give domain owners visibility into IP addresses sending on their behalf and their authentication outcomes, as [RFC 9990](https://www.rfc-editor.org/rfc/rfc9990.html) explains. The conclusion that an unmatched IP is unauthorized is an investigation inference, not a property the report can prove by itself. ### An authorized sender is not signing with the expected key When the source is legitimate, compare the reported DKIM `domain` and `selector` with that sender's configuration. DKIM verification uses the public key retrieved from the selector record, and [RFC 6376](https://www.rfc-editor.org/rfc/rfc6376.html) defines the `d=` signing domain and `s=` selector as inputs to that lookup. A missing, retired, malformed, or wrong-key record can make the sender's signature fail. ### The message changed after it was signed If a fresh message from the same service shows a verification failure, compare the message path and any downstream processing. DKIM signs selected headers and a hash of the canonicalized body; RFC 6376 specifies that the verifier recomputes the body hash. A footer, disclaimer, link rewrite, gateway, list, or forwarder can therefore break a previously valid signature. That causal mapping is an inference you confirm with the delivered message and `Received` headers. ### The signature verifies but does not align If the message's verifier result is `dkim=pass` but the report's policy result for DKIM is `fail`, the signature may be valid without aligning to `header_from`. DMARC can still pass through aligned SPF. This is an alignment branch, not a verification repair; use the [DKIM alignment troubleshooting guide](/learning/why-does-my-dkim-signature-fail-alignment) after you confirm that distinction. ## How do I diagnose the failure? ### 1. Preserve one complete report row and its reporting period Save the compressed XML safely, then record `report_metadata/email`, the date range, `source_ip`, `count`, `header_from`, `policy_evaluated`, and every DKIM result under `auth_results`. RFC 9990 defines `source_ip` as the connecting address and `count` as the number of messages to which that policy evaluation applied. Redact report IDs and any data your incident process treats as sensitive before sharing it. ### 2. Match the source to an approved sender before editing DNS Compare the IP and `header_from` with your sending-service inventory, outbound logs, and any documented source ranges. If the source is not recognized, investigate ownership and spoofing exposure. If it is recognized, identify the system that applied the listed selector. For a broader cross-layer header method, see [email authentication failure troubleshooting](/learning/email-authentication-failure). ### 3. Separate verification from DMARC alignment Read both DKIM locations in the XML. A failed `auth_results/dkim/result` calls for message and key evidence. A passing verification result with failed `policy_evaluated/dkim` calls for alignment evidence. RFC 9990 explicitly keeps these fields separate, so a policy relaxation is not a substitute for discovering which condition the row records. ### 4. Inspect a fresh message from the same sender path Send a new test through the affected service and preserve the receiver-added `Authentication-Results`, `DKIM-Signature`, and `Received` headers. [RFC 8601](https://www.rfc-editor.org/rfc/rfc8601.html) defines `Authentication-Results` as a receiver-added field, so use it from the receiver you are investigating rather than a copied header from an untrusted hop. Capture `header.d`, `header.s`, and the verification reason if present. ## How do I fix it? ### Repair an authorized sender's selector or public key Only after the source and selector are confirmed, publish or correct the public key at the exact selector name the sender uses. A public lookup is useful for this narrow check: run the [Palisade DKIM checker](/tools/dkim) with the reported signing domain and selector. It cannot identify an IP owner, reconstruct an old report, or prove that a historical message was modified. ### Move signing after the last content-changing hop When fresh-message evidence shows post-signing modification, move DKIM signing after the footer, gateway, or rewrite that changes the message, or have the modifying system re-sign it. Do not add a body-length workaround or loosen DMARC policy as a substitute. If the verifier specifically says `body hash did not verify`, follow the focused [DKIM body-hash repair guide](/learning/dkim-fail-body-hash-did-not-verify). ### Contain an unknown source without changing the policy first For an unknown source, verify ownership and stop unauthorized use through the responsible system or incident process. Keep the current policy decision separate from this technical investigation. Changing `p`, `adkim`, or `aspf` may alter reporting or enforcement, but it does not repair a source that cannot produce an aligned authentication result. ## How do I validate the repair? Repeat the same sending path that produced the row. Confirm the fresh message has the intended `header.d` and `header.s`, the receiver's `Authentication-Results` shows the expected verification and alignment outcome, and the public selector record resolves. Then wait for a later aggregate-report period and compare the affected source's count and results. A passing public key lookup alone does not prove delivery behavior or that Google will report a particular outcome. ## Check the reported selector, then address recurring report gaps If the report names an exact DKIM domain and selector, check whether its public key is currently published before changing it. [Check a DKIM selector](/tools/dkim) The lookup cannot identify the reporting IP owner, inspect a past message, or explain a receiver's historical verification result. Keep those decisions tied to the aggregate row and a fresh same-path message. If later report windows keep identifying unknown sources or failing legitimate senders, the work becomes recurring source-specific investigation rather than another one-time selector check. Palisade's [DMARC Agent](https://docs.palisade.email/page-breakdowns/domain-overview/) analyzes DMARC aggregate-report data, identifies sending sources and authentication or alignment issues, creates prioritized remediation tickets, and detects when a domain appears ready for the next policy stage. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=dmarc_troubleshooting&utm_content=noreply-dmarc-support-google-com-dkim-fail) Palisade does not autonomously change DNS or DMARC policy, repair every sender, prove every future message will authenticate, or control a receiver's delivery decision. Your team reviews the evidence and applies changes. ## Sources and further reading - [RFC 9990: DMARC Aggregate Reporting](https://www.rfc-editor.org/rfc/rfc9990.html) - [RFC 6376: DomainKeys Identified Mail](https://www.rfc-editor.org/rfc/rfc6376.html) - [RFC 8601: Authentication-Results](https://www.rfc-editor.org/rfc/rfc8601.html) - [Palisade Docs: Domain overview](https://docs.palisade.email/page-breakdowns/domain-overview/) ## Frequently asked questions ### Does a Google DMARC report prove that Google sent my mail? No. It identifies Google as the report generator, while the row's `source_ip` identifies a connecting system Google observed. Match that source with your sender inventory before treating it as Google Workspace mail or changing its DKIM record. ### Can DKIM fail while DMARC passes? Yes. DMARC can pass when aligned SPF passes even if the reported DKIM verification or DKIM alignment result fails. Inspect both `policy_evaluated` and `auth_results` to see which result the row contains. ### Should I change my DMARC policy after one failing row? No. First identify the source and reproduce the relevant result on a fresh message. A policy change affects receiver instructions and reporting, but it does not fix a wrong key, a modified message, or an unauthorized sender. ### Why does the report show a selector I do not recognize? The selector belongs to the DKIM signature the receiver evaluated for that reported sender path. If the source is authorized, identify the service that signed it. If it is not authorized, preserve the evidence and investigate the source before publishing any record. --- # One-click unsubscribe in Salesforce Marketing Cloud Canonical: https://www.palisade.email/learning/one-click-unsubscribe-marketing-cloud > Understand one-click unsubscribe on Salesforce Marketing Cloud commercial sends and validate the delivered-message result. One-click unsubscribe in Salesforce Marketing Cloud Engagement is documented for commercial sends: the platform includes the List-Unsubscribe header, and an inbox provider may use it to present an unsubscribe control. When a provider sends the RFC 8058 POST, Salesforce handles it as a publication-list unsubscribe. You cannot force an inbox to display the control, so validate the headers in a real commercial test message and verify the resulting subscriber status. [Salesforce's List-Unsubscribe documentation](https://help.salesforce.com/s/articleView?id=sf.mc_es_one_click_header_unsubscribe.htm&language=en_US&type=5) is the controlling product source. ## Quick takeaways - Salesforce documents the header behavior for commercial sends, not every message type or every mailbox interface. - Inbox providers decide whether to show a built-in unsubscribe control. - A one-click request is separate from an unsubscribe link in the email body or a custom preference center. - Salesforce documents the resulting action as an unsubscribe from the publication list. - Inspect a delivered commercial message before treating the feature as working for your sending path. ## Who is affected? This applies to operators who send commercial email through Salesforce Marketing Cloud Engagement and need to understand what a mailbox-provider unsubscribe action changes. [Salesforce's unsubscribe documentation](https://help.salesforce.com/s/articleView?id=sf.mc_es_unsubscribes.htm&language=en_US&type=5) distinguishes list, publication-list, and broader unsubscribe states. This article concerns the documented header-driven publication-list outcome, not a custom CloudPage, preference-center design, or consent synchronization with another system. The mailbox, not Marketing Cloud Engagement, controls whether a recipient sees an unsubscribe control. A missing control in one mailbox is therefore not proof that Salesforce failed to include the header. For the vendor-neutral header pair, POST rules, and DKIM coverage, see [our RFC 8058 one-click unsubscribe guide](/learning/one-click-unsubscribe). ## What are the requirements? ### Commercial sends use the documented header path [Salesforce Help says commercial sends include the List-Unsubscribe header](https://help.salesforce.com/s/articleView?id=sf.mc_es_one_click_header_unsubscribe.htm&language=en_US&type=5), and that customers cannot disable or alter this header behavior. Its documentation also states that an inbox provider can use the header to offer an unsubscribe option. That describes the sending-platform behavior; it does not require a particular Gmail, Yahoo, or Outlook display. ```text Delivered commercial test message List-Unsubscribe: <https://...> List-Unsubscribe-Post: List-Unsubscribe=One-Click Expected evidence: headers in the raw message, not a guaranteed inbox button. ``` ### A one-click request is a mailbox-to-sender POST [RFC 8058](https://www.rfc-editor.org/rfc/rfc8058.html) is an Internet Standards Track specification. It defines a `List-Unsubscribe` HTTPS URI and `List-Unsubscribe-Post: List-Unsubscribe=One-Click` as the one-click signal. A receiver may send an HTTPS POST after user consent; it should use `multipart/form-data` and may use `application/x-www-form-urlencoded`. The standard requires no cookies or HTTP authorization in that POST and says the sender must not rely on an HTTPS redirect. ![Commercial send to header, optional mailbox control, RFC 8058 POST, and publication-list unsubscribe.](/images/editorial/one-click-unsubscribe-marketing-cloud/one-click-unsubscribe-marketing-cloud-flow.svg "1200x926") *Source: Original Palisade protocol flow based on [Salesforce Help's List-Unsubscribe behavior](https://help.salesforce.com/s/articleView?id=sf.mc_es_one_click_header_unsubscribe.htm&language=en_US&type=5) and [RFC 8058](https://www.rfc-editor.org/rfc/rfc8058.html). It illustrates the documented request path, not a mailbox or Salesforce interface.* ### The documented Salesforce outcome is publication-list unsubscribe [Salesforce documents the resulting one-click POST as a publication-list unsubscribe](https://help.salesforce.com/s/articleView?id=sf.mc_es_one_click_header_unsubscribe.htm&language=en_US&type=5). Do not infer from that alone that a CRM consent record, another data extension, or an external suppression system has changed. Those integrations and any broader consent policy need their own tenant-specific evidence. ## When does the requirement take effect? The Salesforce behavior above is product documentation, not a date-based mailbox-provider mandate. For Gmail, [Google's Email sender guidelines](https://support.google.com/a/answer/81126) apply one-click unsubscribe requirements to covered bulk senders of marketing and subscribed messages. The applicable provider rule depends on the recipient provider and sending volume, while the Salesforce question is whether the delivered commercial message follows the documented header path. Check the current provider guidance when the campaign is in scope for a bulk-sender rule. ## How do I implement the requirement? ### 1. Confirm that the send is commercial Use the same commercial message type and sending path that your subscribers receive. Salesforce scopes the documented automatic header behavior to commercial sends, so a transactional or custom path is not evidence for this case. Keep the body unsubscribe link and preference-center workflow under their own requirements. ### 2. Send a controlled message and inspect its raw source Deliver a test to a mailbox you control, then inspect the original message source. Record whether `List-Unsubscribe` and `List-Unsubscribe-Post` appear. The raw headers are stronger evidence than a mailbox button because Salesforce states that the inbox provider controls the display. ### 3. Verify the publication-list result safely Where your test procedure permits it, use the mailbox's unsubscribe action and confirm the expected publication-list status in an approved non-production test record. Do not test against a customer address or assume the result proves changes in connected CRM or consent systems. If the header is absent, first confirm the message was a commercial send before escalating the case with the delivered headers. ## How do I validate compliance? Start with the delivered message and the intended subscriber outcome. A useful validation record includes the send classification, the raw `List-Unsubscribe` and `List-Unsubscribe-Post` lines, the mailbox provider used for the test, and the observed publication-list status after an approved test. Keep screenshots of inbox controls optional, because an interface can change or remain hidden even when the header is present. For broader provider readiness, use the [Gmail and Yahoo sender-requirements checklist](/learning/google-is-making-email-sender-requirements-stricter-starting-nov-2025) and distinguish it from [email authentication](/learning/what-is-email-authentication-and-why-does-it-matter). DNS, SPF, DKIM, and DMARC evidence can support authentication troubleshooting, but they do not prove that a specific Marketing Cloud Engagement message contained the one-click header or that its publication-list update completed. ## Check the wider provider requirements Once the commercial-send test is documented, compare the campaign with the wider [Gmail and Yahoo 2024 sender update](/learning/gmail-bulk-sender-guidelines). That guide is the closest next step for a team that needs the rest of the provider rules alongside this Marketing Cloud Engagement behavior. [Review the sender-requirements checklist](/learning/google-is-making-email-sender-requirements-stricter-starting-nov-2025) That checklist cannot inspect a delivered Marketing Cloud Engagement message, force a mailbox control to appear, or prove a subscriber-status or consent-system change. ## Sources and further reading - [Salesforce Help: List-Unsubscribe Header Unsubscribe](https://help.salesforce.com/s/articleView?id=sf.mc_es_one_click_header_unsubscribe.htm&language=en_US&type=5) - [Salesforce Help: Unsubscribes](https://help.salesforce.com/s/articleView?id=sf.mc_es_unsubscribes.htm&language=en_US&type=5) - [RFC 8058: Signaling One-Click Functionality for List Email Headers](https://www.rfc-editor.org/rfc/rfc8058.html) - [Google Email sender guidelines](https://support.google.com/a/answer/81126) ## Frequently asked questions ### Does Salesforce Marketing Cloud Engagement always show an unsubscribe button? No. Salesforce documents the header on commercial sends, but the inbox provider decides whether to present an unsubscribe control. Inspect the delivered raw message to verify the header path before using the absence of a button as a troubleshooting signal. ### Does one-click unsubscribe replace the email footer link? No. The header-driven action and an in-message unsubscribe or preference-center link serve different paths. Keep the body link according to your applicable provider and legal requirements, even when the commercial message contains the one-click headers. ### What status does the Salesforce one-click request change? Only the documented outcome is a publication-list unsubscribe. Do not assume that a universal unsubscribe, global unsubscribe, CRM consent record, or another connected suppression system changes unless your tenant configuration and integration evidence confirm it. ### Can I customize the Salesforce one-click headers? No. Salesforce's List-Unsubscribe documentation says customers cannot disable or alter the headers for the documented commercial-send behavior. Use a delivered-message test to establish what your actual sending path contains instead of attempting to construct a replacement header. ### What should I retain from a validation test? Keep the commercial send classification, raw header lines, the receiving mailbox provider, the date, and the publication-list result from an approved test record. Those facts let you separate platform behavior from mailbox display and from any separate consent-system synchronization. --- # Pharming vs phishing Canonical: https://www.palisade.email/learning/pharming-vs-phishing > Pharming vs phishing: phishing uses a deceptive lure, while pharming redirects users to a fraudulent site through technical means. Learn the difference. Phishing and pharming can both lead to stolen credentials, but the initial path differs. [Phishing](https://www.nist.gov/itl/smallbusinesscyber/guidance-topic/phishing) uses a deceptive message or prompt to make someone act. [Pharming](https://csrc.nist.gov/glossary/term/pharming) uses technical redirection to send someone to a fraudulent site, sometimes after they use an address or route they trust. A real incident can contain both mechanisms, so classify the evidence before assuming the redirect's cause. ## Quick takeaways - Phishing is a social-engineering lure that tries to persuade a person to click, download, reply, approve, or disclose information. - Pharming redirects a person to a fraudulent site through technical means rather than relying only on a deceptive prompt. - A counterfeit sign-in page alone does not establish whether an event was phishing, pharming, or both. - Stop before entering credentials or approving a request, then verify the organization through a separately obtained route. - Spoofing can make a phishing message look credible, but identity impersonation does not by itself prove pharming. - Public SPF, DKIM, and DMARC checks can show a domain's published authentication posture. They cannot investigate a browser redirect or fraudulent website. ## Who this comparison is for This comparison is for someone triaging a suspicious sign-in page, unexpected redirect, or deceptive message. It helps security teams, IT administrators, and affected users describe what they observed so the investigation starts with the right evidence. Use it when the question is, "Did someone lure the user to this page, or did a trusted route send the user somewhere unexpected?" The answer affects what evidence to preserve. A suspicious message calls for sender, link, attachment, and request evidence. An unexpected redirect can require browser, endpoint, router, network, or DNS evidence. The terms can overlap. Do not force an event into one category when the available evidence supports both. Record the observed path and mark the root cause as needs-human when there is no confirmed technical finding. For the broader message-led threat, see [what phishing is](/learning/what-is-phishing). For the related question of a forged identity, see [what email spoofing is](/learning/what-is-spoofing). ## How the options were evaluated The comparison uses stable definitions from NIST and was checked on 2026-08-12. The key criterion is the attack path observed before the person reached the fraudulent site: - Initial mechanism: a deceptive communication, technical redirection, or evidence of both. - Evidence available: the message, the address entered, the destination reached, and any endpoint or network observations. - Immediate response: whether the person must stop an interaction and verify a request independently. - Investigation boundary: what the observed evidence can establish and what still needs human technical investigation. - Domain-owner follow-up: whether a public email-authentication check has a relevant but limited role. The lure-versus-redirection classifier below is an editorial synthesis of [NIST's phishing guidance](https://www.nist.gov/itl/smallbusinesscyber/guidance-topic/phishing), [NIST's pharming definition](https://csrc.nist.gov/glossary/term/pharming), and [NISTIR 7770's comparison of phishing and pharming](https://tsapps.nist.gov/publication/get_pdf.cfm?pub_id=907707). It classifies the first observed path. It does not diagnose the root cause of any redirect. ![Decision flow for distinguishing a deceptive message-led lure from a trusted route redirected to a fraudulent site](/images/editorial/pharming-vs-phishing/pharming-vs-phishing-classifier.svg "1200x646") *Source: [Pharming](https://csrc.nist.gov/glossary/term/pharming), checked 2026-07-28.* ## Pharming Pharming is the better label when technical means redirect a person to a fake site that masquerades as a legitimate one. NIST's glossary says the redirection can involve a compromised infrastructure service, such as DNS, or the subscriber's endpoint. - Best fit: An event where a person typed or used a familiar address or trusted route but reached an unexpected destination. - Relevant evidence: [NIST's pharming definition](https://csrc.nist.gov/glossary/term/pharming) describes technical redirection to a fake site and identifies infrastructure services and endpoints as possible locations for the mechanism. - Tradeoff: The term does not prove that DNS caused the event. A suspicious page, by itself, cannot distinguish a DNS issue from an endpoint, browser, router, network, or other redirection path. Preserve what the user entered, the address displayed before and after the redirect, the time of the event, and any available browser or endpoint observations. Do not change DNS records because a page looks fraudulent. That action could disrupt legitimate mail or web traffic without resolving the actual cause. A public DNS lookup can establish what is published at the time of the query. It cannot prove which resolver, device, or network path a user used during an incident. Keep that distinction clear when assigning the technical investigation. ## Phishing Phishing is the better label when a convincing email, text, social message, or other communication tries to persuade someone to take a harmful action. NIST describes phishing messages that can induce people to follow harmful links, download malicious software, transfer funds, log in, or submit sensitive information. - Best fit: An event that begins with an unexpected request, message, attachment, link, sign-in prompt, or payment instruction. - Relevant evidence: [NIST phishing guidance](https://www.nist.gov/itl/smallbusinesscyber/guidance-topic/phishing) advises verifying a request through known contact information or a public company site, rather than relying on contact details supplied in the message. - Tradeoff: A deceptive message does not establish why a later browser redirect occurred. It may be the full attack path, or it may be one part of a wider incident. The first safe action is to stop before entering credentials, downloading a file, approving a request, or transferring funds. Verify the organization through a saved address, independently found official site, or established contact number. Do not use a number, link, or chat prompt supplied by the suspicious message or page. Business email compromise and phishing are also distinct. Business email compromise often centers on impersonation and payment or account actions, while phishing describes the deceptive effort to obtain an action or disclosure. ## How to choose Choose phishing when the first observed path is a deceptive prompt. Choose pharming when a legitimate address or trusted route appears to redirect the person to a fraudulent destination. Record both when evidence supports a lure and a later technical redirection. ```yaml option: pharming checked_on: 2026-08-12 best_fit: "Unexpected redirection from a familiar address or trusted route" verified_evidence: - "NIST defines pharming as technical redirection to a fake site" - "Possible mechanisms include infrastructure services or the subscriber endpoint" open_question: "Which browser, endpoint, DNS, router, or network mechanism caused this event?" option: phishing checked_on: 2026-08-12 best_fit: "A deceptive message or prompt that asks a person to act" verified_evidence: - "NIST describes messages that induce harmful clicks, downloads, transfers, logins, or disclosures" - "Independent verification is safer than using contact details in the suspicious message" open_question: "Did the message itself deliver the user to the fraudulent site, or did a separate redirect occur?" option: Palisade public email-authentication evidence checked_on: 2026-08-12 best_fit: "A domain owner reviewing public SPF, DKIM, and DMARC posture after a reported email-based event" verified_evidence: - "The Email Security Score reviews public domain signals" open_question: "Did the reported message authenticate on its actual production path, and did a redirect involve an endpoint or network?" ``` Use a needs-human escalation when a user reports an unexpected redirect but cannot provide the address entered, the destination reached, or relevant device and network details. The mechanism remains unknown until the responsible security or IT team can inspect the applicable evidence. ![Response map separating immediate safety actions from message evidence and unexpected-redirection evidence](/images/editorial/pharming-vs-phishing/pharming-vs-phishing-response-map.svg "1200x859") *Source: [Phishing](https://www.nist.gov/itl/smallbusinesscyber/guidance-topic/phishing), checked 2026-07-28.* ![Operational comparison of phishing, pharming, and a public domain-authentication review](/images/editorial/pharming-vs-phishing/pharming-vs-phishing-attack-paths.webp "1200x442") *Source: Palisade.* ## What email authentication can and cannot address SPF, DKIM, and DMARC concern email identity and message handling. [RFC 9989](https://www.rfc-editor.org/rfc/rfc9989.html) defines DMARC as a way for a domain owner to publish requested handling for messages that fail DMARC validation, while receivers apply their own local policy. That makes domain authentication relevant when a reported phishing message appears to use an organization's sender domain. It does not make DMARC browser, endpoint, router, resolver, or fraudulent-site forensics. Stronger authentication can reduce unauthorized use of a domain in email, but it does not prove that every future message will authenticate or guarantee delivery. [Email security controls](/learning) work in layers. A domain owner should separate the question "What does our domain publish?" from "What happened on this user's device and browser?" Those questions need different evidence. ## Review public email-authentication signals you control If you administer the domain named in a suspicious email, use the [Email Security Score](/tools/email-security-score) to inspect public SPF, DKIM, and DMARC signals. This is a useful starting point for a domain-authentication review when the available input is a public domain. The result is a point-in-time view of public DNS evidence. It cannot determine why a browser redirected, inspect an endpoint compromise, remove a fraudulent site, prove a production sending path, or reveal a receiver's private filtering decision. Compare any public result with the actual message headers and your organization's reporting process before drawing an incident conclusion. For teams evaluating recurring DMARC work across domains, [Palisade comparisons](/compare) can help frame the operating-model question. Palisade is agentic DMARC software that analyzes DMARC aggregate-report data, identifies sending sources and authentication or alignment issues, and proposes a next policy step for human review. It does not autonomously change DMARC policy, investigate browser redirects, or prevent pharming and phishing incidents. ## Sources and further reading - [NIST glossary: Pharming](https://csrc.nist.gov/glossary/term/pharming) - [NIST phishing guidance](https://www.nist.gov/itl/smallbusinesscyber/guidance-topic/phishing) - [NISTIR 7770: Trustworthy email](https://tsapps.nist.gov/publication/get_pdf.cfm?pub_id=907707) - [RFC 9989: DMARC](https://www.rfc-editor.org/rfc/rfc9989.html) - [Palisade Email Security Score](https://www.palisade.email/tools/email-security-score) ## Frequently asked questions ### Is pharming the same as phishing? No. Phishing uses a deceptive prompt to persuade a person to act. Pharming uses technical redirection to send a person to a fraudulent site. Both can lead to credential theft, and one incident can include both mechanisms. ### Can a phishing email lead to pharming? Yes. A phishing message can be part of a wider incident that later includes technical redirection. The message alone does not prove that the redirect was pharming. Preserve the message and investigate the redirect with the relevant browser, endpoint, network, or DNS evidence. ### Does a fake login page prove pharming? No. A fake login page proves that the destination is suspicious or fraudulent. It does not reveal how the person arrived there. Check whether the initial path was a deceptive prompt, a trusted address that redirected elsewhere, or both. ### Does DMARC prevent pharming? No. DMARC applies to email-message authentication and requested receiver handling for DMARC failures. It does not investigate or control browser, endpoint, router, DNS-resolver, or web-site redirection. ### Should I change my DNS records after an unexpected redirect? Only after the responsible technical team has evidence that a DNS configuration or DNS infrastructure issue caused the redirect. Changing DNS records based only on a suspicious page can create service disruption and may leave the actual cause unresolved. --- # Phishing protection browser add on Canonical: https://www.palisade.email/learning/phishing-protection-browser-add-on > Set up a phishing protection browser add on safely, review permissions, validate the control, and keep a rollback path. A phishing protection browser add on can add a useful warning layer, but start by enabling the browser's built-in protection and treat any extension as a separately approved control. Choose one whose permissions, privacy terms, support path, and removal process your organization can accept. Then validate the configuration with an authorized, harmless exercise. This process cannot prove that a particular site is safe or that every phishing attempt will be blocked. ## Quick takeaways - Keep the browser's native phishing and malware protection enabled before evaluating an add-on. - Approve an extension only after reviewing its publisher, requested access, privacy information, and support lifecycle. - Prefer the narrowest site access that still supports the documented function. - Pilot the control with an authorized test or reporting workflow, not with a live suspicious URL. - Record an owner, support route, and removal path so the add-on does not become an unmanaged browser exception. ## Scope and prerequisites This guide covers a browser-local warning layer for managed workstations. It does not compare products, configure a particular vendor console, or replace [a layered phishing-protection program](/learning/anti-phishing-program). A browser warning can help interrupt a risky visit, but the phishing definition still includes the deceptive request and the action it tries to obtain, as [NIST's phishing glossary](https://csrc.nist.gov/glossary/term/phishing) explains. Before rollout, name the browser owner, the managed-device population, the approved extension source, and the support contact. Keep the browser current. If your organization manages Chrome, its administrator can allow or block extensions based on requested permissions through its documented [extension policy controls](https://support.google.com/chrome/a/answer/9867568?hl=en). For unmanaged devices, the user still needs a written approval and removal path. Do not turn off a native warning layer to make a new add-on work. Chrome documents phishing and malware detection as enabled by default and says its Safe Browsing warnings can cover phishing, malware, unwanted software, and social-engineering sites in its [unsafe-site warning guidance](https://support.google.com/chrome/answer/99020?hl=en). Other browsers have different settings and policy controls, so use their current official documentation for the equivalent baseline. ## Choose the implementation approach Use the native browser protection when it is already centrally managed and meets the immediate need. Consider an add-on only when it adds a documented function your organization has approved, such as an additional warning or reporting workflow, without requesting access that is disproportionate to that function. Permission review is part of the security decision. Chrome's extension documentation explains that access to data on all visited websites can allow an extension to read, request, or modify page data, while access limited to listed sites is narrower. Read the current [Chrome Web Store permission guidance](https://support.google.com/chrome_webstore/answer/186213?hl=en) beside the extension's own privacy notice and support documentation. The permission warning does not by itself prove an extension is malicious, but it identifies access that needs a business justification. If the add-on is intended for Firefox, verify the same decision in Firefox's current [optional-permissions documentation](https://support.mozilla.org/en-US/kb/manage-optional-permissions-extensions). It describes reviewing and changing optional permissions in the Add-ons Manager. Do not assume that a permission label or control works the same way in another browser. ![Decision card showing the setup sequence: native browser protection, approved extension choice, permission and privacy review, authorized validation, then keep, tune, or remove.](/images/editorial/phishing-protection-browser-add-on/browser-protection-decision-card.svg "1200x929") *Source: Original Palisade procedure informed by [Chrome's extension permission guidance](https://support.google.com/chrome_webstore/answer/186213?hl=en) and [CISA browser-security guidance](https://www.cisa.gov/sites/default/files/publications/Capacity_Enhancement_Guide-Securing_Web_Browsers_and_Defending_Against_Malvertising-Guidance_for_Non-Federal_Organizations.pdf). This card is a setup procedure, not a verdict about a website or extension.* ## How to configure a phishing protection browser add on ### 1. Confirm the native browser baseline Ask the browser or endpoint owner to confirm that the supported browser is current and its documented phishing and malicious-download warnings remain enabled. Record the browser version range and the policy owner. This avoids treating an extension as a substitute for a security feature already provided by the browser. ### 2. Approve the publisher and install source Use the organization-approved browser store or managed deployment path. Match the publisher to the approved vendor record, read the privacy and support information, and reject unsigned packages, copied links, and installs prompted by a pop-up. CISA's browser-security guidance recommends applying browser configuration guidance and identifies malicious advertising and redirects as browser risks in its [securing web browsers guide](https://www.cisa.gov/sites/default/files/publications/Capacity_Enhancement_Guide-Securing_Web_Browsers_and_Defending_Against_Malvertising-Guidance_for_Non-Federal_Organizations.pdf). ### 3. Review access before enabling the add-on Compare each requested permission with the documented function. Prefer access only when selected or on approved sites when that is sufficient. Escalate broad access to all sites, browsing history, clipboard data, or proxy and VPN behavior for a privacy and security review. Chrome notes that site-access changes do not cover extensions that alter lower-level network access through VPN or proxy settings in its [extension-management documentation](https://support.google.com/chrome/answer/2664769?hl=en). ```yaml approval_record: browser_baseline: "documented native protection enabled" publisher_verified: true requested_access: "record each permission and its business reason" privacy_review: "approved policy and data-handling terms" pilot_owner: "named browser or endpoint owner" rollback: "disable or uninstall through the approved management path" ``` This is an approval record format, not a browser configuration. Do not copy account-specific policy values from another organization. ### 4. Pilot without visiting a real suspected phishing site Use an authorized training simulation, a browser vendor's safe reporting path, or a managed test page approved by your security team. Check that the warning or reporting route reaches the expected owner and that legitimate business sites continue to work. Do not use a live suspicious URL as a test case, and do not ask staff to bypass a warning to establish whether the add-on works. ### 5. Document the support and rollback path Record who can disable or remove the add-on, how an employee reports a false positive, and how the team restores browser access if an update causes an outage. Preserve the native baseline unless the authorized browser owner deliberately changes it. If an extension becomes unsupported or damaged, use the approved removal path and return to the browser-native baseline while the owner reviews the next step. ## How to validate the setup Validate the setup in four layers. First, confirm the browser or management policy shows the native protection and approved extension in the intended state. Second, compare the actual permissions against the signed-off approval record. Third, run the authorized harmless simulation or reporting workflow and record the observed warning, report, or support action. Fourth, review help-desk tickets and browser telemetry, where your organization lawfully collects it, for breakage and false positives during the pilot. For the browser layer, these are implementation and operating checks, not DNS, message-header, or DMARC validation. Browser protection does not replace the sender-side controls described in [email authentication and phishing protection](/learning/what-is-phishing), and it cannot establish why an individual email was delivered. If someone has already interacted with a suspicious page, use [the post-click response procedure](/resources-post/what-to-do-if-you-clicked-on-a-phishing-link) rather than relying on the add-on's presence as incident evidence. ## Troubleshooting ### The add-on asks for more access than the documented function needs Pause the rollout. Compare the permission with the vendor documentation, then request an approved explanation or choose a control with a narrower documented scope. Do not grant broad site access simply because the extension is marketed as security software. ### A legitimate site breaks during the pilot Capture the URL category, timestamp, browser version, and extension version without collecting credentials or page contents. Follow the approved support process, and disable or remove the add-on if access cannot be restored safely. Keep the browser's native protection enabled while the issue is investigated. ### The browser warns about a site but a user wants to continue Treat the warning as a stop signal for the user, not proof that an administrator can safely override it. Verify the request through a known, separate service path. Chrome explicitly recommends not visiting a site when it presents a dangerous-site warning in its [Safe Browsing warning guidance](https://support.google.com/chrome/answer/99020?hl=en). ### The extension becomes unsupported or corrupted Use the approved management path to disable or remove it and return to the native browser baseline. Replace an unsupported extension only after the same publisher, permission, privacy, pilot, and rollback review used for the original approval. ## Sources and further reading - [Google Chrome Help: manage warnings about unsafe sites](https://support.google.com/chrome/answer/99020?hl=en) - [Google Chrome Web Store Help: permissions requested by apps and extensions](https://support.google.com/chrome_webstore/answer/186213?hl=en) - [Google Chrome Enterprise Help: configure ExtensionSettings policy](https://support.google.com/chrome/a/answer/9867568?hl=en) - [CISA: Securing Web Browsers and Defending Against Malvertising](https://www.cisa.gov/sites/default/files/publications/Capacity_Enhancement_Guide-Securing_Web_Browsers_and_Defending_Against_Malvertising-Guidance_for_Non-Federal_Organizations.pdf) ## Frequently asked questions ### Do I need an add-on if the browser already warns about phishing? Not always. Start with the native warning layer and the browser-management controls already available. Add an extension only when it has a documented, approved function that fills a specific gap and its access can be justified. ### Can a browser extension prove that a website is safe? No. A warning or lack of a warning is not a complete safety verdict. Keep independent verification, endpoint controls, identity protections, and incident-response procedures in place. ### Should an anti-phishing add-on have access to every website? Only when that broad access is necessary for the approved, documented function and has passed the required privacy and security review. Prefer narrower access when it can deliver the intended protection. ### How should I test a browser phishing-protection add-on? Use an authorized harmless simulation, a documented reporting workflow, or another approved test. Do not visit a live suspicious URL, bypass a browser warning, or expose staff to an uncontrolled phishing page for testing. ### What should I do if someone already entered credentials on a suspicious page? Treat the event as an incident and follow the organization's response process. Reset exposed credentials through a known legitimate path, review sign-ins, and use the [post-click phishing response guide](/resources-post/what-to-do-if-you-clicked-on-a-phishing-link) for the immediate evidence-led steps. --- # Proofpoint DMARC checker: what a compliance check does and doesn't prove Canonical: https://www.palisade.email/learning/proofpoint-dmarc-checker > What Proofpoint's DMARC compliance assessment covers, the difference between a published record and an aligned message, and how to verify your own domain free. Proofpoint's DMARC Compliance Check is a form-led assessment, not an instant anonymous domain checker. Proofpoint says the process includes a 15-minute kickoff call, a one-page assessment with SPF, DKIM, and DMARC pass ratings plus policy status, then a follow-up call. Choose the Proofpoint assessment when you want that scoped engagement. Choose a public DNS lookup when you need to inspect the published DMARC record immediately. ## Quick takeaways - Proofpoint describes its DMARC Compliance Check as an assessment with a form submission and scheduled calls. - The documented assessment output includes SPF, DKIM, and DMARC pass ratings, along with DMARC policy status. - A public DNS lookup can show the DMARC record that receivers can resolve at the time of the query. - A DMARC record alone cannot establish production message pass rates or complete sender coverage. - A delivered message and DMARC aggregate reports validate different layers of a DMARC deployment. - Do not change a DMARC policy based on a status label without identifying affected senders and checking alignment. ## Who this comparison is for This comparison is for a domain owner who searched for a Proofpoint DMARC checker and needs to decide between requesting an assessment or checking a public record now. The distinction matters when a team is investigating a DMARC warning, preparing for enforcement, or gathering evidence before a vendor discussion. The two paths accept different inputs and produce different evidence. Proofpoint's published process is an engagement intended to provide an assessment. A public lookup starts with a domain name and reads DNS. Neither result, on its own, proves that every production sender authenticates correctly or that every receiver will deliver future mail. For a broader explanation of the protocol, see Palisade's [DMARC learning hub](/learning/dmarc). This article stays focused on the narrower question: what Proofpoint's current compliance check includes, and what an immediate public check can establish instead. ## How the options were evaluated The options were assessed against current first-party documentation checked on August 12, 2026. The criteria are the same for both: - Input and access: whether the reader submits a form for an assessment or enters a public domain for a lookup. - Documented output: whether the result is an assessment with pass ratings and policy status, or a DNS record result. - Evidence scope: what the result can establish about public policy, message authentication, and sender coverage. - Time model: whether the evidence is a point-in-time public lookup or a scoped assessment process. - Decision boundary: what additional evidence is required before changing the DMARC policy. A documented capability counts as available. Proofpoint does not publish the private methodology, data window, receiver coverage, or calculation details behind an individual assessment on the public page, so those remain questions for the engagement. A public DNS result establishes only the record returned for that query. It does not reveal private traffic or a mailbox provider's private filtering decision. ## Proofpoint DMARC Compliance Check Proofpoint's [Email DMARC Compliance Check](https://www.proofpoint.com/us/learn-more/email-dmarc-check) describes a process that begins with a form. The published sequence includes a 15-minute kickoff call, a one-page assessment, and a follow-up call. Proofpoint says the assessment includes SPF, DKIM, and DMARC pass ratings and DMARC policy status. - Best fit: A domain owner who wants a vendor-led assessment discussion and the documented one-page report. - Relevant evidence: Proofpoint documents the kickoff, assessment, pass ratings, policy status, findings, recommendations, and follow-up call on its [Email DMARC Compliance Check page](https://www.proofpoint.com/us/learn-more/email-dmarc-check), checked August 12, 2026. - Tradeoff: The public page does not present an immediate domain-result screen. Its public description also does not disclose the exact data window, included receivers, source grouping, or calculation method for an individual assessment. Treat the assessment as evidence to review, not as a standalone authorization to move to `p=quarantine` or `p=reject`. DMARC evaluation depends on SPF or DKIM authentication with identifier alignment, as defined by [RFC 9989](https://www.rfc-editor.org/rfc/rfc9989.html). A pass-rate percentage is only useful when you understand which domains, message sources, dates, exclusions, and definitions produced it. Proofpoint also describes authentication and alignment problems as reasons DMARC can fail in its [DMARC policy guidance](https://www.proofpoint.com/us/us/blog/email-and-cloud-threats/dmarc-policy-why-dmarc-fails). That general explanation does not identify the cause of a particular domain's failures. Confirm the sending path before treating an assessment finding as a repair instruction. ## Palisade DMARC checker Palisade's [DMARC checker](/tools/dmarc) is the direct fit when you have a public domain name and need to inspect the current DMARC record without scheduling an assessment. It is a point-in-time public DNS check, so its value is immediate record evidence rather than vendor analysis of traffic. - Best fit: An operator who needs to inspect the published DMARC policy, reporting destinations, and record-level findings for a public domain. - Relevant evidence: The [Palisade DMARC checker](/tools/dmarc) accepts a domain and reports public DMARC record information. - Tradeoff: A public lookup cannot calculate SPF or DKIM pass rates, inspect private mail traffic, reproduce Proofpoint's one-page assessment, or evaluate whether a vendor relationship fits the organization. If you need to inspect related DNS records beyond DMARC, use Palisade's [DNS lookup](/tools/dns-lookup). Use a public result to establish what a receiver can resolve now. A structurally valid record can still coexist with unsigned mail, misaligned third-party senders, forwarding effects, or a source that is absent from a short observation window. ```text Illustrative only. Do not publish this example as your production record. _dmarc.yourdomain.com TXT "v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com" ``` The record shape above shows a monitoring policy and an aggregate-report destination. The actual record for a domain must use the domain owner's approved reporting address and policy. Do not copy another organization's values. ![Decision map showing when to use a Proofpoint assessment, a public DMARC lookup, a delivered message, or aggregate reports](/images/editorial/proofpoint-dmarc-checker/proofpoint-dmarc-checker-decision-map.webp "1200x829") *Source: Palisade.* ## How to choose Choose Proofpoint's assessment if the useful next action is a vendor-led discussion with a documented one-page review of SPF, DKIM, DMARC pass ratings, and policy status. Before the kickoff, prepare questions that make each conclusion traceable. Choose a public DMARC lookup if the immediate question is, "What policy and report destinations does this domain publish right now?" It is the faster branch when you have only a domain name and need DNS evidence before deciding whether an assessment is worthwhile. Use a delivered production message when the question is whether one exact sender path authenticated and aligned. Use aggregate reports when the question is whether multiple receivers reported authentication and disposition evidence across a reporting period. [RFC 9990](https://www.rfc-editor.org/rfc/rfc9990.html) defines the DMARC aggregate-report format. ```yaml option: Proofpoint DMARC Compliance Check checked_on: 2026-08-12 best_fit: Vendor-led assessment discussion for a domain's DMARC posture verified_evidence: Form-led process, 15-minute kickoff, one-page assessment, pass ratings, policy status, follow-up call open_question: Individual assessment data window, receiver coverage, source grouping, exclusions, and calculation method ``` ```yaml option: Palisade DMARC checker checked_on: 2026-08-12 best_fit: Immediate inspection of a public domain's DMARC DNS record verified_evidence: Public domain lookup and record-level DMARC findings open_question: Production pass rates, complete sender inventory, private receiver decisions, and future DNS state ``` > Do not move a domain to an enforcement policy because one checker or assessment status appears favorable. Confirm the legitimate sender inventory, SPF or DKIM alignment, a delivered message from each important path, and aggregate-report evidence before approving a policy change. ### 1. Confirm the public DNS layer Look up the domain's DMARC record. Record the policy, reporting addresses, and any syntax issue. Check the answer against the authoritative DNS configuration and at least one public resolver when a change is pending. ### 2. Confirm the vendor or sender layer For a Proofpoint assessment, ask which domains and sources were included and which period the pass ratings cover. For every material sending service, confirm its current authentication status in that service's own configuration or verification view. ### 3. Confirm a production message layer Send or locate a real message from the exact production path. Inspect its `Authentication-Results` header and determine whether SPF or DKIM passed with an identifier aligned to the visible From domain. RFC 9989 defines the alignment relationship used for DMARC evaluation. ### 4. Confirm the DMARC reporting layer Collect aggregate reports after the reporting address is active and traffic has accumulated. Compare source IPs, disposition, authentication results, and alignment data with the sender inventory. Aggregate reports help reveal repeated sources, but receiver participation and visibility are not complete by default. ## Check the public record before the assessment call If the immediate task is to inspect the record a receiver can resolve, use the [Palisade DMARC checker](/tools/dmarc) with the sending domain. Bring the result, a sender inventory, sample headers, and any available aggregate-report evidence to an assessment discussion. The lookup does not calculate SPF or DKIM pass rates, inspect private traffic, reproduce Proofpoint recommendations, monitor later DNS changes, or judge a vendor relationship. ## Sources and further reading - [Proofpoint Email DMARC Compliance Check](https://www.proofpoint.com/us/learn-more/email-dmarc-check) - [Proofpoint guidance on why DMARC can fail](https://www.proofpoint.com/us/us/blog/email-and-cloud-threats/dmarc-policy-why-dmarc-fails) - [RFC 9989: DMARC](https://www.rfc-editor.org/rfc/rfc9989.html) - [RFC 9990: DMARC aggregate reporting](https://www.rfc-editor.org/rfc/rfc9990.html) - [Palisade DMARC checker](/tools/dmarc) ## Frequently asked questions ### Is Proofpoint's DMARC Compliance Check an instant checker? No. Proofpoint's public page describes a form-led engagement with a 15-minute kickoff call, a one-page assessment, and a follow-up call. It does not describe an anonymous result displayed immediately after entering a domain. ### What does Proofpoint say its DMARC assessment includes? Proofpoint says the one-page assessment includes SPF, DKIM, and DMARC pass ratings plus DMARC policy status. Ask which domains, reporting period, sources, and definitions support any percentage before using it for a policy decision. ### Can a public DMARC lookup show SPF and DKIM pass rates? No. A public lookup can inspect the DMARC record published in DNS. SPF and DKIM pass rates require message or report-derived evidence from the relevant sending paths. ### Can a valid DMARC record prove that all mail will pass DMARC? No. A valid record proves only that the published DNS record can be resolved and parsed. Each sender still needs an aligned SPF or DKIM result for the messages it sends. ### Do DMARC aggregate reports replace message-header checks? No. Aggregate reports summarize receiver-reported evidence across a reporting interval. A delivered-message header is still the best evidence for the authentication result of one exact production message path. --- # Proofpoint pricing: what is published and what drives cost Canonical: https://www.palisade.email/learning/proofpoint-pricing > Proofpoint pricing is quote-only for current enterprise plans. See dated Essentials rates, cost drivers, licensing considerations, and DMARC coverage. Proofpoint publishes dated list prices for its former Essentials small-business line, but it does not publish enterprise package prices. Choose the published Essentials sheets only as historical reference, then request a quote for current Proofpoint 365 Total Protection or enterprise packages. The documented cost drivers are user licences, contract term, and some consumption exceptions. DMARC-related hosted services also sit behind a separate product and package entitlement. ## Quick takeaways - Proofpoint's published US Essentials sheet is stamped October 2021, so it is not evidence of a current 2026 quote. - The published US sheet lists Business at $2.75, Advanced at $3.75, and Professional at $5.33 per active user per month. - Proofpoint's published EMEA Essentials sheet uses different package and regional pricing, so the two sheets cannot be combined into one global price list. - Enterprise packages are quote-based on Proofpoint's buying page, with no public package figures, minimum seat count, or discount ladder. - Published enterprise budgetary drivers include user licences, single-year or multi-year term, and consumption-based exceptions. - Hosted DMARC, DKIM, and SPF services are an Email Fraud Defense entitlement, not a published standalone DMARC price. ## Who this comparison is for This comparison is for an IT buyer, procurement owner, or MSP evaluating Proofpoint costs for email security and trying to separate public list-price evidence from quote-only products. It is also relevant when "Proofpoint Essentials pricing" appears in a budget discussion even though Proofpoint now markets that offering as [Proofpoint 365 Total Protection](https://www.proofpoint.com/us/products/email-protection/essentials). ![What Proofpoint publishes about pricing and what it leaves to a quote](/images/editorial/proofpoint-pricing/proofpoint-pricing-published.webp "1200x488") *Source: Palisade.* The decision has two parts. First, establish which Proofpoint product family covers the required job: inbound email security, human-risk controls, archiving, or DMARC operations. Second, establish whether the available published numbers apply to the region, package, date, user count, contract term, and consumption model under consideration. Palisade belongs in this decision only when the buyer is evaluating DMARC operations. It is not a secure email gateway and does not filter inbound mail, so it is not a replacement for Proofpoint's inbound filtering packages. See the broader [DMARC platform comparison guide](/proofpoint-dmarc-alternative) when the decision is specifically about DMARC software. Buyers can also run the [DMARC checker](/tools/dmarc) before comparing remediation requirements. ## How the options were evaluated The criteria below were checked against Proofpoint and Palisade first-party pages on August 12, 2026: - Published price evidence: whether the vendor publishes a figure, currency, unit, date, and product scope. - Product scope: whether the package covers email security, archiving, human-risk controls, or hosted email-authentication services. - Cost drivers: whether the vendor documents variables that affect a quote. - Entitlement boundary: whether a capability is included in a named package, offered as an add-on, or available only through a separate product. - Purchase path: whether the vendor provides self-serve checkout or directs the buyer to a quote, demo, trial, or assessment request. A documented capability counts as published evidence. A missing figure remains an open question. Missing public documentation does not prove that a product, discount, or commercial term is unavailable. ![Decision object separating published Proofpoint Essentials price sheets from quote-based enterprise packages and hosted DMARC entitlement questions](/images/editorial/proofpoint-pricing/proofpoint-pricing-decision-object.webp "1200x676") *Source: Palisade.* ## Proofpoint Essentials and Proofpoint 365 Total Protection Proofpoint's most specific public price evidence is a [US Essentials price list](https://www.proofpoint.com/sites/default/files/data-sheets/pfpt-uk-ds-essentials-pricelist-msrp-us.pdf) with a footer stamp of 10/21. It lists monthly MSRP per active user for three packages: - Business: $2.75 per active user per month. - Advanced: $3.75 per active user per month. - Professional: $5.33 per active user per month. - Essentials Security Awareness: $1.00 per active user per month as a separate line item. The same document identifies storage-related cost exposure for archive use. It includes 2 GB per user account, then lists archive data import at $3.00 per GB above that allowance and imported data management at $3.00 per GB per month until the retention period ends. A [separate EMEA monthly MSRP sheet](https://www.proofpoint.com/sites/default/files/data-sheets/pfpt-uk-ds-essentials-price-list-monthly-msrp-emea.pdf), stamped 5/22, lists four packages, including a Beginner tier restricted to existing customers. It uses GBP, EUR, and two USD regional price columns. Its USD figures and SKU assignments differ from the US sheet. Those documents establish that Proofpoint has published historical Essentials pricing. They do not establish a single current global price. A buyer should not select the lower of two figures, convert currencies, or combine package rows from the two sheets. Proofpoint now presents [Proofpoint 365 Total Protection](https://www.proofpoint.com/us/products/email-protection/essentials) as an all-in-one Microsoft 365 suite for MSPs. That live page refers to flexible packages but does not name public package prices. Treat the older Essentials sheets as dated commercial evidence, then ask Proofpoint which current product and regional terms apply. - Best fit: A buyer who needs historical, published small-business per-user list-price evidence for the former Essentials line. - Relevant evidence: The US sheet publishes three package rates, a separate Security Awareness price, and archive import and management charges. The EMEA sheet shows that pricing depends on region and package version. - Tradeoff: Neither sheet is a current enterprise quote or a reliable global rate card for Proofpoint 365 Total Protection. The [published Essentials package overview](https://www.proofpoint.com/sites/default/files/pfpt-us-essentials-packages-overview.pdf), stamped 4/23, also explains why higher package levels can cost more. Attachment sandboxing, email encryption, social media account protection, Advanced BEC Defense, and Email Warning Tags begin at Advanced. Archive support, search and eDiscovery, and data import and export are listed as Professional features. ## Proofpoint enterprise packages Proofpoint's [enterprise collaboration-security buying page](https://www.proofpoint.com/us/products/how-to-buy/collaboration-security) names Core, Tier 2, Tier 3, and Prime without attaching a public figure to any package. - Core: Email security. - Tier 2: Core capabilities plus account takeover protection. - Tier 3: Tier 2 capabilities plus human risk education and training. - Prime: Tier 3 capabilities plus impersonation protection, domain fraud and spoofing prevention, hosted DMARC, DKIM and SPF services, and lookalike domain detection. Proofpoint states that budgetary pricing can be determined by the number of user licences and the contract term, either single-year or multi-year, with exceptions based on consumption. That is the published cost-driver statement. It does not support calculating a per-user enterprise rate from the historical Essentials sheets. Proofpoint does not publish a minimum seat count or a discount ladder on that buying page. Both are commercial questions for the quote process. The page uses "Request a quote" and "Contact us" rather than self-serve checkout. - Best fit: An organization buying an enterprise email-security package through a Proofpoint sales process. - Relevant evidence: Proofpoint documents the package names, capability progression, and user-licence, term, and consumption factors for budgetary pricing. - Tradeoff: Public sources do not provide enterprise list prices, minimums, volume discounts, or a package-specific quote calculator. ## Proofpoint Email Fraud Defense for hosted DMARC services Proofpoint's [Email Fraud Defense product page](https://www.proofpoint.com/us/products/email-protection/email-fraud-defense) describes hosted SPF, hosted DKIM, and hosted DMARC as part of that product. It describes guided workflows and skilled consultants for DMARC deployment. This matters because hosted DMARC is not presented as a public standalone price. On the enterprise buying page, hosted DMARC, DKIM, and SPF services appear under Prime. A buyer who needs DMARC operations should ask whether Email Fraud Defense is separately quoted, included through Prime, or subject to another entitlement in the proposed order form. Proofpoint's [Hosted SPF technical overview](https://www.proofpoint.com/sites/default/files/product-overview/pfpt-us-to-hosted-spf.pdf) says the DNS service is available to Email Fraud Defense customers and directs pricing questions to an account manager. The document's technical claims do not create a published price or prove inclusion in another package. - Best fit: A Proofpoint buyer who requires hosted SPF, DKIM, and DMARC services within Proofpoint's product portfolio. - Relevant evidence: Proofpoint documents Email Fraud Defense as the product for hosted email-authentication services and lists those services under Prime on its enterprise buying page. - Tradeoff: The public sources do not publish a standalone Email Fraud Defense price, a hosted-DMARC rate, or the exact commercial entitlement for a proposed account. ## Palisade for DMARC automation Palisade is a fit for IT teams and MSPs that need an agentic DMARC software layer rather than inbound email filtering. Palisade autonomously analyzes DMARC aggregate-report data, identifies sending sources and authentication or alignment issues, and creates prioritized remediation tickets. It can propose the next DMARC policy step when the evidence supports it, while a human reviews the evidence and applies the change. This is a narrower product decision than enterprise email security. Palisade does not filter inbound email, change a receiver's reputation decision, or autonomously change the DMARC policy. Stronger authentication supports better deliverability, but it does not guarantee inbox placement. - Best fit: A team or MSP that wants an AI agent to do the DMARC work across one domain or many domains. - Relevant evidence: [Palisade's product documentation](https://docs.palisade.email/) describes its DMARC-focused operating model, including analysis of aggregate-report data and remediation workflow. - Tradeoff: Palisade is not the right product when the core requirement is inbound email filtering, account takeover protection, awareness training, or Proofpoint's wider enterprise security package. ## How to choose Choose Proofpoint's published Essentials evidence when you need dated historical MSRP for that small-business line. Choose a Proofpoint quote process when the requirement is an enterprise package, Proofpoint 365 Total Protection, or Email Fraud Defense. Choose Palisade when the requirement is recurring DMARC analysis and remediation workflow, while retaining another product for inbound filtering if that is also required. Use this checklist before accepting any quote: - Confirm the exact product name and whether it is a current offering or a historical Essentials package. - Confirm the billing unit, including active users, protected domains, archive data, or another consumption measure. - Ask which features require Advanced, Professional, Tier 2, Tier 3, Prime, or Email Fraud Defense. - Ask whether hosted DMARC, DKIM, and SPF are included, separately quoted, or excluded. - Ask for the contract term, renewal terms, regional currency, minimum commitment, and any consumption exceptions. - Keep historical list prices separate from the vendor's current written quote. ```yaml option: Proofpoint Essentials historical price sheets checked_on: 2026-08-12 best_fit: Dated small-business MSRP reference verified_evidence: - US sheet stamped 10/21 lists Business, Advanced, and Professional per-active-user monthly MSRP - EMEA sheet stamped 5/22 uses different regional figures and package structure open_question: Which current Proofpoint 365 Total Protection package and regional commercial terms apply --- option: Proofpoint enterprise packages checked_on: 2026-08-12 best_fit: Enterprise email-security procurement through a quote verified_evidence: - Core, Tier 2, Tier 3, and Prime are published package names - User licences, contract term, and some consumption exceptions affect budgetary pricing open_question: Package price, minimum commitment, discount structure, and final entitlement --- option: Palisade checked_on: 2026-08-12 best_fit: DMARC analysis and remediation workflow for IT teams and MSPs verified_evidence: - DMARC aggregate-report analysis and prioritized remediation tickets are documented - A human reviews evidence and applies DMARC policy changes open_question: Whether inbound email filtering or wider email-security controls are also required ``` ## Check the public email-security controls before comparing quotes Before treating a quoted DMARC or email-security package as the answer, inspect the domain's current public controls with the [Email Security Score](/tools/email-security-score). Compare the DNS result with the capabilities in the quote, especially if hosted SPF, DKIM, DMARC, archiving, or domain-fraud controls are part of the purchase discussion. [Check your domain's email-security controls](/tools/email-security-score) A public DNS scan cannot prove the production sending path, continuous configuration state, a receiver's private filtering decision, or future message placement. It also cannot confirm that a commercial package is licensed or configured for your account. ## Sources and further reading - [Proofpoint Essentials price list MSRP US](https://www.proofpoint.com/sites/default/files/data-sheets/pfpt-uk-ds-essentials-pricelist-msrp-us.pdf) - [Proofpoint Essentials monthly MSRP EMEA](https://www.proofpoint.com/sites/default/files/data-sheets/pfpt-uk-ds-essentials-price-list-monthly-msrp-emea.pdf) - [Proofpoint collaboration security buying options](https://www.proofpoint.com/us/products/how-to-buy/collaboration-security) - [Proofpoint 365 Total Protection](https://www.proofpoint.com/us/products/email-protection/essentials) - [Proofpoint Email Fraud Defense](https://www.proofpoint.com/us/products/email-protection/email-fraud-defense) - [Palisade documentation](https://docs.palisade.email/) ## Frequently asked questions ### Does Proofpoint publish pricing? Yes. Proofpoint publishes dated list-price sheets for its former Essentials line. Its enterprise buying page does not publish prices for Core, Tier 2, Tier 3, Prime, or Email Fraud Defense. ### How much did Proofpoint Essentials cost? The US Essentials sheet stamped October 2021 lists Business at $2.75, Advanced at $3.75, and Professional at $5.33 per active user per month. Those figures are historical published MSRP, not a current universal Proofpoint quote. ### Is Proofpoint 365 Total Protection the same as Proofpoint Essentials? No. Proofpoint markets Proofpoint 365 Total Protection as the current all-in-one Microsoft 365 suite for MSPs. Its live product page does not publish package names or prices, so confirm the current commercial mapping with Proofpoint. ### What drives Proofpoint enterprise cost? Proofpoint states that budgetary pricing depends on the number of user licences and contract term, whether single-year or multi-year, with some exceptions based on consumption. Public sources do not state an enterprise per-user rate, minimum seat count, or discount ladder. ### Is hosted DMARC included with Proofpoint? Only under a documented product or package entitlement. Proofpoint describes hosted DMARC, DKIM, and SPF through Email Fraud Defense, and its enterprise buying page lists those services under Prime. The public sources do not publish a standalone hosted-DMARC price. ### Can a public DNS check confirm a Proofpoint deployment? No. A public DNS check can inspect published records, but it cannot prove that the licensed Proofpoint service is configured, that the exact production sender uses it, or that a mailbox provider will deliver future messages. --- # Proofpoint vs Abnormal: gateway and API approaches compared Canonical: https://www.palisade.email/learning/proofpoint-vs-abnormal > Proofpoint vs Abnormal on documented terms: what an MX gateway sees, what an API deployment sees, what each needs to deploy, and how to choose. Proofpoint and Abnormal sit in different places in your mail path. Proofpoint can run as a secure email gateway, so mail reaches it before your mailbox provider and it can refuse a message at the edge. Abnormal connects to Microsoft 365 or Google Workspace through an API, reads mail the platform has already accepted, and measures each message against a behavioral baseline for the people involved. Neither approach wins in general. The right one depends on whether you can change MX and which attacks are getting through now. ## Quick takeaways - Proofpoint documents two deployment modes for one product, a secure email gateway or an API integration, and calls the API route the low touch rollout. - Abnormal documents one mode, a native API connection to Microsoft 365 or Google Workspace with no MX change, no agents and no proxies. - A gateway reads every message before the mailbox provider accepts it, which is why it can stop mail at the edge and why it needs a DNS change to get there. - An API product reads tenant signals a gateway cannot reach, and it pulls a bad message out of the mailbox instead of refusing it. - Neither vendor publishes a price for the product compared here, and neither maintains your DMARC record. ## Who this comparison is for This is for the IT admin or MSP technician with both names on a shortlist who wants to know what actually differs before the demos start. It also applies when you run one already and someone asks whether the other adds anything. ![Gateway and API approaches compared](/images/editorial/proofpoint-vs-abnormal/proofpoint-vs-abnormal-field.webp "1200x630") *Source: Palisade.* They compete for the same budget, so they get presented as alternatives. The sharper split is architectural: one can sit in the mail path, the other sits beside it. That changes what each can see, what each can do to a message, and what has to change in your environment first. For the wider category, see [email security software](/learning/email-security-software) and the [comparison hub](/compare). ## How the options were evaluated Every vendor claim below comes from the vendors' own product, buying and documentation pages, checked on 12 August 2026. Review aggregators were left out on purpose: neither side's detection quality can be verified from a web page. Five criteria carry the comparison. - Deployment: what changes in DNS or in the tenant before mail is inspected. - Visibility: which messages and which signals the product reads once it is live. - Disposition: what happens to a message the product decides is malicious. - Commercial evidence: what each vendor states about price on its own pages. - DMARC scope: whether domain authentication is included, sold separately, or absent. A capability counts as available only inside the scope the vendor states. Silence on a page is a question for the demo, not proof that something is missing. ## The gateway path: Proofpoint in the mail path A secure email gateway owns the MX record. Mail for your domain reaches the vendor first, and only what survives goes on to Microsoft or Google. A message refused at the edge never lands in a mailbox, so nobody gets a chance to click it. Proofpoint documents both paths for one product. Its [Core Email Protection page](https://www.proofpoint.com/us/products/threat-defense) lists flexible deployment via API or SEG, calls the API route a rapid, low touch rollout through the Microsoft Graph API, and presents the gateway route as the one with more protection and customization. Its [Email Protection page](https://www.proofpoint.com/us/products/email-security-and-protection/email-protection) offers the same choice and adds threat intelligence, machine learning and behavioral analysis on top of Microsoft 365 and Google Workspace, so deployment mode and detection method are independent decisions. Installing it costs you a DNS change with live mail behind it. Repointing MX is the moment mail flow depends on the new vendor, and backing out is another DNS change. A gateway cannot read what never crosses its path. Mail between two mailboxes in the same tenant stays inside the platform, which is the gap that matters once an internal account is compromised. Proofpoint's stated answer is post-delivery work: rescanning delivered mail with updated threat intelligence and machine learning models, then pulling a confirmed malicious message from all inboxes, including forwarded copies. Proofpoint's [buying page](https://www.proofpoint.com/us/products/how-to-buy/collaboration-security) names four enterprise packages, Core, Tier 2, Tier 3 and Prime, with no figure against any of them. Its only published list prices cover the Essentials line, and the two sheets disagree: a US sheet stamped 10/21 and an [EMEA sheet](https://www.proofpoint.com/sites/default/files/data-sheets/pfpt-uk-ds-essentials-price-list-monthly-msrp-emea.pdf) stamped 5/22 with a different package set and different currency columns. Both are dated records, not a rate card. ## The API path: Abnormal beside the mail platform Abnormal has one deployment model. Its [inbound email security page](https://abnormal.ai/products/inbound-email-security) states deployment in 60 seconds via API with no MX changes, and its [platform page](https://abnormal.ai/platform) states native API integrations with Microsoft 365, Google Workspace, Okta, CrowdStrike and Splunk, with no agents and no proxies. Installing it is an authorization inside the tenant, not a DNS change, so mail flow never depends on the vendor being reachable. That position buys a different field of view. Abnormal states it reads identity, behavioral and content signals per message, and names authentication events, calendar activity and internal threads as sources a gateway cannot access. Its stated method is a per identity baseline: a behavioral fingerprint for every employee and vendor, so a sender is measured against that person's own history rather than a population average. The attack class it names is payload free business email compromise, which passes every authentication check. Microsoft's documentation is a useful reference point for what behavioral detection means. It describes [implicit email authentication](https://learn.microsoft.com/en-us/defender-office-365/anti-phishing-protection-about) as adding sender reputation, sender history and behavioral analysis on top of SPF, DKIM and DMARC. Its [policy documentation](https://learn.microsoft.com/en-us/defender-office-365/anti-phishing-policies-about) then defines four phishing thresholds that set machine learning sensitivity, and states that false positives rise as the setting goes up. Every behavioral product makes that trade. The limit of the API position is timing. The product acts on mail the platform has already accepted, so its remedy is removal rather than refusal. Abnormal says threats are removed before users engage, and publishes a Search and Respond function that remediates in bulk. How wide that window runs is a trial question. Abnormal publishes no price, and its position that it plus native platform protection replaces a gateway is its own claim, with no published test behind it. The contrast does not map cleanly onto the two names, though. A buyer who cannot touch MX can deploy Proofpoint by API and land in the same position as Abnormal, including the loss of edge blocking. The gateway comes from one of these vendors; the API model comes from both. ## What neither approach fixes No detection layer, behavioral or otherwise, closes the lookalike domain and display name gap. Microsoft documents it plainly: an attacker who registers a lookalike domain and publishes valid records for it passes SPF, DKIM and DMARC while impersonating a trusted party. [RFC 9989 section 2.2](https://www.rfc-editor.org/rfc/rfc9989.html#section-2.2) agrees, placing visually similar domain names (cousin domains) and display name abuse outside DMARC's scope. DMARC covers exact domain spoofing, and that is the whole of it. That layer is also the one neither product operates for you. [DMARC](/learning/what-is-dmarc) lives in your DNS, and inbound filtering does not touch it. For Proofpoint it is a separate purchase, Email Fraud Defense, which the buying page places in the Prime package and whose [product page](https://www.proofpoint.com/us/products/email-protection/email-fraud-defense) describes hosted SPF, hosted DKIM and hosted DMARC with consultants guiding the rollout. Abnormal's pages describe no record management at all. Palisade works on that layer and no other. Its [documentation](https://docs.palisade.email/) covers DMARC, SPF, DKIM, BIMI and MTA-STS record management, aggregate report processing and sender classification, with no filtering, sandboxing or quarantine in it. The agent investigates every sender, drafts every fix and proposes each policy step, and you approve before anything ships. If the consultant led DMARC model is the part you are weighing, the [Proofpoint DMARC alternative](/proofpoint-dmarc-alternative) page covers it. ## How to choose Take the deployment constraint first, because it rules out more than any feature does. - If you can change MX, want mail refused before it reaches a mailbox, or need cover for mail that does not terminate in Microsoft 365 or Google Workspace, the gateway path fits, and Proofpoint is the one of these two that sells it. - If MX is frozen by another team, a migration or a managed platform contract, the API path is the only one open to you, and both vendors serve it. - If the losses you actually see are payload free impersonation of people your staff already trust, rather than malware and credential pages, weight the per identity behavioral model against your own recent misses. - If both describe you, run the API product beside the platform's built in filtering for a month and count what it catches that the platform missed. That is the only number here that comes from your tenant. Buy DMARC as its own line item either way, and settle two things first: whether hosted SPF, DKIM and DMARC sit inside the quoted package, and who owns the DNS changes. ## Sources and further reading - [Proofpoint Core Email Protection](https://www.proofpoint.com/us/products/threat-defense) - [Proofpoint Email Protection deployment options](https://www.proofpoint.com/us/products/email-security-and-protection/email-protection) - [Proofpoint Collaboration Security buying options](https://www.proofpoint.com/us/products/how-to-buy/collaboration-security) - [Proofpoint Essentials EMEA price list, stamped 5/22](https://www.proofpoint.com/sites/default/files/data-sheets/pfpt-uk-ds-essentials-price-list-monthly-msrp-emea.pdf) - [Proofpoint Email Fraud Defense](https://www.proofpoint.com/us/products/email-protection/email-fraud-defense) - [Abnormal inbound email security](https://abnormal.ai/products/inbound-email-security) - [Abnormal platform integrations](https://abnormal.ai/platform) - [Microsoft anti-phishing protection in Defender for Office 365](https://learn.microsoft.com/en-us/defender-office-365/anti-phishing-protection-about) - [Microsoft anti-phishing policies and thresholds](https://learn.microsoft.com/en-us/defender-office-365/anti-phishing-policies-about) - [RFC 9989, Domain-based Message Authentication, Reporting, and Conformance (DMARC)](https://www.rfc-editor.org/rfc/rfc9989.html) - [Palisade documentation](https://docs.palisade.email/) ## Frequently asked questions ### Is Abnormal a replacement for a secure email gateway? Not on evidence either vendor publishes. Abnormal states its own position that it plus Microsoft or Google native protection replaces a gateway, with no independent test behind it, and Proofpoint still sells the gateway as a supported deployment. ### Does Proofpoint require an MX record change? No. Proofpoint documents two deployment modes, a secure email gateway and an API integration through the Microsoft Graph API. Only the gateway mode needs MX pointed at the vendor, and the API mode gives up edge blocking. ### Can Abnormal stop a message before it is delivered? Not at the SMTP edge, because it is not in the mail path. It connects by API to a platform that has already accepted the message, so its remedy is removal, with Search and Respond for bulk remediation. ### Do Proofpoint or Abnormal publish list pricing? No. Abnormal publishes no price on its inbound or platform pages, and Proofpoint shows none for its four enterprise packages. Its only published list prices cover the Essentials line, in two sheets stamped 10/21 and 5/22 that disagree. ### Does either product manage my DMARC record? Only Proofpoint, and only through a separate product. Email Fraud Defense sits in the Prime package and offers hosted SPF, hosted DKIM and hosted DMARC with consultant guided rollout. Abnormal's pages describe no record management. --- # Proofpoint vs Barracuda: how the two compare Canonical: https://www.palisade.email/learning/proofpoint-vs-barracuda > Proofpoint vs Barracuda compared on their own published terms: deployment paths, tier structure, pricing disclosure, and where DMARC work sits. Proofpoint and Barracuda both sell inbound email protection for Microsoft 365 and Google Workspace, and both send buyers to a quote instead of a price. The differences that survive scrutiny are structural: how each product connects to your mail, what each tier adds as you climb it, and where DMARC work sits. Read the two on their own published terms, then decide on the constraint you cannot move in your own environment. ## Quick takeaways - Proofpoint sells one product with two deployment paths, API or secure email gateway, and states the tradeoff itself. - Barracuda leads with an API connection that needs no MX change, and sells its MX-routed gateway separately. - Neither publishes a usable price. Proofpoint's only list figures sit in two Essentials sheets stamped 10/21 and 5/22 that disagree, and Barracuda names three tiers with no figure. - The ladders climb differently. Proofpoint's four packages add security capability, while Barracuda's higher tiers add backup, archiving and training. - DMARC sits in different places: reporting across all three Barracuda tiers, and hosted SPF, DKIM and DMARC in Proofpoint's top Prime package. ## Who this comparison is for An IT team or MSP that has narrowed inbound email protection to these two vendors and wants to know what each publishes before booking a sales call. It assumes mailboxes on Microsoft 365 or Google Workspace, and somebody who will have to defend the quote. Neither product is a DMARC platform. If domain spoofing is what put these two on your list, start with [what DMARC is](/learning/what-is-dmarc), then read the narrower [Proofpoint DMARC alternative](/proofpoint-dmarc-alternative) and [Barracuda DMARC alternative](/barracuda-dmarc-alternative) pages. ## How the options were evaluated Every claim below was read on the vendor's own site or product documentation on August 12, 2026. Review sites and reseller listings were left out. Six criteria, fixed before the evidence was collected: - **Deployment model:** how mail reaches the product, and whether MX records change. - **Package structure:** what each tier contains, and what moves a buyer up. - **Pricing disclosure:** what figure the vendor publishes, and how old it is. - **Detection claims:** what each vendor says its product catches. - **DMARC placement:** which tier or product carries authentication work. - **Buying path:** how a buyer gets from the website to a number. Where a vendor's pages are silent, that is recorded as unknown. Silence is not evidence that a capability is missing. ## Deployment model - **Proofpoint:** the [Core Email Protection page](https://www.proofpoint.com/us/products/threat-defense) lists "Flexible Deployment via API or SEG" and sets out the tradeoff itself. It describes the API path as rapid deployment without MX changes with strong post-delivery detection, and the gateway path as fine-tuned pre-delivery filtering with rich DLP and policy customization. - **Barracuda:** the [Email Protection page](https://www.barracuda.com/products/email-protection) states that the product connects to Microsoft 365 or Google Workspace with no mail exchange (MX) changes, operational in minutes rather than weeks. Barracuda also sells Email Gateway Defense, whose [MX setup documentation](https://documentation.campus.barracuda.com/wiki/display/EGD/How+to+Manage+MX+Records+With+the+Setup+Wizard) has the administrator add Barracuda's records and remove the old ones, because "spammers will normally deliver mail to all MX records listed for a domain". - **What this means for you:** ask which path your quote assumes. An API connection touches no DNS. A gateway path costs a DNS change, a propagation wait and a cutover plan, so [confirm where your MX records point today](/tools/mx) before you scope it. ![Proofpoint and Barracuda on their own documented terms](/images/editorial/proofpoint-vs-barracuda/proofpoint-vs-barracuda-field.webp "1200x488") *Source: Palisade.* ## Package structure - **Proofpoint:** four packages on the [Collaboration Security buying page](https://www.proofpoint.com/us/products/how-to-buy/collaboration-security). Core is email security. Tier 2 adds account takeover protection and defense against compromised supplier accounts. Tier 3 adds risk-based education and threat-guided training. Prime adds impersonation protection, domain fraud and spoofing prevention, hosted DMARC, DKIM and SPF services, and lookalike domain detection. - **Barracuda:** three tiers on the [Email Protection plans page](https://www.barracuda.com/products/email-protection/plans). Advanced covers AI-powered detection and response, spam, malware and ransomware protection, phishing and BEC protection, account takeover protection, encryption and data loss prevention. Premium adds unlimited Microsoft 365 backup, point-in-time recovery and file scanning. Premium Plus adds cloud archiving, security awareness training and attack simulation. - **What this means for you:** the ladders are not the same shape, so tier names do not line up. Proofpoint's packages climb through security capability. Barracuda's climb past Advanced mostly buys data protection and training, so a team that already owns backup and archiving pays twice. ## Pricing disclosure - **Proofpoint:** the only list prices it publishes cover the Essentials line. The [US sheet](https://www.proofpoint.com/sites/default/files/data-sheets/pfpt-uk-ds-essentials-pricelist-msrp-us.pdf), stamped 10/21, quotes Business at $2.75, Advanced at $3.75 and Professional at $5.33 per active user per month. The [EMEA sheet](https://www.proofpoint.com/sites/default/files/data-sheets/pfpt-uk-ds-essentials-price-list-monthly-msrp-emea.pdf), stamped 5/22, adds a Beginner package and four currency columns, and its dollar figures do not match. Both are dated records for a small-business line now sold as 365 Total Protection, and the enterprise buying page carries no figure at all. - **Barracuda:** the plans page names Advanced, Premium and Premium Plus and compares features across them, with no figure anywhere. It routes the buyer to chat, phone or email. - **What this means for you:** neither product can be budgeted from a website. Proofpoint at least names the variables: budgetary pricing follows user licence count and contract term, single or multi-year, with exceptions for consumption. Barracuda publishes no equivalent. Normalize both quotes to the same seats, term and modules before comparing. ## Detection and response claims - **Proofpoint:** the Core Email Protection page says the product "blocks 99.999% of advanced email threats, including phishing attacks, BEC, ransomware, and beyond", and describes post-delivery remediation as pulling a confirmed malicious message from all inboxes, including forwarded copies. - **Barracuda:** the Email Protection page credits detection to Barracuda IQ, multi-model AI analyzing intent, identity behavior and content across more than 100 global threat feeds, with Bailey explainable AI stating a decision in plain language. Remediation is agentic clawback across all mailboxes in near real time. - **What this means for you:** neither claim is an independent test result, and the two are not measured the same way. Treat them as a list of things to test on your own mail during an evaluation. ## Where DMARC sits for each vendor - **Barracuda:** the plans page lists DMARC reporting in all three tiers. The [Domain Fraud Protection page](https://www.barracuda.com/products/email-protection/domain-fraud-protection) covers reporting, analysis and visibility into who sends email on your behalf, plus a mechanism to reject mail that does not come from your legitimate systems. It does not state that Barracuda publishes, hosts or changes your SPF, DKIM or DMARC records. - **Proofpoint:** the buying page places hosted DMARC, DKIM and SPF services in Prime, the top of four packages, sold as its own product, [Email Fraud Defense](https://www.proofpoint.com/us/products/email-protection/email-fraud-defense), which describes hosted record options, near-instant DNS updates, and consultants who guide the buyer through each step of the rollout. A separate [Hosted SPF brief](https://www.proofpoint.com/sites/default/files/product-overview/pfpt-us-to-hosted-spf.pdf) limits that service to Email Fraud Defense customers. - **What this means for you:** DMARC is an add-on decision on both sides rather than a line inside the filtering purchase. With Proofpoint it is a tier and a product, with consultants attached. With Barracuda the published boundary is reporting and analysis, leaving the record changes with you. ## The gap both products leave Both of these are inbound filtering products. They read mail arriving at your tenant and decide what happens to it. Neither one, as part of that purchase, keeps your own outbound authentication in order: inventorying the services that send as your domain, resolving their SPF and DKIM alignment failures, and publishing the DMARC record that carries the domain to enforcement. That gap is the layer Palisade automates. Palisade is DMARC software rather than a gateway, so it filters and quarantines nothing and replaces neither product. It parses aggregate reports, classifies the senders they reveal, hosts the DMARC, DKIM, BIMI and MTA-STS records by CNAME delegation, and runs an agent that drafts every fix and proposes each policy step for your team to approve. If your filtering decision is made but outbound authentication is still unresolved, [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=vendor_comparison&utm_content=proofpoint-vs-barracuda) and use the reports to see which senders need attention. ## How to choose No winner here holds across every buyer, so choose on the constraint you cannot move. - **If mail flow risk is binding** and you cannot schedule an MX cutover, both vendors have an answer: Barracuda's headline API connection, or Proofpoint's Microsoft Graph API path. Ask each which capabilities differ between their API and gateway versions. - **If pre-delivery control is binding**, meaning mail must stop before the tenant with fine-grained policy and DLP, Proofpoint documents the gateway as a supported deployment of the same product, and Barracuda's equivalent is a separate product. - **If the bundle is binding**, start from what you already own. Barracuda's higher tiers fold in backup, archiving and awareness training, which concentrates the spend for a team that has none of them and duplicates it for one that does. - **If DMARC enforcement is binding**, neither purchase finishes it. Price the authentication layer separately so the two decisions do not hide each other. If a third vendor belongs on the shortlist, the [comparison hub](/compare) covers the wider set. Then ask both the same questions: which tier the quote covers, which deployment path it assumes, and who maintains the DNS records. ## Sources and further reading - [Proofpoint Core Email Protection](https://www.proofpoint.com/us/products/threat-defense) - [Proofpoint Collaboration Security buying options](https://www.proofpoint.com/us/products/how-to-buy/collaboration-security) - [Proofpoint Essentials price list, stamped 10/21](https://www.proofpoint.com/sites/default/files/data-sheets/pfpt-uk-ds-essentials-pricelist-msrp-us.pdf) - [Proofpoint Essentials EMEA price list, stamped 5/22](https://www.proofpoint.com/sites/default/files/data-sheets/pfpt-uk-ds-essentials-price-list-monthly-msrp-emea.pdf) - [Proofpoint Email Fraud Defense](https://www.proofpoint.com/us/products/email-protection/email-fraud-defense) - [Proofpoint Hosted SPF technical brief](https://www.proofpoint.com/sites/default/files/product-overview/pfpt-us-to-hosted-spf.pdf) - [Barracuda Email Protection](https://www.barracuda.com/products/email-protection) - [Barracuda Email Protection plans](https://www.barracuda.com/products/email-protection/plans) - [Barracuda Domain Fraud Protection](https://www.barracuda.com/products/email-protection/domain-fraud-protection) - [Barracuda Email Gateway Defense MX record setup](https://documentation.campus.barracuda.com/wiki/display/EGD/How+to+Manage+MX+Records+With+the+Setup+Wizard) ![Choose between Proofpoint and Barracuda on the constraint you cannot move](/images/editorial/proofpoint-vs-barracuda/proofpoint-vs-barracuda-decision.webp "1200x530") *Source: Palisade.* ## Frequently asked questions ### Does either vendor publish a price for email protection? No. Barracuda's plans page names Advanced, Premium and Premium Plus with no figure, routing buyers to chat, phone or email. Proofpoint publishes list prices only for Essentials, in two sheets stamped 10/21 and 5/22 whose figures disagree, and nothing for its enterprise packages. ### Can Barracuda be deployed without changing MX records? Yes. Its Email Protection page states the product connects to Microsoft 365 or Google Workspace with no mail exchange changes. Barracuda also sells Email Gateway Defense, an MX-routed product whose documentation has the administrator add Barracuda's records, remove the old ones and wait for propagation. ### Is DMARC included when I buy either product? Not in the way most buyers assume. Barracuda lists DMARC reporting across all three tiers, described as reporting and analysis. Proofpoint places hosted SPF, DKIM and DMARC in its top Prime package, through Email Fraud Defense. Publishing the records and judging when a domain is safe to enforce stay separate work. ### Which one is better for a Microsoft 365 tenant? Both vendors document a Microsoft 365 path, so the answer comes from your constraint rather than the vendor. Proofpoint names a Microsoft Graph API integration for rapid deployment and keeps the gateway for finer pre-delivery policy. Barracuda leads with the API connection and sells its gateway separately. ### Can Palisade replace Proofpoint or Barracuda? No. Palisade does not filter, sandbox or quarantine inbound mail, and it is not a secure email gateway. It works on the authentication layer beside whichever filter you pick, parsing DMARC reports, classifying senders, hosting the records, and proposing each policy step for approval. --- # Proofpoint vs Mimecast: how the two compare Canonical: https://www.palisade.email/learning/proofpoint-vs-mimecast > Proofpoint vs Mimecast compared on their own documented terms: deployment, coverage, pricing transparency, and where DMARC sits for each vendor. Choose Proofpoint if your buying process values its published enterprise package structure and you may need its Prime package with Email Fraud Defense services. Choose Mimecast if its current threat-protection plans and its stated MX-based or API-based deployment options fit your mail environment. Neither vendor publishes enough first-party pricing to make a complete cost comparison, so the decision should turn on the quoted scope, DMARC needs, deployment path, and contract terms. ## Quick takeaways - Proofpoint publishes dated list pricing for its small-business Essentials line, but not for its enterprise packages. - Mimecast publishes plan families and plan names, but replaces list prices with sales-contact language. - Proofpoint says its enterprise budgetary pricing depends on user licences and contract term, with consumption-based exceptions. - Mimecast says its new customers buy the new email-security plans introduced on August 15, 2025. - DMARC is a separate path in both vendors' offerings, rather than a standard capability of every core mail-filtering package. - Palisade is a DMARC automation layer that works alongside an email gateway. It does not filter inbound mail. ## Who this comparison is for This comparison is for an IT team evaluating Proofpoint or Mimecast for email security, and trying to understand what each vendor publicly discloses before requesting a quote. It also applies when DMARC enforcement is part of the buying requirement rather than an unrelated future project. Proofpoint and Mimecast both sell secure email services, but their public materials organize products and pricing differently. That makes a direct price table misleading. The useful comparison is whether the quoted package covers the mail-security functions, DMARC work, deployment model, and commercial terms your team needs. If DMARC is the main decision, the related [Proofpoint DMARC alternative](/proofpoint-dmarc-alternative) and [Mimecast DMARC alternative](/mimecast-dmarc-alternative) pages cover that narrower operating question. For broader vendor evaluation, use the [Palisade comparison hub](/compare). ## How the options were evaluated The criteria below were checked against each vendor's own public product, pricing, and purchase pages on August 12, 2026. - Published commercial evidence: list prices, package names, pricing drivers, and whether the vendor directs buyers to sales. - Email-security scope: the vendor's stated primary email-protection products and proof points. - DMARC scope: whether DMARC appears in a standard package, an add-on, hosted service, or managed offering. - Deployment evidence: only deployment statements published by the relevant vendor. - Open questions: capabilities or commercial terms that public materials do not specify. A documented capability is treated as available only within the scope the vendor states. Missing public documentation is an open question, not evidence that a feature is unavailable. ![Decision flow for evaluating Proofpoint, Mimecast, and a separate DMARC automation layer](/images/editorial/proofpoint-vs-mimecast/proofpoint-vs-mimecast-decision-flow.webp "1200x676") *Source: Palisade.* ## Proofpoint - Best fit: Teams that want Proofpoint's published enterprise package structure and are prepared to obtain a quote based on licences, term, and required services. - Relevant evidence: Proofpoint's [Collaboration Security buying page](https://www.proofpoint.com/us/products/how-to-buy/collaboration-security) lists Core, Tier 2, Tier 3, and Prime packages. It describes Core as email security alone, while Prime adds impersonation protection, domain fraud and spoofing prevention, hosted DMARC, DKIM and SPF services, and lookalike-domain detection. The same page says budgetary pricing can be determined by the number of user licences and contract term, single-year or multi-year, with exceptions based on consumption. - Relevant evidence: Proofpoint's dated Essentials price list, stamped 10/21, lists Business at $2.75, Advanced at $3.75, and Professional at $5.33 per active user per month. That document is for the Essentials line and is not a current published enterprise rate. [Proofpoint Essentials MSRP price list](https://www.proofpoint.com/sites/default/files/data-sheets/pfpt-uk-ds-essentials-pricelist-msrp-us.pdf). - Relevant evidence: Proofpoint says [Email Protection](https://www.proofpoint.com/us/products/email-protection) stops 99.999% of email-security threats. This is a vendor claim and should not be compared as though it measures the same thing as Mimecast's customer count or analyst recognition. - Tradeoff: Public enterprise package prices are unavailable. A buyer must request a quote to assess the actual cost of Core, Tier, Prime, or attached services. For DMARC, Proofpoint positions Email Fraud Defense as the associated product path. Its solution brief, stamped 10/24, says the service includes Hosted SPF, Hosted DKIM, and Hosted DMARC; guided workflows and skilled consultants; DNS syntax validation; and import of existing DMARC records. It also says the service can overcome the SPF DNS lookup limit. See the [Proofpoint Email Fraud Defense solution brief](https://www.proofpoint.com/sites/default/files/data-sheets/pfpt-us-ds-efd360.pdf). This is a specific DMARC model: hosted records plus a consultant-led rollout. Confirm in a quote whether the proposed package includes Email Fraud Defense, which hosted services apply, who owns DNS changes, and what work remains with your team. ## Mimecast - Best fit: Teams that want to evaluate Mimecast's current threat-protection plan family and its documented MX-based or API-based deployment choices. - Relevant evidence: Mimecast's [plans page](https://www.mimecast.com/products/mimecast-plans/) lists Critical, Advanced, and Premium for threat protection; Professional, Enterprise, and Gov for insider risk management; and Core and Pro for security behaviour management. The page uses "Contact for pricing", "Custom pricing available", or "Custom options available" rather than published list prices. - Relevant evidence: Mimecast says new customers must buy its new email-security plans as of August 15, 2025. It says existing purchases continue unchanged, and warns that migration can carry an additional cost under standard price-increase terms. The page also says customers must sign a one-page legal agreement about AI use in Mimecast products. - Relevant evidence: Mimecast's [Integrated Cloud Email Security page](https://www.mimecast.com/products/email-security/integrated-cloud-email-security/) says MX-based deployment routes all inbound mail through its gateway first. It says API-based deployment connects in minutes without MX record changes or mail-flow disruption. These are Mimecast deployment statements, not a comparison claim about Proofpoint. - Relevant evidence: Mimecast says it was named a Leader in the 2025 Gartner Magic Quadrant for Email Security and protects more than 42,000 organisations. Those are vendor-published claims with different measures than Proofpoint's threat-stopping claim. - Tradeoff: Mimecast does not publish list prices or a public formula for the cost drivers behind a final quote. Buyers need to establish which plan families and add-ons are included. Mimecast's DMARC Analyzer documents aggregate, forensic, and TLS report overviews, SPF delegation, a DMARC record generator, record checkers, deployment workflows, setup wizards, and a recommendation engine for self-service. Its [DMARC Analyzer product page](https://www.mimecast.com/products/dmarc-analyzer/) describes a fully managed deployment option as an additional fee. The public materials checked do not state that Mimecast hosts or changes a customer's DMARC, SPF, or DKIM DNS records. Mimecast's service matrix states that DMARC visibility and reporting is standard in one plan and available for an additional fee in four others. Confirm the exact plan, reporting scope, managed-deployment fee, and DNS responsibilities before treating DMARC as included in the gateway purchase. ## Palisade for DMARC automation alongside either gateway - Best fit: IT teams and MSPs that choose Proofpoint or Mimecast for email filtering, but want an agentic DMARC software layer to analyze reports and organize the work required for DMARC enforcement. - Relevant evidence: [Palisade pricing](https://www.palisade.email/pricing) describes plans for one-domain use, IT teams, MSPs, and enterprise deployments. The page lists DMARC report parsing and sender classification, hosted DMARC and SPF, MTA-STS hosting, and SPF flattening. - Relevant evidence: Palisade's [product documentation](https://docs.palisade.email/) describes an AI agent that analyzes DMARC aggregate-report data, identifies sending sources and authentication or alignment issues, creates prioritized remediation tickets, and proposes the next policy step for human review. - Tradeoff: Palisade does not filter inbound email. It is not an alternative to Proofpoint or Mimecast's secure email gateway. A human reviews the evidence and applies any DNS or DMARC policy change. The practical fit is separate rather than competitive. Use a gateway to filter mail according to the selected vendor's architecture. Use a DMARC operating layer when the remaining task is inventorying production senders, resolving alignment issues, and deciding when evidence supports moving the DMARC policy forward. ## How to choose Start with the gateway requirement, then isolate DMARC as its own buying line item. Proofpoint fits a team that wants its stated package path and can evaluate a licence-and-term quote. Mimecast fits a team that needs its stated plan-family structure or prefers to evaluate its MX-based and API-based deployment models. Palisade fits when DMARC work needs a separate automation layer alongside the chosen gateway. Before buying, ask each vendor: - Which named package and add-ons are included in the quote? - Is DMARC reporting standard, separately priced, or attached through another product? - Who publishes, validates, and changes DMARC, SPF, and DKIM DNS records? - What deployment method will carry production mail, and what validation is required before cutover? - Which licence, contract-term, consumption, migration, or managed-service assumptions drive cost? - What evidence will show that real production mail authenticates after deployment? ```yaml option: Proofpoint checked_on: 2026-08-12 best_fit: "Enterprise buyers evaluating Core through Prime and Email Fraud Defense services." verified_evidence: - "Core, Tier 2, Tier 3, and Prime package structure is published." - "Budgetary pricing is tied to user licences and contract term, with consumption exceptions." - "Essentials has a dated 10/21 MSRP sheet, not enterprise list pricing." open_question: "Quoted enterprise price and the exact services included for this deployment." ``` ```yaml option: Mimecast checked_on: 2026-08-12 best_fit: "Teams evaluating current threat-protection plans and MX-based or API-based deployment." verified_evidence: - "Critical, Advanced, and Premium threat-protection plans are published." - "Public pages use custom-pricing and contact-sales language." - "DMARC visibility and reporting varies by plan and can require an additional fee." open_question: "Quoted pricing, included plan families, and managed-deployment cost." ``` ```yaml option: Palisade checked_on: 2026-08-12 best_fit: "Teams that need DMARC automation alongside a selected secure email gateway." verified_evidence: - "Palisade analyzes DMARC aggregate reports and identifies authentication or alignment issues." - "Palisade proposes the next DMARC policy step for human review." - "Palisade provides hosted DMARC and SPF capabilities." open_question: "Whether the team's gateway, DNS ownership model, and approval process fit the rollout." ``` ## Check the public email-security baseline before requesting quotes If you already have a domain in scope, run it through the [Email Security Score](/tools/email-security-score) before comparing proposals. The result can help you record the public DMARC, SPF, DKIM, BIMI, MX, MTA-STS, and TLS-RPT state that a vendor quote needs to address. ![How to break the tie between Proofpoint and Mimecast using your unsolved problem](/images/editorial/proofpoint-vs-mimecast/proofpoint-vs-mimecast-decision.webp "1200x600") *Source: Palisade.* A public DNS check does not prove which production senders use the domain, whether a gateway is filtering live traffic, a receiver's private reputation decision, or future inbox placement. Compare the scan with a real delivered message's authentication results and later with DMARC aggregate-report evidence. ## Sources and further reading - [Proofpoint Collaboration Security buying options](https://www.proofpoint.com/us/products/how-to-buy/collaboration-security) - [Proofpoint Essentials MSRP price list, stamped 10/21](https://www.proofpoint.com/sites/default/files/data-sheets/pfpt-uk-ds-essentials-pricelist-msrp-us.pdf) - [Proofpoint Email Fraud Defense solution brief, stamped 10/24](https://www.proofpoint.com/sites/default/files/data-sheets/pfpt-us-ds-efd360.pdf) - [Mimecast plans and pricing contact options](https://www.mimecast.com/products/mimecast-plans/) - [Mimecast Integrated Cloud Email Security deployment options](https://www.mimecast.com/products/email-security/integrated-cloud-email-security/) - [Mimecast DMARC Analyzer](https://www.mimecast.com/products/dmarc-analyzer/) ## Frequently asked questions ### Does Proofpoint publish enterprise pricing? No. Proofpoint publishes a dated list-price document for its Essentials small-business line, but its enterprise Collaboration Security packages direct buyers to request a quote. Proofpoint says budgetary pricing depends on user licences and contract term, with consumption-based exceptions. ### Does Mimecast publish list pricing? No. Mimecast's plans page lists product families and uses "Contact for pricing", "Custom pricing available", and "Custom options available" instead of a public list price. A buyer needs a quote to compare actual commercial terms. ### Is DMARC included with Proofpoint and Mimecast email security? Not across every core package. Proofpoint places hosted DMARC, DKIM, and SPF services in its Prime package through Email Fraud Defense. Mimecast's service matrix indicates that DMARC visibility and reporting is standard in one plan and available at an additional fee in others. Confirm the precise quoted scope. ### Should an API-based Mimecast deployment avoid all validation work? No. Mimecast says API-based deployment requires no MX record changes and no mail-flow disruption, but that does not prove a particular production configuration is correct. Validate DNS where applicable, the vendor's status, a real delivered message's authentication results, and DMARC aggregate reports once data accumulates. ### Can Palisade replace Proofpoint or Mimecast email filtering? No. Palisade does not filter inbound mail and is not a secure email gateway. It can operate alongside either vendor to analyze DMARC reports, identify authentication and alignment issues, and propose a next policy step for human approval. --- # RFC 5321.MailFrom vs RFC 5322.From: what's the difference? Canonical: https://www.palisade.email/learning/rfc5321-mailfrom-vs-rfc5322-from > RFC 5321.MailFrom vs RFC 5322.From: learn how SMTP envelope and visible header identities differ, how SPF checks them, and how DMARC alignment works. RFC 5321.MailFrom is the SMTP envelope sender, also called the reverse path. RFC 5322.From is the message-header author address that recipients usually see. SPF can authenticate the MailFrom domain, while DMARC evaluates whether a passing SPF or DKIM identity aligns with the visible RFC 5322.From domain. The addresses may differ, but a difference can leave SPF unaligned for DMARC. ## Quick takeaways - RFC 5321 `MAIL FROM` is supplied during the SMTP transaction before message content is sent. - RFC 5322 `From` is an originator field in the message header. - The SMTP reverse path is commonly recorded as `Return-Path` after final delivery. - SPF evaluates an SMTP identity, commonly `smtp.mailfrom`. - DMARC uses the RFC 5322.From domain as its Author Domain. - A passing SPF result does not satisfy DMARC unless its authenticated domain aligns with the visible From domain. ## Who is affected? This distinction affects domain administrators, ESP operators, and MSP technicians who troubleshoot SPF, DKIM, DMARC, bounces, or third-party sending platforms. It matters whenever an application sends mail using a provider-owned return path while the message displays an organization-owned From address. The identities have separate jobs. The RFC 5321 reverse path tells SMTP systems where delivery errors can be reported. The [RFC 5322 From field](https://www.rfc-editor.org/rfc/rfc5322.html#section-3.6.2) identifies the author or authors responsible for the message content. A sender can use different domains for those roles without violating either standard. The exception is a null reverse path, written as `MAIL FROM:<>`. [RFC 5321 section 4.5.5](https://www.rfc-editor.org/rfc/rfc5321.html#section-4.5.5) requires mail delivery notification messages to use it to reduce the risk of loops. A null reverse path has no domain that SPF can align to, so DMARC may instead rely on aligned DKIM. For broader protocol context, see Palisade's [email authentication learning center](/learning). ## What are the requirements? ### RFC 5321 defines the SMTP reverse path [RFC 5321 section 4.1.1.2](https://www.rfc-editor.org/rfc/rfc5321.html#section-4.1.1.2) defines the `MAIL` command and its `FROM` parameter. The reverse path identifies the source mailbox used for reporting errors related to the transaction. It is part of the SMTP envelope, not part of the message header that a recipient reads. This is an illustrative SMTP and message-header shape: ```text MAIL FROM:<bounces@mailer.yourdomain.com> RCPT TO:<recipient@example.net> From: Product updates <news@yourdomain.com> To: Recipient <recipient@example.net> Subject: August update ``` The address after `MAIL FROM:` can differ from the address in `From:`. The SMTP server processes the envelope commands before it accepts the message fields after `DATA`. ### RFC 5322 defines the visible author field [RFC 5322 section 3.6.2](https://www.rfc-editor.org/rfc/rfc5322.html#section-3.6.2) defines `From` as an originator field that specifies the author or authors responsible for writing the message. The field is required in an RFC 5322 message. `From:` does not direct delivery-status notifications. It describes the message's author identity. If a message has more than one address in `From:`, RFC 5322 requires a `Sender:` field that identifies the agent that actually transmitted the message. RFC 5322 remains the controlling Internet Message Format specification for these fields. [RFC 6854](https://www.rfc-editor.org/rfc/rfc6854.html) updates RFC 5322's originator-field rules to permit multiple addresses in `From` under defined conditions. ### DMARC compares authenticated domains to RFC 5322.From [RFC 9989](https://www.rfc-editor.org/rfc/rfc9989.html) defines the RFC 5322.From domain as the DMARC Author Domain. DMARC passes when at least one aligned authentication mechanism passes: SPF with an aligned RFC 5321.MailFrom domain, or DKIM with an aligned signing domain. A message can therefore have all of these results at once: - SPF passes for `mailer.vendor.example`. - The visible `From:` address uses `yourdomain.com`. - SPF does not align because `mailer.vendor.example` is unrelated to `yourdomain.com`. - DKIM can still satisfy DMARC if its passing `d=` domain aligns with `yourdomain.com`. Relaxed alignment permits the organizational-domain relationship defined by DMARC. Strict alignment requires the domains to be identical. Do not assume a provider-owned custom return path is aligned because it contains a recognizable brand label. Compare the actual domains in a delivered message. ![Decision flow showing how RFC 5321.MailFrom and RFC 5322.From can produce SPF alignment or require aligned DKIM for DMARC](/images/editorial/rfc5321-mailfrom-vs-rfc5322-from/rfc5321-mailfrom-vs-rfc5322-from-identity-flow.webp "1200x829") *Source: Palisade.* ### Authentication results report the identities used [RFC 8601](https://www.rfc-editor.org/rfc/rfc8601.html) defines the `Authentication-Results` header field used by receivers to report authentication assessments. Its registered properties include `smtp.mailfrom`, `smtp.helo`, `header.from`, and `header.d`. A typical delivered-message result can look like this: ```text Authentication-Results: mx.example.net; spf=pass smtp.mailfrom=bounces@mailer.yourdomain.com; dkim=pass header.d=yourdomain.com; dmarc=pass header.from=yourdomain.com ``` The exact wording and fields vary by receiver. Treat a receiver's header as evidence of that receiver's evaluation, not a universal statement about every mailbox provider. ## When does the requirement take effect? There is no rollout date or sender-volume threshold for the distinction itself. RFC 5321 and RFC 5322 were published as Draft Standards in October 2008, and their field roles apply whenever SMTP transports an RFC 5322 message. RFC 6854, published in March 2013, updates RFC 5322's handling of multiple originators. RFC 9989 was published in May 2026 and defines the current DMARC specification. It obsoletes RFC 7489. DMARC evaluation happens when a receiver evaluates an individual message, subject to that receiver's implementation and local policy. A DNS or sender-platform change can affect the next message immediately after the relevant systems use the new configuration. DNS propagation and cached records can delay what different receivers observe. A passing configuration screen is useful, but it does not prove that the production message used the expected reverse path or DKIM domain. ## How do I implement the requirement? ### 1. Choose the visible RFC 5322.From domain Use a `From:` domain that represents the organization or service the recipient expects. Make the visible address part of the sending-domain design, because DMARC uses its domain as the Author Domain. ### 2. Identify each platform's RFC 5321.MailFrom domain For every application, ESP, and transactional sender, find the domain used in its SMTP envelope. A provider may call this a return path, bounce domain, envelope sender, or custom MAIL FROM domain. Do not copy another tenant's DNS values. The sending provider generates the selectors, CNAME targets, and verification values for its own account. ### 3. Publish authentication for the production path Publish SPF for the domain the actual sending infrastructure uses. Configure DKIM using the values generated by the sending platform. If the MailFrom domain cannot align with the visible From domain, configure an aligned DKIM signing domain before relying on DMARC. > Changing a return path can change bounce handling. Confirm that the selected destination can process delivery-status notifications before replacing an existing production setting. ### 4. Preserve null reverse-path behavior Do not replace `MAIL FROM:<>` on delivery-status notifications with an ordinary sender address. RFC 5321 uses the null reverse path to avoid notification loops. Ensure those messages have an appropriate DKIM path if DMARC evaluation matters for them. ## How do I validate compliance? Start with DNS. Confirm the published SPF and DKIM records through the authoritative DNS provider and at least one public resolver. A public [Email Security Score](/tools/email-security-score) can inspect public authentication configuration for a domain. You can also use Palisade's [DMARC checker](/tools/dmarc) to review the published DMARC record. Then validate the vendor layer. Check that each sending platform reports its domain authentication or custom return-path setup as verified. This confirms the platform accepted the configuration. It does not confirm that a production message used it. Next, send a real message through each exact production path and inspect the delivered raw headers. Compare: - `Return-Path`, if the receiving system added it, with the expected reverse path. - `From:` with the intended visible author domain. - `spf=` and `smtp.mailfrom=` in `Authentication-Results`. - `dkim=` and `header.d=`. - `dmarc=` and `header.from=`. Finally, review DMARC aggregate reports after enough mail has flowed to identify which sending sources authenticate and align. This message-level and report-level evidence is the proof that matters for operational DMARC decisions. ## Check the public authentication posture before reviewing reports A delivered message may show that one platform used the intended identities, but it does not inventory every sender using the domain. Start with Palisade's [Email Security Score](/tools/email-security-score) to inspect the public SPF, DKIM, and DMARC posture before comparing it with headers and aggregate-report evidence. [Check your domain's email security score](/tools/email-security-score) A public DNS check cannot prove the production sending path, a receiver's private decision, continuous state, or future inbox placement. For teams with multiple senders or domains, [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=email_authentication&utm_content=rfc5321-mailfrom-vs-rfc5322-from). Palisade autonomously analyzes DMARC aggregate-report data, identifies sending sources and alignment issues, and creates prioritized remediation tickets. It proposes the next policy step from the evidence, while a human reviews the evidence and applies any change. Palisade does not change DMARC policy automatically or guarantee that every future message will authenticate. ## Sources and further reading - [RFC 5321: Simple Mail Transfer Protocol](https://www.rfc-editor.org/rfc/rfc5321.html) - [RFC 5322: Internet Message Format](https://www.rfc-editor.org/rfc/rfc5322.html) - [RFC 9989: Domain-based Message Authentication, Reporting, and Conformance](https://www.rfc-editor.org/rfc/rfc9989.html) - [RFC 8601: Authentication-Results header field](https://www.rfc-editor.org/rfc/rfc8601.html) - [RFC 6854: Update to Internet Message Format](https://www.rfc-editor.org/rfc/rfc6854.html) ## Frequently asked questions ### Is Return-Path the same as From? No. `Return-Path` records the SMTP reverse path after delivery, while `From:` identifies the message author. [RFC 5321](https://www.rfc-editor.org/rfc/rfc5321.html) defines the SMTP reverse path and [RFC 5322](https://www.rfc-editor.org/rfc/rfc5322.html#section-3.6.2) defines the From field. ### Which address does SPF check? SPF commonly evaluates the RFC 5321.MailFrom domain. When the reverse path is null, SPF can use the SMTP HELO identity instead. DMARC alignment depends on the authenticated identity reported for the message. ### Which address does DMARC protect? DMARC uses the domain in RFC 5322.From as the Author Domain. A passing SPF MailFrom domain or DKIM signing domain must align with that domain for the relevant mechanism to satisfy DMARC. [RFC 9989](https://www.rfc-editor.org/rfc/rfc9989.html) defines this comparison. ### Can RFC 5321.MailFrom and RFC 5322.From use different domains? Yes. Different domains are valid for SMTP and message formatting. For DMARC, a different MailFrom domain means SPF may pass without aligning, so an aligned DKIM signature can become the mechanism that passes DMARC. ### Does a passing SPF result mean DMARC passes? No. SPF must both pass and align with the RFC 5322.From Author Domain to satisfy DMARC through SPF. A passing aligned DKIM result can independently satisfy DMARC. --- # SendGrid one-click unsubscribe: headers, subscription tracking, and validation Canonical: https://www.palisade.email/learning/sendgrid-one-click-unsubscribe > Configure or verify SendGrid one-click unsubscribe with Subscription Tracking or custom headers, then inspect a delivered message. SendGrid can add one-click unsubscribe to marketing email in two ways. Enable Subscription Tracking and SendGrid automatically adds `List-Unsubscribe` plus `List-Unsubscribe-Post: List-Unsubscribe=One-Click`; or supply the headers when sending through its API or SMTP path. Send a real test and inspect its raw headers. A valid pair does not guarantee that a mailbox provider will show its Unsubscribe control. ## Quick takeaways - [SendGrid Subscription Tracking](https://www.twilio.com/docs/sendgrid/ui/sending-email/list-unsubscribe) automatically inserts the HTTPS `List-Unsubscribe` header and the one-click post header into text and HTML mail. - SendGrid also documents manual `List-Unsubscribe` and `List-Unsubscribe-Post` headers for Mail Send and SMTP. - A visible unsubscribe link in the message body remains separate from the headers. - [RFC 8058](https://www.rfc-editor.org/rfc/rfc8058.html) requires an HTTPS URI, the exact post value, and valid DKIM coverage for its one-click mechanism. - Raw delivered headers prove what the sending path emitted. They do not prove that a mailbox will render its own control or that an opt-out endpoint processed a recipient. ## Who is affected? This page is for an operator sending marketing or subscribed mail through Twilio SendGrid. It covers the header pair and SendGrid's documented ways to produce it. It does not configure a recipient mailbox, replace consent management, or cover SendGrid Domain Authentication. For the latter, use the separate guide to [SPF and DKIM for SendGrid](/learning/how-do-i-set-up-spf-and-dkim-for-sendgrid). `List-Unsubscribe` is an email header. A mailbox may use it to offer an unsubscribe action near the sender. The visible link inside the message body is a different element. SendGrid says its list-unsubscribe header does not replace the standard unsubscribe functionality in the email body, and Subscription Tracking can place an `[unsubscribe]` substitution tag in that body. See the [SendGrid List-Unsubscribe documentation](https://www.twilio.com/docs/sendgrid/ui/sending-email/list-unsubscribe) for its feature behavior. For the vendor-neutral protocol details, including endpoint handling and DKIM requirements, read [our RFC 8058 one-click unsubscribe explainer](/learning/one-click-unsubscribe). This SendGrid page stays focused on the configuration choice and the evidence to inspect. ## What are the requirements? ### SendGrid Subscription Tracking adds the pair When Subscription Tracking is enabled, SendGrid documents that it inserts `List-Unsubscribe` with an HTTPS unsubscribe link and `List-Unsubscribe-Post` with `List-Unsubscribe=One-Click` into text and HTML email. The same source says that the body link can be positioned with the `[unsubscribe]` substitution tag. That is the simpler path when SendGrid's subscription-tracking behavior matches how your sending program manages opt-outs. ### Manual headers remain a separate sending path SendGrid also documents manual headers for v3 Mail Send, v2 Mail Send, and SMTP. This can be useful when you do not use Subscription Tracking, but it makes the owner of the endpoint and unsubscribe processing responsible for the full behavior. Its examples show both the post header and a `List-Unsubscribe` field with `mailto:` and HTTPS values. Do not copy the documentation's example address or URL into production. Use values and an endpoint that belong to your own unsubscribe workflow. ```text List-Unsubscribe: <https://unsubscribe.example.invalid/request/<recipient-token>> List-Unsubscribe-Post: List-Unsubscribe=One-Click ``` The example is illustrative only. RFC 8058 says the `List-Unsubscribe` field **MUST** contain one HTTPS URI, **MAY** contain non-HTTP/S URIs such as `mailto:`, and the post field **MUST** contain the single value shown above. It also requires a valid DKIM signature that covers both fields. Read [RFC 8058 section 3.1 and section 4](https://www.rfc-editor.org/rfc/rfc8058.html) before implementing a self-managed endpoint. ![Flow from SendGrid Subscription Tracking or manual headers to raw delivered-header inspection, with mailbox display provider-controlled.](/images/editorial/sendgrid-one-click-unsubscribe/sendgrid-one-click-unsubscribe-decision-flow.svg "1200x614") *Source: Original Palisade decision flow based on [Twilio SendGrid's List-Unsubscribe documentation](https://www.twilio.com/docs/sendgrid/ui/sending-email/list-unsubscribe) and [RFC 8058](https://www.rfc-editor.org/rfc/rfc8058.html). It distinguishes configuration and evidence boundaries; it is not a SendGrid or mailbox interface.* ### A valid header pair does not control mailbox display Twilio notes that developers may not see a one-click unsubscribe button even after implementing the headers correctly. Mailbox providers decide which messages show their control. Treat that as a presentation decision outside SendGrid's configuration. The reliable first check is the emitted header pair, followed by a safe, real opt-out test in a non-production recipient or test list. Google's [subscription guidelines](https://support.google.com/mail/answer/15263077) say that bulk senders must support one-click unsubscribe for marketing and subscribed messages, and that unsubscribe requests should be processed within 48 hours. Those guidelines establish recipient-provider scope; they do not promise display for every individual message. For the complete Gmail and Yahoo context, use the [bulk sender requirements checklist](/learning/google-is-making-email-sender-requirements-stricter-starting-nov-2025). ## When does the requirement take effect? RFC 8058 is an IETF Standards Track document published in January 2017. Its rules are stable protocol requirements, but a mailbox provider's sender policy and control-display logic can change. This SendGrid behavior and Google's subscription guidance were checked on July 29, 2026. Recheck the vendor and provider documentation when changing a campaign workflow or investigating a provider warning. ## How do I implement the requirement? ### 1. Choose the configuration owner Choose Subscription Tracking when SendGrid should insert the headers and handle the associated subscription-tracking workflow. Choose manual headers only when your application or another system owns the HTTPS endpoint and the opt-out process. This is an operational choice, not an RFC requirement to use a particular SendGrid feature. ### 2. Preserve the body unsubscribe route Keep a visible unsubscribe route in the message body. If you use Subscription Tracking, SendGrid documents the `[unsubscribe]` substitution tag for controlling where its body link appears. If you supply manual headers, ensure your message template and consent workflow still provide the required body experience for the providers and jurisdictions relevant to you. ### 3. Send a test through the production-equivalent path Send a test through the same SendGrid path used in production: the marketing workflow, API integration, or SMTP relay. A test from another application or a different SendGrid account can confirm only that other path. Do not test a live recipient's opt-out flow without authorization. ## How do I validate compliance? ### 1. Inspect the raw delivered message Open the raw source of the message and look for both headers. Confirm that `List-Unsubscribe` includes the expected HTTPS URI and that `List-Unsubscribe-Post` exactly contains `List-Unsubscribe=One-Click`. If you control DKIM signing, also confirm that the signature covers both header fields as RFC 8058 requires. A [delivered-message header analyzer](/tools/email-header-analyzer) can help inspect authentication evidence, but raw header review remains necessary for the list-unsubscribe pair. ### 2. Match the result to the chosen SendGrid path For Subscription Tracking, the header pair should be present on the text and HTML message SendGrid sends. For manual headers, compare the delivered values with the headers your API or SMTP code supplied. A mismatch points to the actual sending path or message construction, not to a generic DNS problem. ### 3. Test the endpoint without assuming mailbox UI behavior Use a controlled test recipient or test list to verify that an opt-out reaches the appropriate suppression or subscription system. The header pair alone cannot prove that the endpoint processed a recipient. Conversely, an absent mailbox control does not, by itself, prove SendGrid omitted the headers because the mailbox provider controls that display. ## Review the rest of your sender requirements After confirming the headers, compare the same sending program against the [Gmail and Yahoo sender-requirements checklist](/learning/google-is-making-email-sender-requirements-stricter-starting-nov-2025). That checklist covers the surrounding bulk-sender requirements. It cannot inspect private SendGrid headers, trigger the unsubscribe endpoint, or prove a provider's display decision. [Review the bulk sender requirements](/learning/google-is-making-email-sender-requirements-stricter-starting-nov-2025) ## Sources and further reading - [Twilio SendGrid: List-Unsubscribe](https://www.twilio.com/docs/sendgrid/ui/sending-email/list-unsubscribe) - [RFC 8058: Signaling One-Click Functionality for List Email Headers](https://www.rfc-editor.org/rfc/rfc8058.html) - [Google: Email subscription guidelines](https://support.google.com/mail/answer/15263077) ## Frequently asked questions ### Does SendGrid Subscription Tracking add one-click unsubscribe headers? Yes. SendGrid documents that Subscription Tracking inserts both `List-Unsubscribe` with an HTTPS link and `List-Unsubscribe-Post: List-Unsubscribe=One-Click` into text and HTML email. ### Can I use custom headers instead of Subscription Tracking? Yes. SendGrid documents List-Unsubscribe headers for its Mail Send and SMTP paths. You must operate the endpoint and process the resulting opt-out requests correctly. ### Does a List-Unsubscribe header replace the visible unsubscribe link? No. SendGrid says its list-unsubscribe header does not replace standard unsubscribe functionality in the message body. Keep the body experience separate from the header mechanism. ### Why is the Gmail Unsubscribe control missing from my test? Mailbox providers decide whether to display their controls. Check the raw message for both headers before treating a missing control as a SendGrid configuration failure. ### Must the one-click endpoint accept a POST request? Yes. RFC 8058 defines the one-click action as an HTTPS POST to the HTTPS URI in `List-Unsubscribe`; it prohibits cookies, HTTP authorization, and HTTPS redirects for that POST flow. --- # What does SMTP connection refused mean? Canonical: https://www.palisade.email/learning/smtp-connection-refused > SMTP connection refused means a TCP connection was rejected before SMTP began. Diagnose the endpoint, listener, firewall, DNS, and retry path. SMTP connection refused means the sending system reached an IP address, but that host rejected the TCP connection before an SMTP session began. There is no SMTP `220` banner and no SMTP reply code yet. Check the selected MX host, resolved IP address, TCP port, receiving listener, and network controls from the same path as the affected sender before changing SPF, DKIM, or DMARC. ## Quick takeaways - SMTP connection refused is a TCP-layer result that occurs before SMTP commands or message authentication. - A timeout, a reachable `220` banner, and a later SMTP `4xx` or `5xx` response are different failures with different evidence. - Server-to-server SMTP delivery normally connects to the recipient MX host on TCP port `25`. - Test every current MX target and each advertised IPv4 or IPv6 address from the affected sending network. - A public MX lookup can identify published destinations, but it cannot prove a production sender's route or a recipient's private filtering decision. - SPF, DKIM, and DMARC do not open a closed listener or permit a blocked TCP connection. ## What does the failure mean? A TCP refusal means the connection attempt was actively rejected before the receiving host opened an SMTP conversation. [RFC 9293 describes TCP reset behavior](https://www.rfc-editor.org/rfc/rfc9293.html) for connection attempts that do not match an accepting connection state. The operating system or mail software may report that result as `connection refused`. This illustrative redacted connection-log fragment shows the evidence pattern: ```text 2026-08-12T09:14:27-04:00 smtp-client[12345]: connect to mx1.recipient.example[192.0.2.25]:25: Connection refused ``` The fragment identifies a TCP failure against one address and port. It does not prove why that host rejected the connection, whether another MX host works, or how a mailbox provider would handle a later accepted message. Keep these outcomes separate: - TCP refusal: the destination or an intervening control actively rejects the connection before SMTP starts. - TCP timeout: the sender does not receive a usable connection response before its timer expires. A timeout can indicate filtering, routing loss, or an unreachable host, but it is not evidence of an active refusal. - SMTP banner reachability: a `220` greeting means the TCP connection reached an SMTP listener. It does not prove that the server will accept a sender, recipient, or message. - Later SMTP response: an SMTP `4xx` or `5xx` reply occurs after the session starts. For example, [SMTP 550 permanent failure](/learning/smtp-550-permanent-failure) is an SMTP-level result, not a connection refusal. [RFC 5321 defines SMTP message transfer and MX-based routing](https://www.rfc-editor.org/rfc/rfc5321.html). A recipient domain can publish multiple MX hosts, and each host can resolve to more than one IP address. One refused address therefore does not establish that all delivery paths for the domain are unavailable. ![Decision flow for separating a TCP refusal, timeout, reachable SMTP banner, and later SMTP response](/images/editorial/smtp-connection-refused/smtp-connection-refused-connection-outcomes.webp "1200x829") *Source: Palisade.* ## What usually causes it? ### The sender selected the wrong endpoint or port A sender can connect to a stale IP address, a host that is not a published MX target, or a message-submission port instead of the recipient's server-to-server SMTP port. [RFC 5321 assigns TCP port 25 to SMTP relay](https://www.rfc-editor.org/rfc/rfc5321.html), while [RFC 6409 reserves port 587 for message submission](https://www.rfc-editor.org/rfc/rfc6409.html). This is especially likely when an application bypasses normal MX resolution or when a relay configuration contains a hard-coded host. Port `465` is also a message-submission service port for implicit TLS under [RFC 8314](https://www.rfc-editor.org/rfc/rfc8314.html). It is not the normal target for MX delivery. ### No SMTP listener is accepting connections on the advertised address The recipient MTA may be stopped, bound only to a private interface, still starting, or configured to listen on an address different from the one DNS advertises. A TCP refusal is consistent with a host that has no listener for the attempted address and port. The exact listener state requires recipient-side system or service evidence. ### A firewall or edge control rejects the connection A host firewall, network firewall, load balancer, cloud security rule, or anti-abuse control can reject a TCP attempt before it reaches the SMTP service. If one source network receives a refusal and another reaches the same host and port, the cause is an inference about the network path until the relevant firewall or provider logs confirm it. Do not treat this as a message-authentication failure. The SMTP server has not received the message data required to evaluate SPF, DKIM, or DMARC. ### An MX target or address record is stale A domain migration can leave an MX target, A record, or AAAA record pointing to retired infrastructure. RFC 5321 allows multiple MX hosts and address candidates, so test each published candidate rather than relying on the first failed connection. A stale IPv6 address can create a failure that appears only when the sender attempts IPv6. Compare address families only when the MX hostname publishes both A and AAAA records. ### The sending network cannot make outbound TCP port 25 connections An egress firewall or cloud-network policy can reject direct outbound SMTP while other networks can reach the recipient. The correct repair may be to use the organization's authorized relay, not to bypass the restriction or repeatedly retry the same blocked path. ## How do I diagnose the failure? ### 1. Preserve the connection evidence from the affected sender Start with the sending MTA queue record, application error, or network log from the failed attempt. Record the hostname and IP address the sender selected, the destination hostname and IP address, the port, timestamp with timezone, address family, and exact operating-system error. Build a connection evidence packet before changing DNS or transport settings: - Client hostname and source IP address, if available. - Recipient MX hostname and destination IP address attempted. - TCP port and transport purpose, such as server-to-server delivery or authenticated submission. - Timestamp and timezone. - Exact connection error, copied from the queue or log. - Network path and scope, including the sender's network, relay, VPN, cloud region, or egress gateway. - TLS mode if the TCP connection reached SMTP. For a refusal before the banner, record `not reached`. - Relevant MX, A, and AAAA answers captured at the time of the test. - A controlled test result from the same path, including whether it was refused, timed out, or returned a `220` banner. Do not share unredacted message headers, recipient addresses, credentials, or customer data in tickets that do not need them. ### 2. Resolve the current recipient route Query the recipient domain's MX records, then resolve every MX hostname to its A and AAAA addresses. Use the [MX records lookup](/tools/mx) to inspect publicly visible MX records before comparing them with the sender's queue evidence. A public lookup is useful when the queue log lacks the selected MX target or when you suspect stale public DNS. It cannot show which address your production MTA selected, confirm the receiving SMTP listener, or prove a receiver's later message decision. If the sender uses a configured relay instead of direct MX delivery, inspect that relay configuration first. The recipient's public MX records may be irrelevant to the failed connection. ### 3. Test each published address from the affected network From the sending network, test TCP port `25` for every intended destination address. Record the address, result, and time. Use an approved network diagnostic method for your environment. ![Checklist for testing each published MX address from the affected network](/images/editorial/smtp-connection-refused/smtp-connection-refused-test-path.webp "1200x582") *Source: Palisade.* ```bash nc -vz mx1.recipient.example 25 ``` This command is illustrative only. It tests TCP reachability to one hostname and port. It does not send a message, authenticate to a submission service, or prove that the recipient will accept mail after the SMTP banner. If a connection succeeds, capture only the initial SMTP banner. Do not use manual SMTP commands against systems you do not administer unless you are authorized to test them. > Do not change the recipient domain's MX records or relax a DMARC policy to respond to one refused connection. First establish whether the sender selected an incorrect endpoint, the listener is unavailable, or a network control rejected the route. ### 4. Compare a controlled network path Repeat the same test from a second approved network or relay, then compare the result by source IP and address family. A refusal from every tested network points toward the recipient endpoint, listener, or recipient-side edge control. A refusal only from one network points toward that sender's egress path or source-specific treatment. This comparison narrows the scope. It does not establish the recipient's private policy without evidence from the recipient's administrator or provider. ### 5. Check the receiving listener when you manage the destination If your team manages the recipient infrastructure, confirm that the MTA is running and listening on TCP port `25` on every public address advertised through MX resolution. Then inspect host firewalls, network firewalls, load balancers, cloud security controls, and any service health evidence. Check each layer independently. A service process marked healthy does not prove that the public interface is reachable, and a public TCP test does not prove that the server will accept a message for a particular recipient. ## How do I fix it? ### Correct the selected endpoint or port Replace a hard-coded stale hostname or IP address with the intended route. For normal server-to-server delivery, use the recipient's MX resolution process and TCP port `25` as defined by RFC 5321. For an application submitting mail to its own authorized provider, use the provider's documented submission endpoint and port. This repair changes transport routing. It does not alter SPF, DKIM, DMARC, or recipient mailbox filtering. ### Restore the listener on the published recipient address When you manage the destination, start or repair the SMTP service and bind it to the correct public interface. Confirm that each MX hostname resolves only to addresses where the service accepts TCP port `25`. Remove obsolete A or AAAA records if retired infrastructure cannot accept mail. Keep an MX host in DNS only when it is intended to receive mail for the domain. ### Permit the intended network path Adjust the confirmed host, network, load-balancer, or cloud rule so that intended server-to-server SMTP traffic reaches the listener. Make the narrowest rule change supported by the evidence. Preserve a rollback plan that restores the earlier control if it creates an unexpected exposure or delivery interruption. If an outbound control blocks direct port 25, configure the sender to use the approved relay. Do not bypass organizational egress policy with an unreviewed direct route. ### Repair stale MX or address records Update the authoritative MX, A, or AAAA records only after confirming the correct target and public listener. Then allow time for DNS caches to refresh according to the published TTL. This repair changes DNS routing. It does not prove that the receiving application accepts all recipients or that later SMTP, authentication, or mailbox checks will pass. ## How do I validate the repair? Repeat the original sending path. Start from authoritative DNS and compare its MX, A, and AAAA answers with at least one public resolver. Confirm that each intended recipient destination accepts TCP port `25` and returns an SMTP `220` banner when tested from the affected sender network. Send a controlled message through the same application, relay, source network, recipient domain, and content path that produced the refusal. Preserve the new queue result, SMTP transcript, and delivered-message headers where available. A `220` banner proves listener reachability only. A successful SMTP transaction requires the relevant later SMTP responses, including acceptance after message data. If the message is sent using your domain, inspect the delivered message's trusted authentication results and review DMARC aggregate-report data after it accumulates. Those checks validate message authentication after transport succeeds. They do not explain the original TCP refusal. For related post-connection errors, see [SMTP error 421 4.7.0](/learning/smtp-error-codes/421-4-7-0) for deferrals and rate-limiting behavior. ## Check the MX route before investigating ongoing sender issues Use the [MX records lookup](/tools/mx) to inspect the public MX route behind a refused connection and compare it with the destination recorded in the sender's queue. This can expose a stale MX target or an unexpected public hostname before you change infrastructure. A public MX lookup cannot test the affected sender's network path, repair a listener, monitor SMTP availability, or prove why a specific recipient system refused the TCP connection. Once transport works, Palisade's [DMARC Agent](https://docs.palisade.email/page-breakdowns/domain-overview/) can analyze DMARC aggregate-report data, identify sending sources and authentication or alignment issues, and create prioritized remediation tickets. A human reviews the evidence and applies any DNS or DMARC policy change. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=smtp_connection_refused&utm_content=smtp-connection-refused) ## Sources and further reading - [RFC 5321: Simple Mail Transfer Protocol](https://www.rfc-editor.org/rfc/rfc5321.html) - [RFC 9293: Transmission Control Protocol](https://www.rfc-editor.org/rfc/rfc9293.html) - [RFC 6409: Message Submission for Mail](https://www.rfc-editor.org/rfc/rfc6409.html) - [RFC 8314: Cleartext Considered Obsolete](https://www.rfc-editor.org/rfc/rfc8314.html) - [Palisade Domain Overview](https://docs.palisade.email/page-breakdowns/domain-overview/) ## Frequently asked questions ### Is SMTP connection refused a DNS error? No. SMTP connection refused is a TCP connection result. DNS can contribute when it returns a stale or incorrect MX target or address, but the refusal occurs when the sender attempts the resulting IP address and port. ### Is a timeout the same as SMTP connection refused? No. A refusal is an active TCP rejection before SMTP begins. A timeout means the sender did not receive a usable response before the connection timer expired. Test both outcomes from the same sender path because they indicate different network behavior. ### Does a `220` SMTP banner mean delivery will work? No. A `220` banner proves that a TCP connection reached an SMTP listener. The server can still reject the sender, recipient, message content, or authentication later in the SMTP session. ### Can DMARC cause SMTP connection refused? No. DMARC evaluation requires message authentication evidence after the SMTP session has progressed far enough for the receiver to process the message. A TCP refusal happens before that stage. ### Should I retry a refused SMTP connection? Only while there is evidence that the failure may be temporary or alternate MX destinations remain to test. Persistent refusal needs an endpoint, listener, DNS, firewall, or approved-relay repair before repeated retries can succeed. --- # Soft bounce vs hard bounce: what each means and what to do Canonical: https://www.palisade.email/learning/soft-bounce-vs-hard-bounce-email > Soft bounce vs hard bounce: learn the temporary and permanent delivery difference, how ESP labels vary, and how to respond safely with evidence. A soft bounce is usually a delivery failure your email provider treats as temporary. A hard bounce is usually one it treats as permanent. The SMTP standards use different terms: `4yz` replies are transient negative completions, while `5yz` replies are permanent negative completions for the requested action. Keep the provider label and the receiver's raw response together before you retry, suppress an address, or change domain settings. ## Quick takeaways - A `4yz` SMTP reply indicates a transient negative completion, while a `5yz` reply indicates a permanent negative completion for the requested action. - Soft bounce and hard bounce are email-service-provider classifications, not formal SMTP status terms. - A hard bounce does not prove that a recipient address never existed in every context. - A soft bounce does not guarantee that a later retry will succeed. - Preserve the raw SMTP reply, enhanced status code, diagnostic text, provider label, and repeat history before taking action. - Treat a bounce that names SPF, DKIM, DMARC, MX, or DNS as a configuration investigation, not automatic proof that the address is invalid. ## Who this comparison is for This comparison is for an email operator who has a bounce event, a sending-platform label, or an SMTP response and needs to choose the safe next action. It is useful when one address failed, a recipient domain is rejecting messages, or a broader campaign has started to defer or bounce. The choice is between two operational treatments, not between two interchangeable protocol states. A temporary receiver response may justify a bounded retry through the sending provider. A permanent response may require stopping unchanged retries, but the exact diagnostic still determines whether the issue is an invalid recipient, recipient-domain routing, authentication, content, or a receiver policy. For related error patterns, see [common email bounce messages](/learning/bounce-back-email). A bounce reporting missing recipient-domain routing needs a different investigation than a bad mailbox, as explained in [what no MX record found means in a bounce](/learning/no-mx-record-found-bounce). ## How the options were evaluated The categories and actions below were checked against first-party provider documentation and SMTP standards on August 12, 2026. - Protocol evidence: The three-digit SMTP reply, enhanced status code, receiving host, and exact diagnostic text. - Provider interpretation: The sending platform's classification, retry handling, reporting, or suppression treatment. - Action safety: Whether the evidence supports a retry, address review, domain-control check, or provider-specific investigation. - Scope: Whether the failure is isolated to one recipient, affects a recipient domain, or appears across multiple messages. - Unknowns: A provider's unpublished mapping or threshold remains unknown. Missing documentation does not prove that a feature or behavior is absent. The standards define reply semantics. They do not define every provider's soft-bounce or hard-bounce label. [RFC 5321 section 4.2.1](https://www.rfc-editor.org/rfc/rfc5321.html#section-4.2.1) defines `4yz` as a transient negative completion and `5yz` as a permanent negative completion. [RFC 3463 enhanced status codes](https://www.rfc-editor.org/info/rfc3463/) add condition detail, including persistent transient and permanent failure classes. ## Mailchimp's soft and hard bounce treatment [Mailchimp's soft and hard bounce guidance](https://mailchimp.com/help/soft-vs-hard-bounces/) describes a soft bounce as a temporary delivery problem and a hard bounce as a permanent delivery problem within Mailchimp's service. - Best fit: A Mailchimp user interpreting Mailchimp's own bounce labels and deciding whether a contact needs further review. - Relevant evidence: Mailchimp documents soft and hard bounce terminology and its own account treatment. The label is useful operational evidence inside Mailchimp. - Tradeoff: Mailchimp's classification and account handling are product-specific. They do not convert every similar SMTP reply from another provider into the same category or action rule. A hard-bounce label should stop blind retries, then direct the operator to the receiver's explanation. If the message reports an address-status failure, verify the address through an authorized source before sending again. Do not guess an alternative address. A temporary label calls for the retry behavior that Mailchimp documents for that sending path. It does not establish that the recipient mailbox will accept a later message. ## Twilio SendGrid's bounce and block classifications [Twilio SendGrid's bounce and block classifications](https://www.twilio.com/docs/sendgrid/ui/analytics-and-reporting/bounce-and-block-classifications) document an operational classification layer for receiver responses used in reporting and action. - Best fit: A Twilio SendGrid operator who needs to interpret a SendGrid bounce, block, or related event in the context of SendGrid reporting. - Relevant evidence: SendGrid documents classifications that group response outcomes for its platform. - Tradeoff: A SendGrid classification is an interpretation of the sending event. It does not replace the remote receiver's SMTP reply or reveal a mailbox provider's private filtering decision. Keep the receiver evidence beside the platform event. A `550` response with `5.1.1`, for example, supports an address-status investigation under the enhanced-code standard. A generic permanent reply with vague policy text needs the full diagnostic, affected scope, and provider context before an operator suppresses the contact across every system. ![Decision flow for separating the SMTP reply class from a sending provider's soft or hard bounce classification.](/images/editorial/soft-bounce-vs-hard-bounce-email/soft-bounce-vs-hard-bounce-decision-flow.svg "1200x831") *Source: [RFC 5321, "Simple Mail Transfer Protocol"](https://www.rfc-editor.org/rfc/rfc5321.html), checked 2026-08-12.* ## Palisade for the public-domain control branch Palisade is relevant only when the bounce evidence identifies a public domain control, such as SPF, DKIM, DMARC, MX, or another DNS-published email configuration. In that case, the [Email Security Score](/tools/email-security-score) can inspect the public configuration for the affected domain. - Best fit: An operator whose bounce evidence points to a public email-authentication or routing control that needs a point-in-time domain check. - Relevant evidence: The tool checks public DNS evidence for the controls it reports. It can help narrow a DNS or authentication branch before a same-path message retest. - Tradeoff: A public-domain scan cannot validate recipient existence, reproduce a private receiver policy decision, explain every provider suppression rule, or guarantee that a retried message will be accepted. Palisade is agentic DMARC software for teams that need to analyze DMARC aggregate-report data, identify sending sources and authentication or alignment issues, and prioritize remediation work. It does not control a receiver's filtering decision, validate a recipient mailbox, or guarantee delivery. ## How to choose Start with the raw response, then use the narrowest action the evidence supports. - Choose a bounded retry when the receiver returns a `4yz` response and the provider documents retry behavior for that situation. - Choose address verification and stop unchanged retries when a `5yz` response specifically identifies an invalid recipient address. - Choose a recipient-domain routing investigation when the response points to domain or MX problems. - Choose a public-domain check when the bounce names SPF, DKIM, DMARC, MX, or DNS. A [DKIM signature verification failure](/learning/smtp-error-codes/dkim-signature-verification-failed) needs message-header and signing-path evidence in addition to any public DNS result. - Choose the sending provider's dashboard and raw message evidence when the response is vague, policy-specific, or grouped under an unpublished classification. Use this redacted incident record before changing list data, retry policies, or DNS: ```yaml bounce_evidence: recipient: "redacted@example.net" smtp_reply: "550" enhanced_status: "5.1.1" diagnostic_text: "Recipient address rejected" provider_label: "hard bounce" first_seen: "2026-08-12T12:00:00Z" repeat_count: 1 decision: action: "stop unchanged retries and verify the address through an authorized source" verification: "send one new message through the same production path after the cause is corrected" ``` This example is illustrative only. Do not place a real recipient address, message content, or unredacted customer data in a shared incident record. > Do not repeatedly send an unchanged message after a permanent failure. Repetition does not correct an invalid address or a receiver's stated rejection condition. For Gmail-specific deferrals, [Google's sender guidance](https://support.google.com/mail/answer/15256272?hl=en) recommends pausing, testing with a single message, and increasing volume gradually after successful delivery. That guidance applies to Gmail traffic. It is not a universal retry schedule. ### Check public controls when the bounce names them If the diagnostic names SPF, DKIM, DMARC, MX, or DNS, inspect the affected sending domain with the [Email Security Score](/tools/email-security-score) before changing policy. Compare the public result with a fresh message sent through the same production path. The check does not prove why an individual receiver rejected a message, validate a recipient mailbox, monitor later changes, or guarantee future placement. It only helps inspect the public-domain configuration branch of this bounce investigation. ## Sources and further reading - [RFC 5321: Simple Mail Transfer Protocol](https://www.rfc-editor.org/rfc/rfc5321.html) - [RFC 3463: Enhanced Mail System Status Codes](https://www.rfc-editor.org/info/rfc3463/) - [Mailchimp: Soft vs. hard bounces](https://mailchimp.com/help/soft-vs-hard-bounces/) - [Twilio SendGrid: Bounce and block classifications](https://www.twilio.com/docs/sendgrid/ui/analytics-and-reporting/bounce-and-block-classifications) - [Google: Gmail sender guidelines for deferrals](https://support.google.com/mail/answer/15256272?hl=en) ## Frequently asked questions ### Is a soft bounce always temporary? No. A soft-bounce label usually means the sending provider treated the event as temporary, often alongside a `4yz` receiver response. The provider's retry behavior and later receiver responses determine whether the condition clears or requires investigation. ### Is a hard bounce always an invalid email address? No. An invalid address can produce a permanent failure, but a hard-bounce classification can also accompany another permanent rejection. Preserve the enhanced code and diagnostic text before deciding to suppress an address. ### Should I retry a 5yz SMTP reply? No. RFC 5321 says a client should not repeat the same request unchanged after a permanent `5yz` negative completion. Correct the condition named by the receiver, if one is actionable, before a new same-path test. ### Can a 4yz reply indicate an authentication problem? Yes. A temporary receiver response can include a policy, rate, or authentication-related condition. Read the full diagnostic text and inspect message evidence before assuming that the recipient mailbox is the cause. ### Do Mailchimp and Twilio SendGrid use the same bounce rules? Not necessarily. Both providers document their own classifications and handling. Their labels are useful within the relevant platform, but they are not universal SMTP definitions or industry-wide suppression thresholds. --- # Spam complaint rate in email: what it means and how to measure it Canonical: https://www.palisade.email/learning/spam-complaint-rate-email > Your spam complaint rate is spam reports divided by a denominator each provider defines itself, so a Gmail figure and a Yahoo figure are not comparable. A spam complaint rate is the share of messages in a mailbox provider's measured population that recipients report as spam. It is useful only when you retain the provider, sender identity, date window, numerator, and denominator that produced it. Gmail and Yahoo publish provider-specific guidance, so neither figure is a universal deliverability score or directly comparable with an ESP's attempted-mail rate. ## Quick takeaways - A complaint rate is a ratio, not a count of complaints by itself. - Compare rates only when the provider, identity, date window, and denominator match. - Gmail tells senders to keep Postmaster Tools spam rates below 0.10% and avoid 0.30% or higher. - Yahoo says applicable bulk senders should stay below 0.3%, and its Sender Hub Insights rate uses inbox-delivered messages. - A low rate does not guarantee inbox placement, because providers use other unpublished signals as well. ## Who is affected? A complaint happens when a recipient uses a mailbox provider's spam-reporting action. A provider may turn those events into an aggregate rate, a feedback-loop event, or both. The term is easy to use loosely, but the calculation is not automatically the same across systems. Use this working form: ```text spam complaint rate = reported spam events / provider-defined measured messages ``` The denominator is the important qualifier. An ESP report might divide by attempted, accepted, or delivered messages. Yahoo explicitly says Sender Hub's displayed rate is based on messages delivered to the inbox in its reporting population. That is narrower than an attempted-mail total and explains why an internal ESP percentage may not match Yahoo's percentage. See the [Yahoo Sender Hub FAQ](https://senders.yahooinc.com/faqs/) for the current definition. ![Complaint-rate evidence card showing the formula and the four fields required for a valid comparison](/images/editorial/spam-complaint-rate-email/spam-complaint-rate-email-evidence-card.svg "1200x741") *Source: Original Palisade deterministic evidence card based on the [Google Email sender guidelines](https://support.google.com/mail/answer/81126?hl=en) and [Yahoo Sender Hub FAQ](https://senders.yahooinc.com/faqs/). It explains how to preserve measurement scope and does not report provider or campaign performance.* The sender identity also changes the question. Yahoo's standard Insights data is selected by verified DKIM domain, while an ESP might organize its own report by account, From domain, campaign, or IP. For the provider-specific dashboard and its identity model, see [what Yahoo Sender Hub data provides](/learning/what-sender-data-does-yahoo-postmaster-provide). ## What are the requirements? ### Gmail's Postmaster rate guidance Google's [Email sender guidelines FAQ](https://support.google.com/mail/answer/14229414?hl=en) tells senders to keep the spam rate reported in Postmaster Tools below 0.10% and to avoid reaching 0.30% or higher. This is guidance for the rate Google reports for Gmail traffic, not a conversion formula for every campaign system or mailbox provider. Google also says its sender guidelines apply differently based on sending volume and mail type. Read the current [Google Email sender guidelines](https://support.google.com/mail/answer/81126?hl=en) alongside the rate instead of treating a percentage alone as a compliance result. Authentication, unsubscribe handling, and other sender requirements remain separate checks. ### Yahoo's bulk-sender complaint threshold Yahoo's [Sender Best Practices](https://senders.yahooinc.com/best-practices/) says bulk senders should keep spam complaint rates below 0.3%. The same guidance belongs to Yahoo's sender-requirement scope; it is not a claim that every sender at any provider has the same denominator or enforcement outcome. Yahoo distinguishes its threshold guidance from the Sender Hub calculation. Its [Sender Hub FAQ](https://senders.yahooinc.com/faqs/) says Insights displays an average complaint rate for the selected period and calculates that rate from inbox-delivered messages. Use the [Yahoo bulk sender requirements guide](/learning/yahoo-bulk-sender-requirements) for the complete authentication and unsubscribe requirements rather than using this page as an implementation checklist. ## When does the requirement take effect? This article reflects the current Google and Yahoo documents checked on July 29, 2026. The figures above are current sender guidance, not dates after which a universal complaint-rate rule began. Providers can change dashboard access, measurement methods, or enforcement guidance, so recheck the primary documentation before setting an internal alert threshold. The operational time window matters even when the published threshold is stable. A daily provider view, a seven-day ESP view, and a campaign view can each be valid, but they answer different questions. Record the window before declaring a rate improved or worse. ## How do I implement the requirement? ### 1. Record the provider's own definition For every complaint-rate figure, record the provider or system, its numerator, its documented denominator, and the displayed date window. Keep a link or export reference to the provider documentation. Do not substitute an ESP formula for a provider metric merely because both are percentages. ### 2. Map the sender identity behind the rate Record the visible From domain, DKIM signing domain, sending IP, ESP account, and campaign or stream where available. This keeps a domain-level provider figure from being incorrectly assigned to one campaign. Microsoft exposes different sender evidence through IP-oriented SNDS and JMRP services; [Microsoft's closest Postmaster Tools equivalent](/learning/what-is-microsoft-s-equivalent-to-google-postmaster-tools) explains that separate coverage model. ### 3. Compare like with like Compare a campaign to its prior campaign window, or a provider rate to the same provider's earlier rate, with the same identity where possible. If the denominator or identity changed, write that difference beside the result. Treat any conclusion about the cause of a change as an inference until message, campaign, and recipient evidence supports it. ### 4. Investigate the smallest changing segment When the provider rate rises, segment your first-party data by campaign, audience source, From domain, DKIM domain, sending IP, and send time. This is operational guidance, not a documented one-to-one provider rule. It helps narrow the next question without claiming that one complaint-rate number identifies the cause. ## How do I validate compliance? First, confirm that the rate is from the correct provider, sender identity, and window. Then verify the denominator from that provider's documentation or report definition. Finally, compare it with the same stream's first-party sending and suppression records. A rate can show that recipients reported mail, but it does not by itself prove why they did so or predict the final placement of every later message. For a broader evidence-led repair process when mail is landing in spam, use [why emails go to spam and how to fix it](/learning/why-do-your-emails-go-to-spam-and-how-can-you-fix-it). Keep its diagnostic steps separate from this measurement task: a complaint rate is one signal, not an inbox-placement guarantee. ## Check the Yahoo-specific evidence before acting If the figure you are interpreting is from Yahoo, inspect its reported window and DKIM-domain scope in Sender Hub before changing a campaign or suppression process. [Review Yahoo Sender Hub data](/learning/what-sender-data-does-yahoo-postmaster-provide) That guide explains Yahoo's available telemetry. It cannot prove that a campaign caused every complaint, calculate Gmail's rate, or guarantee future inbox placement. ## Sources and further reading - [Google Email sender guidelines](https://support.google.com/mail/answer/81126?hl=en) - [Google Email sender guidelines FAQ](https://support.google.com/mail/answer/14229414?hl=en) - [Yahoo Sender Best Practices](https://senders.yahooinc.com/best-practices/) - [Yahoo Sender Hub FAQ](https://senders.yahooinc.com/faqs/) ## Frequently asked questions ### Is a spam complaint rate the same as an email spam rate? No. A complaint rate concerns recipient spam reports within a provider-defined population. Providers may use the term spam rate in their own dashboards, but you should verify the documented numerator and denominator before equating it with an ESP metric. ### Is 0.3% a safe complaint-rate target for every provider? No. Google advises keeping its Postmaster Tools spam rate below 0.10% and avoiding 0.30% or higher, while Yahoo says applicable bulk senders should remain below 0.3%. Those statements are provider-specific guidance, not a universal target or delivery guarantee. ### Why does my ESP complaint rate differ from Yahoo Sender Hub? An ESP and Yahoo may use different traffic populations, identities, and time windows. Yahoo says its Sender Hub Insights rate is calculated from inbox-delivered messages, while an ESP can use a different documented denominator. ### Does a low spam complaint rate guarantee inbox placement? No. A low rate is useful evidence, but mailbox providers can consider authentication, reputation, content, recipient behavior, and other signals. Their full decision systems are not published as a single scorecard. ### Should I calculate complaint rate from attempted or delivered messages? Only use the denominator defined by the system whose rate you are reporting. For an internal metric, choose and document one consistent formula. Do not relabel it as a Gmail or Yahoo rate unless it matches that provider's documented measurement. --- # What is a DMARC failure report? Canonical: https://www.palisade.email/learning/what-exactly-is-a-dmarc-failure-report-and-why-should-you-care > DMARC failure reports are optional message-level reports about DMARC failures. Learn what they can contain, why delivery varies, and how to use them. A DMARC failure report, also called a forensic report, is an optional message-level report that a receiving mail system may send after a DMARC evaluation meets the reporting conditions published by the domain owner. It can help investigate a specific authentication failure, but it is not guaranteed, immediate, or complete because receivers can limit reporting and protect message data. Aggregate reports remain the primary evidence for broad sender inventory and DMARC monitoring. ## Quick takeaways - DMARC failure reports describe individual messages or message samples that triggered a receiver's failure-reporting conditions. - A `ruf` tag requests destinations for failure reports, but receivers are not required to send them. - The [`fo` tag](/learning/glossary/dmarc-fo) requests which authentication failure conditions can generate a report. - Failure reports can contain sensitive message data, so receivers may redact or omit content. - DMARC aggregate reports show wider traffic patterns and are usually more useful for ongoing source inventory. - A published `ruf` address does not prove that reports will arrive or that every DMARC failure will be reported. ## How DMARC failure reporting works [Failure reporting rules in RFC 9991](https://www.rfc-editor.org/rfc/rfc9991.html) define failure reports as optional reports sent to the destination requested through the `ruf` tag. A receiver first evaluates DMARC by checking whether SPF or DKIM passes with an identifier aligned to the visible From domain. If DMARC fails and the receiver chooses to generate a report under the requested conditions, it can send a message-level failure report. The report is different from a DMARC aggregate report. Aggregate reports use the `rua` tag and provide periodic XML data about observed traffic. Failure reports focus on a particular failed evaluation and can carry diagnostic details from that message. For broader context, see the [Palisade DMARC learning hub](/learning/dmarc). Receivers have discretion. RFC 9991 permits a receiver to limit failure-report volume and to suppress or redact data for privacy, security, or abuse-prevention reasons. That means a quiet `ruf` mailbox does not prove that no messages failed DMARC. It may mean that a receiver did not send a report, sent it elsewhere, rate-limited it, or removed sensitive details. ![Decision flow showing that a receiver may send an optional DMARC failure report after a message fails DMARC and meets the requested reporting condition](/images/editorial/what-exactly-is-a-dmarc-failure-report-and-why-should-you-care/what-exactly-is-a-dmarc-failure-report-and-why-should-you-care-failure-report-flow.webp "1200x829") *Source: Palisade.* ## When a DMARC failure report is useful, and when it is not A failure report is most useful when you have a specific incident to investigate, such as an unexpected authentication failure from a known sending path or an apparent unauthorized use of the visible From domain. Its message-level evidence can help compare the visible From domain, SPF identity, DKIM signing domain, and receiver evaluation. The answer changes when the question is about coverage rather than one event. Use aggregate reports to identify all observed sending sources, estimate the scope of alignment failures, and watch changes over time. A failure report is not a reliable traffic inventory. Use this decision rule: - Use a failure report when you have received one and need to inspect the authentication evidence for that reported message. - Use aggregate reports when you need to identify legitimate senders and recurring DMARC failures across a domain. - Use delivered-message headers when you need to verify the exact production path for a message your team sent. - Use a public DNS lookup when you need to inspect the DMARC record currently published for a domain. For example, a correct `p=reject` record does not show whether a marketing platform signs with an aligned DKIM domain. A real message from that platform and its `Authentication-Results` header provide evidence about that path. The [Google DMARC report guide](/learning/how-do-google-updated-dmarc-reports-reveal-sender-requirement-failures) is useful when provider reporting changes affect how you interpret report data. > Do not treat a failure-report mailbox as the only alert for DMARC problems. A receiver can suppress reports, and a missing report does not confirm that production mail is healthy. ## Worked example: reading `ruf` and `fo` The following is an illustrative DNS record shape only. Do not publish this example unchanged. Use a reporting destination your organization controls, and confirm that an external reporting address is authorized as required by the DMARC specification. ```text v=DMARC1; p=none; rua=mailto:dmarc-aggregate@yourdomain.com; ruf=mailto:dmarc-failures@yourdomain.com; fo=1 ``` [RFC 9989 section 4.7](https://www.rfc-editor.org/rfc/rfc9989.html#section-4.7) defines `ruf` as the URI for failure reports. The reporting specifications also let a receiver check authorization before sending reports to a destination outside the policy domain. In this example: - `ruf=mailto:dmarc-failures@yourdomain.com` requests failure reports at a mailbox under the example domain. - `fo=1` requests a report if either SPF or DKIM produces a failure condition described by the specification. - `rua=mailto:dmarc-aggregate@yourdomain.com` separately requests aggregate reports. - `p=none` requests no specific handling for a DMARC failure. It does not disable reporting. The `fo` values have distinct meanings in the failure-reporting specification, [RFC 9991](https://www.rfc-editor.org/rfc/rfc9991.html): - `0` requests a report if all underlying authentication mechanisms fail to produce an aligned pass. - `1` requests a report if any underlying authentication mechanism fails to produce an aligned pass. - `d` requests a report when a DKIM signature fails evaluation. - `s` requests a report when SPF fails evaluation. These tags express the domain owner's preference. They do not obligate every receiver to send a report or expose complete message content. ## What to do with the evidence you have If you have a received failure report, preserve a redacted copy and compare its visible From domain, SPF result, DKIM result, and any available authentication identifiers with the sending application you expected to use. Then send a controlled test message through that same application and inspect the delivered headers. [RFC 8601 defines the `Authentication-Results` header field](https://www.rfc-editor.org/rfc/rfc8601.html), which receivers use to record authentication assessment results. If you only have a domain name, use the [DMARC checker](/tools/dmarc) to inspect the public DMARC record and see whether it contains `ruf`, `rua`, and a policy. A public DNS check cannot prove that a receiver sent a failure report, that an application is using the intended signing path, or that future messages will pass DMARC. If you are deciding whether to rely on failure reports, keep them as supplemental incident evidence and use aggregate data for the ongoing work. The related guide on [whether DMARC failure reports are worth the trouble](/learning/what-exactly-is-a-dmarc-failure-report-and-why-should-you-care) covers that operational tradeoff. ## Continue from a failure report with Palisade A received failure report can explain one reported event, but it does not inventory every sender using the domain or show which authentication and alignment failures repeat across aggregate-report data. Palisade is agentic DMARC software that analyzes DMARC aggregate-report data, identifies sending sources and authentication or alignment issues, and creates prioritized remediation tickets. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=existing_content_migration&utm_content=what-exactly-is-a-dmarc-failure-report-and-why-should-you-care) Palisade can propose the next policy step from the evidence, while a human reviews it and applies any DNS change. It does not make a receiver send a failure report, change a receiver's private delivery decision, or prove every future message will authenticate. ## Sources and further reading - [RFC 9991: DMARC failure reporting](https://www.rfc-editor.org/rfc/rfc9991.html) - [RFC 9989 section 4.7: DMARC record tags, including `ruf`](https://www.rfc-editor.org/rfc/rfc9989.html#section-4.7) - [RFC 8601: Authentication-Results header field](https://www.rfc-editor.org/rfc/rfc8601.html) - [RFC 9989: Domain-based Message Authentication, Reporting, and Conformance](https://www.rfc-editor.org/rfc/rfc9989.html) ## Frequently asked questions ### Are DMARC failure reports sent for every failed message? No. A domain can request failure reports, but receiving systems can decide whether to send them and can apply rate limits, privacy controls, or other local restrictions. ### Does `ruf` enable DMARC aggregate reports? No. The `ruf` tag requests failure-report destinations. The `rua` tag requests aggregate-report destinations, and the two report types have different purposes. ### Can a DMARC failure report contain email content? Yes. Failure reports can contain message-related data, but receivers may redact or omit content to reduce privacy and security risk. Handle any received report as potentially sensitive. ### Is `fo=1` the same as a DMARC failure? No. `fo=1` requests reporting when either underlying SPF or DKIM authentication mechanism fails to produce an aligned pass. The receiver still controls report generation, and the message's final DMARC result depends on the full evaluation. ### Should I publish a `ruf` address outside my domain? Only when the external destination is authorized to receive reports. The DMARCbis reporting specifications (RFC 9990 and RFC 9991) carry forward the authorization check for external reporting destinations to reduce abuse. ### Can a public DMARC checker confirm that failure reports are arriving? No. A public checker can inspect the published DNS record. It cannot confirm receiver reporting behavior, mailbox delivery, report parsing, or the authentication results of a production message. --- # What is a domain reputation? Canonical: https://www.palisade.email/learning/what-is-a-domain-reputation > Domain reputation is a mailbox provider's assessment of a sending domain. Learn which signals you can check, what providers keep private, and how to. Domain reputation is a mailbox provider's assessment of mail associated with a sending domain. It can influence spam filtering and inbox placement alongside authentication, message content, recipient feedback, and provider-specific signals. There is no universal domain-reputation score. You can inspect public signals and your own sending evidence, but only the receiving mailbox provider can see its full reputation decision. ## Quick takeaways - Domain reputation is provider-specific, so Gmail and another mailbox provider can assess the same domain differently. - SPF, DKIM, and DMARC help establish domain identity, but passing authentication does not guarantee inbox placement. - A public domain-reputation lookup is a point-in-time signal, not a receiver's private filtering decision. - Provider reporting and delivered-message headers are stronger evidence for a specific delivery problem. - A sender can measure its sending practices and recipient feedback, but cannot inspect every receiver's reputation model. - Retest an issue through the same sending application, domain, recipient provider, and message path. ## What this tool checks The [Palisade Domain Reputation Checker](/tools/domain-reputation) accepts a domain and checks publicly available reputation information associated with that domain. Use it to find a public signal that may justify a closer investigation. The check is an outside-in observation. It cannot see a mailbox provider's private reputation calculation, recipient engagement, the exact production sender, an individual message's authentication result, or why one recipient received mail in spam. It also cannot prove continuous state or future inbox placement. Google's [Email sender guidelines](https://support.google.com/a/answer/81126) require bulk senders to authenticate mail with SPF and DKIM, publish a DMARC record, and keep reported spam rates below 0.3%. Those are Gmail requirements. They do not define a universal formula for domain reputation. Domain reputation and IP reputation are related but distinct. A domain can send through several IP addresses, while shared sending infrastructure can introduce IP-level factors that a domain lookup cannot separate. ## The domain-reputation evidence framework Keep three kinds of evidence separate. Each answers a different question. - Reader-controlled authentication and DNS evidence: public SPF, DKIM, and DMARC records, plus the authentication result on a delivered message. This evidence can show whether a record is published and whether a receiver reported authentication for one message. It does not reveal private reputation. - Sending-program evidence: campaign source, audience, consent records, unsubscribe handling, sending volume, and provider reporting available to the domain owner. For personal Gmail recipients, [Google Postmaster Tools](https://support.google.com/mail/answer/9981691) provides data about mail sent to personal Gmail accounts when the domain is eligible and verified. - Receiver-private reputation decisions: a mailbox provider's filtering models, recipient-level signals, and final placement choices. Senders cannot inspect these completely. A public checker and even provider reporting do not expose every signal behind one mailbox decision. ![Three evidence categories for investigating domain reputation: DNS and authentication, sending-program evidence, and receiver-private decisions.](/images/editorial/what-is-a-domain-reputation/domain-reputation-evidence-framework.webp "1200x676") *Source: Palisade.* Use a compact record for each investigation. It prevents a broad reputation concern from being mistaken for a configuration diagnosis. ```text Illustrative redacted evidence record Domain: yourdomain.com Authenticated identifiers: From=yourdomain.com; DKIM d=mail.yourdomain.com Source and time: Campaign application, 2026-08-12 14:00 UTC Sending context: Transactional password-reset message to a personal Gmail inbox Observed signal: Message was placed in spam; public lookup showed no public concern Next review date: 2026-08-19 ``` The record is illustrative only. Do not store unredacted customer addresses, message bodies, private keys, tokens, or full message headers in a shared investigation log. ![Flow showing the separate DNS and authentication, sending-program, and receiver-private evidence used to investigate domain reputation.](/images/editorial/what-is-a-domain-reputation/what-is-a-domain-reputation-reputation-evidence.webp "1200x676") *Source: Palisade.* ## How to run the check ### 1. Identify the visible From domain Start with the domain recipients see in the message's From address. If the issue concerns one campaign or application, record the application, approximate send time, recipient mailbox provider, and any bounce or spam-folder evidence. Do not substitute the return-path domain, DKIM signing domain, or IP address unless the investigation concerns that identifier. Those values can differ from the visible From domain. ### 2. Run the public domain lookup Open the [Palisade Domain Reputation Checker](/tools/domain-reputation) and submit the domain without an email address or URL path. Save the result with the queried domain and the time of the check. For a repeatable public DNS observation, query the DMARC owner for the same visible domain: ```bash dig +short TXT _dmarc.yourdomain.com ``` This command does not measure reputation. It confirms whether a public DMARC record answers at the expected DNS owner name. Google requires bulk senders to publish DMARC, but the presence of a record does not establish reputation or inbox placement. ### 3. Check provider-specific evidence When Gmail delivery is the concern, review the relevant verified domain in Google Postmaster Tools. Google documents its dashboards as data about mail sent to personal Gmail accounts, including spam-rate and domain-reputation data where available. A Gmail observation does not prove how Outlook.com, Yahoo, or another mailbox provider treated the same message. Keep the provider, mailbox type, and observation date in the evidence record. ### 4. Inspect a delivered message from the affected path Open the raw headers for a message sent through the same application and campaign path. Find the receiver-added `Authentication-Results` field. [RFC 8601 defines Authentication-Results as a message header field for reporting message authentication status](https://www.rfc-editor.org/rfc/rfc8601.html). Check the reported SPF, DKIM, and DMARC outcomes and the identifiers they reference. A public lookup may identify a concern worth investigating. A delivered message shows what the receiving system evaluated for that specific message. ## How to interpret the results ### The lookup shows no public concern This means the public lookup did not identify a concern it can report for the queried domain at that time. It is not a clearance for all mailbox providers, messages, or future sends. If affected mail still goes to spam, move to message and provider evidence. Check the authentication results, then compare the affected mail stream with the [Gmail new-domain spam-placement guidance](/email-deliverability/why-does-gmail-mark-new-domain-emails-as-spam) when Gmail is the receiving provider. ### The lookup indicates a public reputation signal A public signal is a reason to investigate the sending program. It does not identify the mailbox provider, campaign, application, or message that caused the signal. First confirm that the queried domain is the visible From domain used by the affected mail. Then separate authentication from reputation. Inspect the delivered message, review provider reporting where available, and determine whether the affected traffic came from one application or several. Do not assume that changing an authentication record will repair a reputation issue. Authentication helps receivers verify identity. It does not reverse a receiver's private filtering decision or make unwanted mail wanted. ### The lookup is unavailable or inconclusive An unavailable or inconclusive result is not evidence of good or bad reputation. Public services have different data coverage and may not return an observable result for every domain. Use the evidence that is available. A delivered message can establish authentication for the production path. Provider reporting can show provider-specific signals for eligible domains. DMARC aggregate reports can help identify sources that use the visible From domain after reports accumulate, but they do not expose a receiver's complete reputation model. ### A mailbox observation shows spam placement Spam placement is evidence about that message, recipient path, and time. It does not prove that every recipient saw the same result or reveal every factor behind the receiver's decision. Compare the message's authentication results with the sending-program record. If authentication passed, focus the next review on the evidenced application, campaign, consent, unsubscribe handling, content, audience selection, and sending pattern. If authentication failed, repair the exact sender configuration or DNS record used by that message before drawing reputation conclusions. ## How to act on the result Start with the evidence closest to the observed delivery problem. - If the delivered message fails SPF, DKIM, or DMARC, repair the exact sender configuration or DNS record that message used. Do not copy values from another account or domain. The [DKIM checker domain guide](/tools/dkim) explains how to validate the public key record after you identify the selector in the message. - If authentication passes but Gmail data shows a concerning spam rate or weak domain reputation, review the affected mail stream against [Google's bulk sender guidance](https://support.google.com/a/answer/81126). Keep the review scoped to the application and campaign evidenced in the data. - If the public lookup shows a signal but message and provider evidence are missing, collect a newly delivered message before changing DNS. Public reputation information alone does not identify the configuration to alter. - If DMARC reports show unfamiliar sources using the visible From domain, investigate those sources before increasing DMARC enforcement. If report addresses are rejected as unauthorized, see [why DMARC says an rua or ruf domain is not authorized](/learning/dmarc-rua-ruf-domain-authorization). > Do not remove SPF, DKIM, or DMARC records to test whether they caused spam placement. Removing authentication can disrupt legitimate mail and makes the next test harder to interpret. ## How to retest Repeat the public lookup for the same visible From domain after correcting an evidenced issue. Record the result, date, and provider context. Then send a new message through the same application, authenticated domain, recipient provider, and intended recipient path. Inspect its `Authentication-Results` header and compare it with the earlier evidence record. For Gmail-specific concerns, allow enough eligible traffic for Postmaster Tools to show relevant data, then compare the same domain and sending context. A changed public lookup result does not prove that a receiver changed its private reputation decision. A passing delivered-message authentication result does not guarantee inbox placement. ## Track the sources that still use your domain A public reputation lookup can identify a signal, but it cannot inventory every production source that sends as your domain or show which sources still fail DMARC alignment after a change. Palisade is agentic DMARC software that analyzes DMARC aggregate-report data, identifies sending sources and authentication or alignment issues, and creates prioritized remediation tickets. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=email_deliverability&utm_content=what-is-a-domain-reputation) Palisade proposes the next DMARC policy step from the evidence, while a human reviews the evidence and applies any change. It does not change a receiver's private reputation decision, guarantee inbox placement, or prove that every future message will authenticate. For broader delivery investigation, use the [email deliverability learning hub](/email-deliverability). ## Sources and further reading - [Google Email sender guidelines](https://support.google.com/a/answer/81126) - [Google Postmaster Tools help](https://support.google.com/mail/answer/9981691) - [RFC 8601: Authentication-Results header field](https://www.rfc-editor.org/rfc/rfc8601.html) - [Palisade Domain Reputation Checker](/tools/domain-reputation) ## Frequently asked questions ### Is domain reputation the same as IP reputation? No. Domain reputation concerns mail associated with a domain, while IP reputation concerns the sending IP address. A message can be affected by both, especially when a domain sends through shared or changing infrastructure. ### Does a good public reputation result mean messages will reach the inbox? No. A public result does not reveal a mailbox provider's private filtering decision, recipient-specific signals, or future placement. Inspect a real delivered message and provider-specific reporting when available. ### Can SPF, DKIM, and DMARC improve domain reputation? Only indirectly. Authentication lets receivers verify domain identity and is required for many bulk-sender scenarios, but it does not guarantee inbox placement or reverse a private reputation decision. ### Why does Gmail show a different reputation signal than another provider? Mailbox providers use their own data and filtering systems. Gmail reporting describes eligible mail sent to personal Gmail accounts, so it should not be treated as evidence for another provider. ### What should I check first when messages go to spam? Check the visible From domain, a newly delivered message's Authentication-Results header, and evidence from the affected sending application. Then review provider data for the same mailbox provider if it is available. --- # What is a PTR record and how does reverse DNS use it? Canonical: https://www.palisade.email/learning/what-is-a-ptr-record > PTR records map an IP address to a hostname. Learn how reverse DNS works, validate forward confirmation, and troubleshoot email sending IPs. A PTR record is a DNS record that maps a public IP address back to a hostname through reverse DNS. Mail receivers can use that hostname to identify the server that opened an SMTP connection, then check whether it resolves forward to the same IP address. A valid PTR record supports sender identity, but it does not prove SPF, DKIM, DMARC, reputation, or inbox placement. ## Quick takeaways - A PTR record maps an IP address to a hostname through reverse DNS. - IPv4 reverse DNS uses the `in-addr.arpa` namespace with the IP address octets reversed. - The organization that controls an IP address or address range normally controls its PTR record. - Forward-confirmed reverse DNS checks whether the PTR hostname resolves back to the original IP address. - Google requires bulk senders to use sending IP addresses with valid forward and reverse DNS records. - A valid PTR record does not prove that a production message passes SPF, DKIM, or DMARC. ## What this tool checks The [Palisade IP reputation checker](/tools/ip-reputation) returns the reverse DNS (PTR) answer for a public IP address. Enter the public sending IP to see its PTR hostname, then query that hostname forward in the [DNS lookup tool](/tools/dns-lookup) with an A record for IPv4 or an AAAA record for IPv6. [RFC 1034 defines PTR records as domain-name pointers](https://www.rfc-editor.org/rfc/rfc1034.html). For an IPv4 address such as `192.0.2.25`, the reverse DNS owner name is `25.2.0.192.in-addr.arpa`. A public query can return a hostname, or it can return no PTR answer. A public record check cannot identify the application that sent a particular message, prove the SMTP banner presented during a connection, confirm message signing, monitor future DNS changes, or explain one receiver's private reputation decision. Use the result with sender configuration, a delivered message, and DMARC aggregate-report data. ## Build a reverse DNS evidence packet Keep a labelled evidence packet for each sending path you investigate. It helps separate public DNS evidence from message and provider evidence. - **Sending IP address:** The public IP seen by the receiving server. - **Exact PTR owner queried:** For IPv4, the reversed address under `in-addr.arpa`. - **PTR result:** The returned hostname, or the exact no-record result. - **Forward-confirmation result:** Whether the hostname's A or AAAA answer includes the original IP. - **SMTP banner hostname:** The hostname presented in the SMTP greeting, when logs or a message trace expose it. - **Sending-service owner:** The team, cloud provider, relay, or email service that controls the sending IP. - **Source and time:** Where the IP came from and when the DNS queries ran. - **Change and retest date:** When the IP owner changed the PTR record and when the same checks were repeated. Use redacted production values in tickets and shared notes. This is an illustrative evidence shape, not a DNS record to publish. ![Reverse DNS evidence packet showing the IP address, PTR response, forward result, and SMTP banner](/images/editorial/what-is-a-ptr-record/what-is-a-ptr-record-reverse-dns-evidence.webp "1200x600") *Source: Palisade.* ```text Sending IP: 192.0.2.25 PTR owner queried: 25.2.0.192.in-addr.arpa PTR result: mail.yourdomain.com. Forward confirmation: A mail.yourdomain.com includes 192.0.2.25 SMTP banner hostname: mail.yourdomain.com Sending-service owner: hosting provider Source/time: recipient connection log, 2026-08-12 12:00 UTC Change/retest date: no change requested ``` ## How to run the check ### 1. Identify the actual public sending IP Start with the address that handled the SMTP connection for the message under investigation. A receiving-server trace, trusted mail log, or sending-provider activity record is stronger evidence than an application hostname. Do not test a private address such as `10.0.0.5`. Private addresses are not delegated in public reverse DNS. If you have only a hostname, resolve its A or AAAA records first, then match the result to the production message path. ### 2. Query the reverse DNS owner Enter the public IP address in the [Palisade IP reputation checker](/tools/ip-reputation) and read the Reverse DNS (PTR) row. The tool checks the public DNS evidence for that exact input. Repeat the lookup independently with this example: ```bash dig +short -x 192.0.2.25 ``` `192.0.2.25` is reserved documentation space. Replace it with the verified public sending IP from your evidence packet. ### 3. Query the returned hostname forward If the PTR response returns `mail.yourdomain.com.`, query that hostname forward. Use an A query for an IPv4 sending IP and an AAAA query for an IPv6 sending IP. ```bash dig +short A mail.yourdomain.com ``` The original IP should appear in the relevant forward answer. [RFC 1912 recommends matching PTR and A records for Internet hosts](https://www.rfc-editor.org/rfc/rfc1912.html). ### 4. Compare DNS with the message path A matching PTR and A record is DNS evidence only. If an email issue prompted the test, inspect a newly delivered message through the same application, relay, provider account, and recipient path. Compare the public sending IP with connection details available in the message trace or receiver logs. The [email authentication learning center](/learning) explains why DNS identity checks and message authentication answer different questions. A receiver records its authentication evaluation in the `Authentication-Results` header field defined by [RFC 8601](https://www.rfc-editor.org/rfc/rfc8601.html). ![Reverse DNS validation flow from sending IP to PTR hostname, forward lookup, and delivered-message evidence](/images/editorial/what-is-a-ptr-record/what-is-a-ptr-record-reverse-dns-validation-flow.webp "1200x829") *Source: Palisade.* ## How to interpret the results ### A PTR hostname resolves back to the sending IP This is a forward-confirmed reverse DNS result. The reverse query returned a hostname, and a forward query for that hostname includes the original IP address. For an outbound mail server, this supports a consistent public relationship between the address and hostname. It does not prove that the SMTP server used the same hostname in its HELO or EHLO greeting. It also does not prove an SPF pass, a DKIM signature, DMARC alignment, or placement in a recipient inbox. ### No PTR record is returned A no-record response means the public resolver did not return a PTR record for the IP queried. First, confirm that the IP is the actual egress address. A cloud gateway, relay, or email provider may send from a different address than the server you manage. If the address is correct, identify its owner. The owner of a dedicated IP range normally manages reverse DNS. Google states in its [email sender guidelines](https://support.google.com/a/answer/81126) that bulk senders must use sending IP addresses with valid forward and reverse DNS records. A missing PTR record is a sender-configuration issue to resolve, but the lookup alone does not prove that Gmail rejected a message for that reason. ### The PTR hostname does not resolve to the original IP This is a forward-confirmed reverse DNS mismatch. Query the hostname exactly as returned by the PTR answer and compare the correct record type with the original address. A stale PTR record, IP reassignment, a changed A or AAAA record, or a wrong test IP can cause this result. Confirm who controls both the IP's reverse zone and the hostname's authoritative forward DNS before requesting a change. ### The returned hostname has multiple forward addresses A hostname can have several A or AAAA records. If the original sending IP appears in the corresponding answer, the forward lookup supports the reverse mapping. If it is absent, treat the mapping as a mismatch until the IP owner confirms the intended setup. Do not infer that every address associated with the hostname sends mail. The delivered message or provider trace identifies the path used for the event under investigation. ## How to act on the result For a missing PTR record, ask the sending-service owner whether the IP is dedicated or shared. - **Dedicated provider IP:** Ask the provider that owns the address range to set the PTR hostname. Then make sure the hostname's A or AAAA record includes the same IP. - **Forward mismatch:** Correct the PTR record through the IP owner, or correct the hostname's authoritative A or AAAA record through the DNS operator. Treat these as one coordinated change. - **Shared provider IP:** Do not attempt to publish a PTR record for the shared IP. The provider controls that reverse DNS zone. Confirm whether the provider documents valid reverse DNS for its shared infrastructure, then focus on the authenticated message path for your domain. > Do not point a PTR record at a domain you do not control or at a hostname whose forward DNS does not include the sending IP. That creates a mismatch and makes sender troubleshooting harder. Before a production test, confirm that the SMTP greeting hostname is appropriate for the configured server identity when that setting is under your control. A PTR record is different from a DNS alias. Read [what a CNAME record does](/learning/what-is-a-cname-record) before using an alias as part of a hostname change. For TXT-based sender settings such as SPF and DMARC, see [what a TXT record does](/learning/what-is-a-txt-record). ## How to retest Repeat the reverse lookup after the IP owner confirms that it changed the PTR record. Query the returned hostname forward with the matching A or AAAA record type, then record whether the original IP now appears. Next, validate the message layer. Send a new message through the same application, relay, provider account, and recipient path. Check the actual egress IP where the receiving system or provider trace exposes it. Inspect the receiver-added `Authentication-Results` header for SPF, DKIM, and DMARC results. A DNS checker cannot prove that the application used the expected sending path or hostname. Once messages are flowing, review DMARC aggregate reports or Palisade monitoring to identify sending sources and authentication or alignment issues across the domain. DNS validity today does not show whether a later sender, IP change, or new service changes the production path. ## Track the sender inventory after the PTR check A corrected PTR record answers one public DNS question for one IP. It does not inventory every source that sends as your domain or show which sources still fail DMARC alignment. Palisade is agentic DMARC software that analyzes DMARC aggregate-report data, identifies sending sources and authentication or alignment issues, and creates prioritized remediation tickets. It can propose the next DMARC policy step when the evidence supports it, while your team reviews the evidence and applies the change. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=existing_content_migration&utm_content=what-is-a-ptr-record) Palisade does not change your DMARC policy without human review, repair every sender automatically, or prove why a receiver made a private reputation decision about one message. For a provider-specific implementation of these authentication checks, see [How do you fix 'Reverse DNS does not match SMTP banner'?](/learning/reverse-dns-does-not-match-smtp-banner). ## Sources and further reading - [RFC 1034: Domain names, concepts and facilities](https://www.rfc-editor.org/rfc/rfc1034.html) - [RFC 1912: Common DNS operational and configuration errors](https://www.rfc-editor.org/rfc/rfc1912.html) - [RFC 8601: Message Authentication Status](https://www.rfc-editor.org/rfc/rfc8601.html) - [Google email sender guidelines](https://support.google.com/a/answer/81126) - [Palisade IP reputation checker](/tools/ip-reputation): reverse DNS (PTR) for a sending IP - [Palisade DNS lookup tool](/tools/dns-lookup): forward A and AAAA records for the returned hostname ## Frequently asked questions ### Is a PTR record the same as an A record? No. An A record maps a hostname to an IPv4 address. A PTR record maps an IP address to a hostname through the reverse DNS namespace. Forward-confirmed reverse DNS compares both directions. ### Can I create a PTR record in my normal DNS provider? Only if that provider also controls the public IP address range. Reverse DNS is normally managed by the ISP, cloud provider, hosting provider, or email provider that owns the address allocation. ### Does a valid PTR record make email pass DMARC? No. DMARC evaluates SPF or DKIM authentication and alignment with the visible From domain. A valid PTR record can support server identity checks, but it does not replace SPF, DKIM, or DMARC. ### Does a shared email-provider IP need my domain in its PTR record? No. A shared provider IP normally has reverse DNS controlled by the provider. You cannot safely set its PTR record yourself. Validate the provider's documented sending setup and inspect a real delivered message for your domain's authentication results. ### Does forward-confirmed reverse DNS guarantee inbox placement? No. A matching PTR and forward record show a consistent public DNS relationship. Mailbox providers can apply additional authentication, content, reputation, and recipient-specific checks that public DNS cannot reveal. --- # What is angler phishing and how can you stop it? Canonical: https://www.palisade.email/learning/what-is-angler-phishing-and-how-can-you-stop-it > Angler phishing uses fake social-media support accounts to exploit public complaints. Learn how to verify support and limit email impersonation. Angler phishing is a brand-impersonation scam that targets people who publicly ask for help on social media. A criminal account poses as customer support, replies or sends a direct message, and tries to move the conversation to a fraudulent login page or request sensitive information. Stop it by verifying support through the brand's official website, refusing credential or payment requests in unsolicited messages, and reporting the impersonating account. ## Quick takeaways - Angler phishing depends on a fake support identity and a public signal that someone needs help. - A display name, logo, or familiar tone does not authenticate a social-media account. - Verify a support contact by starting from the company's official website or app, not from a reply or direct message. - Do not send passwords, multi-factor authentication codes, recovery codes, or payment details to an account that contacted you first. - DMARC can reduce email spoofing of a domain, but it cannot remove a fraudulent social-media profile. - Organizations need both customer-facing verification guidance and a process for reporting impersonation. ## How angler phishing works The defining pattern is the support pretext. A person posts about a billing problem, outage, delivery issue, or account-access problem. A look-alike account then presents itself as the company and offers help. The attacker wants the conversation to leave the public thread. A direct message can contain a link to a counterfeit sign-in page, a request for account details, or instructions to disclose a one-time verification code. The [Federal Trade Commission's guidance on impersonator scams](https://consumer.ftc.gov/articles/how-avoid-scam) advises people to verify unexpected contacts independently and not use contact details supplied by the unexpected message. A fake account can look convincing because social platforms allow names, profile images, and public replies that resemble those of a real business. Those cues are not proof of account ownership. The useful question is narrower: did you reach the organization through a contact path the organization publishes and controls? For the broader defense context, see Palisade's [email security learning hub](/learning). Angler phishing is social-media impersonation, but it may coexist with email impersonation, fake websites, or phone calls that use the same brand. ![Flow showing a public support request, a fake support reply, an attempt to move the conversation, and independent verification through the official website](/images/editorial/what-is-angler-phishing-and-how-can-you-stop-it/what-is-angler-phishing-and-how-can-you-stop-it-angler-flow.webp "1200x829") *Source: Palisade.* ## When the answer changes A real support account may reply to a public post or ask to continue a case through a private channel. That fact alone does not establish fraud. Treat the contact as unverified until you independently confirm the account and the requested action. Use this decision rule: - If the account asks for a password, recovery code, multi-factor authentication code, or full payment-card data, stop the exchange. The [Cybersecurity and Infrastructure Security Agency's phishing guidance](https://www.cisa.gov/secure-our-world/recognize-and-report-phishing) advises against providing sensitive information in response to suspicious messages. - If the account sends a link, do not sign in through that link. Open the brand's known website or app yourself and find support from there. - If the issue needs account-specific information, start a new support request through the official site, authenticated app, or published phone number. - If the brand confirms that the account is official, still share only the information required for the support case and follow the organization's published process. A verification badge, follower count, or account age can inform a review, but none proves that a message is legitimate. Platform features and policies differ, and attackers can compromise or imitate established accounts. ## A worked verification example Suppose a customer posts: "My service is down. Can someone help?" An account with a similar name replies and asks the customer to direct message an email address and a one-time code. The customer should not continue in the direct message. Instead, they should open the provider's official website by typing the known address or using a saved bookmark, then locate the support route published there. ```text Public reply received: "Send us your email address and verification code by DM." Safe response: 1. Do not send the code or follow a supplied link. 2. Open the provider's official website or authenticated app independently. 3. Start a support case through the published channel. 4. Report the suspected impersonating account to the social platform. 5. Preserve the account handle, message link, and screenshots for the provider's security team. ``` The one-time code matters because it can approve a sign-in, password reset, or other account action. It is authentication evidence, not customer-support information. For organizations, publish a short support-verification policy where customers can find it before an incident. State the official account handles, the approved ways to open a case, and the categories of information support will never request through social media. > Do not ask customers to post account details in a public thread. A public reply can acknowledge the issue and direct the customer to a verified support route, but it should not collect credentials or payment information. ## What to do next, based on the evidence you have If you received a suspicious reply or direct message, verify it through the brand's official site, report the account through the social platform, and notify the real organization through its published support channel. Include the profile URL, handle, message text, and any destination URL. Do not include passwords, codes, or other secrets in the report. If your organization is the impersonated brand, document your official support accounts and train support staff to send customers only to controlled support paths. Keep an incident record that captures the impersonating handle, affected platform, reported URLs, report reference, and customer communications. If the campaign also uses email that appears to come from your domain, inspect the domain's published DMARC record with Palisade's [DMARC checker](/tools/dmarc). A public DNS check can show the current record, but it cannot prove that a particular social-media account is fraudulent, identify every production sender, or show a mailbox provider's private delivery decision. Email authentication is a supporting control. [DMARC](https://www.rfc-editor.org/rfc/rfc9989.html) uses aligned SPF or DKIM authentication to help domain owners express handling preferences for failing mail. It does not govern social-media identities or take down fraudulent profiles. For that distinction, see [does DMARC stop phishing?](/learning/does-dmarc-stop-phishing). A stronger login process also helps limit the value of stolen passwords. [Phishing-resistant MFA](/learning/phishing-resistant-mfa) addresses a separate control: how users authenticate when a phishing attempt tries to capture credentials. ## Check the email domain used alongside the impersonation If a suspicious campaign includes email from a domain you control, inspect its published DMARC record before treating email spoofing as confirmed or changing DNS. [Check the DMARC record](/tools/dmarc) A public DMARC lookup cannot remove a fake social-media account, prove the source of a direct message, monitor future impersonation, or guarantee that every legitimate message will authenticate. For ongoing DMARC work, Palisade is agentic DMARC software that analyzes aggregate-report data, identifies sending sources and authentication or alignment issues, and creates prioritized remediation tickets. It can propose the next DMARC policy step when the evidence indicates readiness, while a human reviews the evidence and applies the DNS change. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=security&utm_content=what-is-angler-phishing-and-how-can-you-stop-it) Palisade does not control social-media accounts, remove impersonators, or guarantee inbox placement. It helps teams investigate the email-authentication side of domain impersonation after DMARC reports accumulate. ## Sources and further reading - [Federal Trade Commission: How to avoid a scam](https://consumer.ftc.gov/articles/how-avoid-scam) - [Cybersecurity and Infrastructure Security Agency: Recognize and report phishing](https://www.cisa.gov/secure-our-world/recognize-and-report-phishing) - [RFC 9989: Domain-based Message Authentication, Reporting, and Conformance](https://www.rfc-editor.org/rfc/rfc9989.html) - [Does DMARC stop phishing?](/learning/does-dmarc-stop-phishing) ## Frequently asked questions ### Is angler phishing the same as ordinary phishing? No. Angler phishing is a phishing pattern built around fake customer-support contact on social media after a person publicly signals that they need help. It can still use familiar phishing techniques, such as counterfeit sign-in pages or requests for sensitive information. ### Can an official-looking profile be trusted? No. A familiar name, profile image, badge, or writing style is not enough to prove that an account controls a brand's support channel. Verify the contact through the organization's official website, app, or other published route. ### Should I reply to a suspected fake support account? No. Do not provide account information or continue through a link or direct-message channel chosen by the account. Preserve the evidence, report the account to the platform, and contact the real organization through an independently verified channel. ### Does DMARC stop fake social-media accounts? No. DMARC applies to email authentication and policy handling for messages that use a domain in the visible From field. It cannot verify, remove, or control a social-media account. ### What information should support never request in a direct message? Support should not ask for passwords, multi-factor authentication codes, recovery codes, or full payment-card details through an unsolicited direct message. If an account requests those items, end the exchange and verify support independently. --- # What is DANE and does your email need it? Canonical: https://www.palisade.email/learning/what-is-dane > DANE uses DNSSEC-signed TLSA records to authenticate SMTP TLS. Learn when email domains need DANE, how it works, and how to validate it safely. DANE, short for DNS-Based Authentication of Named Entities, lets a receiving email domain publish DNSSEC-protected TLSA records that tell SMTP senders how to authenticate its mail servers. For SMTP, [RFC 7672](https://datatracker.ietf.org/doc/html/rfc7672) defines how senders use those records to require authenticated TLS for delivery when usable DANE TLSA records exist. Your email domain needs DANE when you can operate DNSSEC correctly and want transport protection that does not rely only on public certificate authorities. ## Quick takeaways - DANE for SMTP uses TLSA DNS records and DNSSEC validation to authenticate a receiving mail server's TLS certificate or public key. - [RFC 6698](https://datatracker.ietf.org/doc/html/rfc6698) defines the TLSA record type, while RFC 7672 defines its SMTP use. - A TLSA record without a DNSSEC-validated chain is not usable as a DANE trust signal. - SMTP DANE records apply to each destination MX host, normally at `_25._tcp.<mx-host>`. - DANE protects the SMTP transport path. SPF, DKIM, and DMARC authenticate sending domains and address a different problem. - MTA-STS also supports authenticated SMTP transport, but it uses an HTTPS policy and the web PKI instead of DNSSEC. ## Who is affected? DANE affects domains that receive SMTP mail on infrastructure they control or can configure through a mail provider. The receiving domain publishes TLSA records for the MX hosts that accept mail, and sending systems that support SMTP DANE can validate those records before delivery. The core dependency is DNSSEC. [RFC 7671](https://datatracker.ietf.org/doc/html/rfc7671) explains that DANE relies on DNSSEC to authenticate TLSA data. A record that is merely visible in public DNS does not provide DANE authentication. The sender needs a DNSSEC-validated answer for the TLSA lookup and the DNS records that establish the relevant DNSSEC chain. This makes DANE a poor fit when you cannot safely manage DNSSEC, do not control the MX hosts, or cannot coordinate certificate and DNS record changes with the mail service that presents the TLS certificate. It can be a good fit for domains with stable inbound mail infrastructure, DNSSEC operational ownership, and a need to make downgrade-resistant SMTP TLS available to supporting senders. DANE does not require every sender on the internet to implement it. A sender that does not support SMTP DANE will not obtain DANE authentication from your TLSA records. That is why a broader [email transport security guide](/learning/infrastructure) should consider both protocol support and your actual receiving environment. ## What are the requirements? ### DNSSEC must authenticate the TLSA lookup A DANE client uses DNSSEC validation to decide whether TLSA data is secure and usable. DNSSEC is not an optional hardening layer around SMTP DANE. It is the trust mechanism that prevents an active network attacker from replacing or suppressing the TLSA answer. Before publishing TLSA records, confirm that the zone is signed, its delegation is correct, and validating resolvers can obtain secure answers. A DNSSEC failure can have delivery consequences for DANE-aware senders, so treat DNSSEC changes as production mail changes. ### The TLSA record binds a TLS service to certificate data [RFC 6698](https://datatracker.ietf.org/doc/html/rfc6698) defines a TLSA record as four fields: certificate usage, selector, matching type, and certificate association data. The first three fields state how to evaluate the association data. The last field contains the certificate or public-key material, or a digest of it, selected by those fields. For SMTP, the TLSA owner name is built from the TCP port and the destination MX hostname. This structural example is illustrative only. Do not publish another organization's certificate association data. Generate the actual value from the certificate or key used by your own MX host. ```text _25._tcp.mail.yourdomain.com. IN TLSA 3 1 1 <SHA-256-subject-public-key-info-digest> ``` A `3 1 1` TLSA record uses DANE-EE certificate usage, the SubjectPublicKeyInfo selector, and a SHA-256 matching type. RFC 7672 describes DANE-EE as the expected SMTP deployment profile. The correct value still depends on the certificate or public key your receiving mail server presents. ![Protocol flow showing a DANE-aware SMTP sender validating DNSSEC, retrieving a TLSA record, and authenticating the receiving MX host certificate](/images/editorial/what-is-dane/what-is-dane-protocol-flow.webp "1200x829") *Source: Palisade.* ### SMTP delivery uses the MX hostname, not only the recipient domain SMTP delivery first follows the recipient domain's MX records. [RFC 7672](https://datatracker.ietf.org/doc/html/rfc7672) applies TLSA lookups to the resulting SMTP destination hostnames. If `yourdomain.com` has several MX hosts, each host that can receive mail needs TLSA data that matches the TLS service it presents. A TLSA record at `_25._tcp.yourdomain.com` does not automatically cover `mail.yourdomain.com` when that is the MX hostname. Review the published MX answers and build the TLSA name from each actual destination host. This is also why an MX change, certificate renewal, or load-balancer change needs DANE review. A valid TLSA record for one host does not authenticate another host with a different certificate or public key. ### The sender authenticates TLS when usable DANE records exist SMTP has historically used opportunistic TLS. A sender can use STARTTLS when offered, but traditional opportunistic TLS does not by itself stop a network attacker from stripping STARTTLS or presenting an untrusted certificate. RFC 7672 defines how a DANE-aware SMTP client uses DNSSEC-authenticated TLSA records to obtain authenticated TLS. When the client has usable DANE TLSA records for the destination, it must not fall back to unauthenticated delivery merely because TLS authentication fails. Delivery can defer while the sender retries according to its queue policy. > A stale or incorrect TLSA record can interrupt inbound mail from DANE-aware senders. Stage certificate and TLSA changes together, and keep a tested rollback path. ## When does the requirement take effect? DANE is an IETF protocol standard, not a single mailbox-provider deadline. [RFC 6698](https://datatracker.ietf.org/doc/html/rfc6698) was published in August 2012 and defines TLSA records. RFC 7671, published in October 2015, gives DANE operational guidance. RFC 7672, published in October 2015, defines SMTP transport security using DANE. These are final RFCs, not drafts. They do not impose a universal date by which every email domain must publish TLSA records, and they do not guarantee that every sending platform will use them. Your effective date is operational: DANE begins to affect delivery when a supporting sender reaches one of your DNSSEC-validated MX destinations and finds usable TLSA records. Do not turn uneven implementation support into a protocol claim. Test the sending paths that matter to your organization, and retain MTA-STS or other transport controls where they fit your requirements. ## How do I implement the requirement? ### 1. Inventory your receiving MX hosts Query the MX records for the recipient domain and list every hostname that can receive SMTP mail. Include priority changes, regional hosts, and failover hosts. Use [DNS records for business email](/learning/dns-records-for-business-email) as a reference for the roles of MX, TXT, and other email DNS records. DANE records are tied to the MX destination hostname, not to a vague idea of the email domain. ### 2. Establish and validate DNSSEC Enable DNSSEC with the DNS operator responsible for the zone and confirm the parent delegation is correct. Validate the chain with a DNSSEC-aware resolver before relying on TLSA data. A public lookup can help inspect published DNS. It cannot prove that every production sender validates the chain, that your mail host is presenting the intended certificate, or that a particular receiver will accept delivery. ### 3. Obtain the certificate association data from the receiving service Identify the certificate or public key that each MX host presents for SMTP on TCP port 25. Decide the TLSA usage, selector, and matching type based on the applicable RFC profile and your service's certificate lifecycle. Coordinate with a managed mail provider before publishing records. Do not derive values from a browser certificate for a web hostname and assume they apply to SMTP. The SMTP listener may use a different certificate or key. ### 4. Publish TLSA records for each destination host Publish a DNSSEC-signed TLSA record at `_25._tcp.<mx-host>` for every relevant MX hostname. Allow DNS propagation and DNSSEC validation to complete before changing the certificate or routing production mail to a new host. When rotating keys, publish association data that supports the planned transition before withdrawing the old record. The exact overlap strategy depends on the certificate material and record choices you use. ### 5. Keep transport security separate from sender authentication DANE protects the connection between SMTP servers. It does not tell a recipient whether the visible From domain is authorized to send the message. Maintain SPF, DKIM, and DMARC alongside transport controls. [DMARC's role in email security](/learning/is-dmarc-the-email-game-changer) is different: it evaluates identifier alignment and policy for a message's From domain. ## How do I validate compliance? Validate DANE at four layers. - DNS: inspect MX, TLSA, DNSKEY, DS, and DNSSEC validation results through authoritative DNS and at least one validating public resolver. Confirm each TLSA owner name maps to a real MX destination. - Vendor or host: confirm with the mail-hosting provider which SMTP certificate and public key each receiving host currently presents. A provider dashboard can help, but it is not message-path evidence. - Message and TLS: test SMTP delivery from a DANE-capable sending path to the exact production MX host. Confirm that the certificate presented during SMTP TLS matches the published, DNSSEC-validated TLSA association. - Ongoing DMARC evidence: use aggregate reports to understand who sends mail using your domain. [DMARC reports](/resources-post/how-to-understand-dmarc-reports) do not validate inbound DANE, but they help keep sender authentication work separate from transport-security work. ![DANE deployment checklist covering MX inventory, DNSSEC validation, TLSA publication, certificate matching, and SMTP testing](/images/editorial/what-is-dane/what-is-dane-validation.webp "1200x582") *Source: Palisade.* Use Palisade's [DNS lookup tool](/tools/dns-lookup) to inspect public DNS records for a domain before making changes. A public DNS check does not prove the production SMTP certificate, continuous DNSSEC health, a sender's DANE implementation, or future delivery decisions. ## Inspect the DNS records behind your DANE deployment Start with the MX hosts and published DNS records for the receiving domain. Compare every TLSA record with the SMTP service and certificate your mail provider confirms. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=email_transport_security&utm_content=what-is-dane) Palisade is agentic DMARC software that analyzes DMARC aggregate-report data, identifies sending sources and authentication or alignment issues, and proposes prioritized remediation work for human review. It can help with the ongoing sender-authentication work around your domains, but it does not change a DANE policy, validate every SMTP TLS connection, or control a receiving provider's delivery decision. ## Sources and further reading - [RFC 6698: The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA](https://datatracker.ietf.org/doc/html/rfc6698) - [RFC 7671: The DNS-Based Authentication of Named Entities (DANE) Protocol: Updates and Operational Guidance](https://datatracker.ietf.org/doc/html/rfc7671) - [RFC 7672: SMTP Security via Opportunistic DANE Transport Layer Security (TLS)](https://datatracker.ietf.org/doc/html/rfc7672) - [RFC 8461: SMTP MTA Strict Transport Security (MTA-STS)](https://datatracker.ietf.org/doc/html/rfc8461) ## Frequently asked questions ### Does DANE require DNSSEC? Yes. DANE relies on DNSSEC validation to authenticate TLSA records. Without a secure DNSSEC result, a TLSA record cannot provide the DANE trust signal that SMTP DANE needs. ### Is DANE the same as MTA-STS? No. Both can improve SMTP transport security, but DANE uses DNSSEC-signed TLSA records to authenticate the receiving service. MTA-STS uses a DNS signal, an HTTPS policy file, and the web public-key infrastructure. ### Does DANE replace DMARC? No. DANE authenticates the SMTP transport connection to a receiving mail server. DMARC uses SPF and DKIM results to evaluate whether mail aligns with the message's visible From domain. ### Do I need one TLSA record for every MX host? Yes. SMTP DANE checks TLSA records for the actual MX destination hostname. Each MX host that receives mail needs TLSA data appropriate for the SMTP certificate or public key it presents. ### Can a DNS lookup prove that DANE is working for all senders? No. A DNS lookup can inspect public MX, TLSA, and related DNS records. It cannot prove that every sender implements DANE, that the live SMTP service presents matching certificate material, or that future delivery will succeed. --- # What is phone number spoofing and how do you stop it? Canonical: https://www.palisade.email/learning/what-is-phone-number-spoofing > Phone number spoofing falsifies caller ID. Learn how spoofed calls work, how to respond safely, and what carrier authentication can do today. Phone number spoofing is when a caller makes a call or sends a text that displays a phone number other than the number actually used to originate it. You cannot stop another person from selecting a spoofed caller ID, including your own number, but you can reduce the risk: treat unexpected caller ID as unverified, contact organizations through independently found details, and report suspected scams. ## Quick takeaways - Phone number spoofing changes the number shown to the recipient, not necessarily the caller's real origin. - A familiar, local, or trusted-looking number is not proof that a caller is legitimate. - Caller ID authentication can help carriers identify some illegitimate spoofing, but it does not make every displayed number trustworthy. - Do not provide passwords, verification codes, payment details, or remote access because of an unexpected call. - If a caller claims to represent an organization, end the call and use contact details from that organization's official website or statement. - Phone spoofing and email spoofing both abuse trust in a displayed identity, but they use different technical controls. ## How phone number spoofing works A caller ID display gives the recipient an identifier to recognize or return a call. That identifier can be used legitimately. For example, an organization may present its main published number when staff place outbound calls from different lines. The risk begins when the displayed number is used to misrepresent who is calling. A fraudster may choose a number that appears local, resembles a known business number, or belongs to an unrelated person. The recipient sees the chosen identifier before they can independently verify the caller. The Federal Communications Commission describes caller ID spoofing as deliberately falsifying the information transmitted to caller ID display systems. Its [caller ID spoofing guidance](https://www.fcc.gov/spoofing) also explains that spoofing with intent to defraud, cause harm, or wrongfully obtain anything of value is prohibited under US law. A spoofed display does not, by itself, tell you how a call was placed, who placed it, or whether the number's legitimate subscriber is involved. That distinction matters if your own number appears to have been used. Receiving callbacks from strangers can mean that someone displayed your number on calls to them. It does not establish that your handset, account, or phone service was accessed. ![Decision flow for responding to an unexpected call with a trusted-looking caller ID](/images/editorial/what-is-phone-number-spoofing/what-is-phone-number-spoofing-call-response.webp "1200x676") *Source: Palisade.* ## When the answer changes The safe response depends on what evidence you have, not on how convincing the caller ID looks. If you were not expecting the call, treat the claimed identity as unverified. This applies even when the display shows your bank, an employer, a government body, a utility, or a local-looking number. End the call without using a phone number provided by the caller. Then find the organization's contact information through its official website, card, invoice, account portal, or another trusted record. If the call concerns an existing account, use the number you already have for that account. If the caller says there is an emergency, an unpaid bill, a security incident, or a required payment, slow the interaction down. A legitimate organization can normally be contacted through an independently verified route. Use this decision rule: - An unexpected call plus a request for money, credentials, one-time codes, remote device access, or urgent action is enough reason to disconnect and verify separately. - A displayed number matching a known organization does not change that rule. - A callback request from an unfamiliar person does not prove that your number was compromised. - A call that you initiate using independently verified details gives you a better basis for discussing an account, though you should still follow the organization's normal authentication process. The [FCC's unwanted calls guidance](https://www.fcc.gov/consumers/guides/stop-unwanted-robocalls-and-texts) recommends avoiding engagement with suspected scam calls and provides reporting options. Blocking one number may stop future calls from that displayed number, but it cannot prove that the underlying caller cannot use a different number later. ## A worked response example Suppose your phone displays the number of a bank and the caller says that suspicious activity requires an immediate verification code. The caller ID is not the evidence you need. The relevant evidence is whether you can independently reach the bank and whether the bank confirms the request through its normal process. ```text Unexpected call claiming to be a bank Displayed caller ID: A number that appears to belong to the bank Caller request: Read out a verification code Safe response: 1. Do not share the code or account details. 2. End the call. 3. Find the bank's official contact number from its website or card. 4. Call that number and ask whether the request was genuine. 5. Report the suspicious call if it was fraudulent. ``` A caller ID label, a local area code, and a familiar number are all weak identity signals because each can be presented without proving the caller's authority. The independent callback is the stronger test because you choose the destination from a trusted source. If your number is being spoofed, preserve useful details such as the time of callbacks, any voicemail, and the number people say they received calls from. Do not ask callers to disclose private information. You can explain briefly that your number may have been spoofed, then report the pattern through the appropriate channels. ## What to do with the evidence you have Start with the least invasive action that matches the evidence. - If you received an unexpected call or text, do not reply with sensitive information. Block the displayed number if your device or carrier supports it, while recognizing that blocking does not identify the source. - If the caller impersonated an organization, contact that organization through independently found details and ask whether it wants the incident reported through a particular channel. - If the call appears fraudulent, submit a report through the [Federal Trade Commission's fraud reporting service](https://reportfraud.ftc.gov/) and, where relevant, the FCC's consumer complaint process. - If your number appears to be spoofed, tell your phone provider what you observed and keep a short record of dates and callback details. Carrier caller ID authentication helps validate some calls in the telephone network. The FCC's [call authentication information](https://www.fcc.gov/call-authentication) describes the STIR/SHAKEN framework and its role in reducing illegal caller ID spoofing. It is useful network evidence, but it is not a reason to disclose information to an unexpected caller. Calls can still require independent verification. For the broader impersonation problem, see [how to stop spoofing attacks](/learning/what-exactly-is-spoofing-and-how-can-you-stop-it) and [what spoofing is and how to stop it](/learning/what-exactly-is-spoofing-and-how-can-you-stop-it). Phone number spoofing is one channel. Email impersonation is another, with separate controls and evidence. ## Check your domain's email impersonation exposure A suspicious phone call does not tell you whether someone can also impersonate your organization by email. If you manage a domain, use the [Email Security Score](/tools/email-security-score) to inspect its publicly visible email-authentication posture. For further context on securing business email identity, visit the [email security learning hub](/learning). [Check your domain's email security score](/tools/email-security-score) A public domain check cannot identify the person behind a phone call, prove that a specific email was legitimate, monitor every future sender, or control a phone carrier's treatment of a call. Palisade is agentic DMARC software that analyzes DMARC aggregate-report data, identifies sending and alignment issues, and proposes remediation work for human review. It does not change a phone number's caller ID or decide whether a carrier blocks a call. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=existing-content-migration&utm_content=what-is-phone-number-spoofing) ## Sources and further reading - [Federal Communications Commission: Caller ID spoofing](https://www.fcc.gov/spoofing) - [Federal Communications Commission: Stop unwanted robocalls and texts](https://www.fcc.gov/consumers/guides/stop-unwanted-robocalls-and-texts) - [Federal Communications Commission: Call authentication](https://www.fcc.gov/call-authentication) - [Federal Trade Commission: Report fraud](https://reportfraud.ftc.gov/) ## Frequently asked questions ### Is phone number spoofing illegal? Only spoofing that is done with intent to defraud, cause harm, or wrongfully obtain something of value is prohibited by the US Truth in Caller ID Act. A displayed number can also have legitimate business uses, so the display alone does not establish intent. ### Can someone spoof my number without hacking my phone? Yes. A person can present your number as caller ID without accessing your phone, SIM, or account. Unexpected callbacks may indicate that your number was displayed on someone else's calls, but they are not proof of an account breach. ### Should I call a suspicious number back? No. Do not call the displayed number back to verify an unexpected claim. Find the organization's contact information yourself through an official website, account portal, statement, or card, then initiate the call. ### Does STIR/SHAKEN stop all spoofed calls? No. Caller ID authentication helps telephone providers validate some caller ID information and reduce illegal spoofing. It does not prove that every call is legitimate or remove the need to verify unexpected requests independently. ### Is phone number spoofing the same as email spoofing? No. Both involve a false-looking identity, but phone caller ID and email sender identity use different systems. Email domains can publish SPF, DKIM, and DMARC controls, while phone networks use caller ID authentication and carrier-level mitigation. --- # What are business email compromise (BEC) attacks and how do you stop them? Canonical: https://www.palisade.email/learning/what-is-the-complete-guide-to-business-email-compromise-bec-attacks-in-2025 > Business Email Compromise (BEC) attacks impersonate trusted people or vendors to redirect money or data. Learn the warning signs and controls. Business Email Compromise (BEC) attacks use a trusted-looking email, account, or identity to persuade someone to send money, change payment details, disclose information, or take another high-risk action. The safest response is to verify any unusual financial or data request through a separate, known contact channel. Email authentication can reduce direct spoofing of your domain, but it cannot validate a payment request sent from a compromised account or a lookalike domain. ## Quick takeaways - BEC is a targeted social-engineering attack that exploits trust in executives, vendors, employees, or business processes. - A message can appear credible because an attacker has compromised a real account, spoofed a domain, or registered a similar-looking domain. - An out-of-band verification process is the control that can stop a fraudulent payment or bank-detail change before approval. - Multi-factor authentication helps reduce the risk of email-account takeover, but it does not make every message trustworthy. - DMARC protects a domain from unauthorized use of its visible From domain when receivers apply the published policy. - A passing public DNS check does not prove that every production sender authenticates correctly or that a receiver will deliver a message. ## How Business Email Compromise attacks work The [FBI's Internet Crime Complaint Center describes Business Email Compromise](https://www.ic3.gov/CrimeInfo/BEC) as a sophisticated fraud that targets organizations involved in payments and transfers of funds. The attacker seeks a believable request, such as a changed bank account for a supplier invoice, a confidential employee-data export, or an urgent executive payment. The email path behind a BEC attempt matters because the defenses differ. An attacker may send a message from a compromised employee or vendor mailbox. In that case, the message can come from a legitimate domain and may pass normal authentication checks. The problem is that the account holder did not authorize the request. An attacker may instead impersonate a domain. [RFC 9989 defines DMARC](https://datatracker.ietf.org/doc/html/rfc9989) as a protocol that evaluates whether SPF or DKIM passes with alignment to the visible From domain, then lets the domain owner publish requested handling for failures. DMARC helps receivers distinguish unauthorized mail that claims to be from a protected domain. It does not decide whether a real sender's request is commercially valid. A third path uses a lookalike domain. For example, a fraudulent domain may differ from a supplier domain by one character. DMARC on the real supplier's domain does not control mail sent from that separate domain. For the protocol controls behind these checks, visit the [email authentication learning center](/learning). For the broader business impact, see [how BEC threatens your business](/learning/what-is-the-complete-guide-to-business-email-compromise-bec-attacks-in-2025). ## When the answer changes: use the evidence to choose the control The practical response changes according to what the recipient can verify. - If the request claims to come from your own domain but the sender address looks suspicious, inspect the domain's DMARC record and the delivered message headers. This can help identify direct-domain impersonation, but it cannot prove who sent the message. - If the request comes from a known vendor or executive address, assume the mailbox could still be compromised. Pause the transaction and confirm the request using a phone number, contact directory, or approval channel that was already trusted. - If payment instructions, bank details, or recipient details changed, require verification through a separate channel before changing records or releasing funds. - If the message asks for credentials, use the organization's established reporting and incident process. Do not reply to the email to verify it. - If a public domain is similar to a trusted supplier, compare the complete domain name with the supplier contact information already on file. The [Cybersecurity and Infrastructure Security Agency's guidance on BEC](https://www.cisa.gov/topics/cyber-threats-and-advisories/malware-phishing-and-ransomware) recommends independently verifying requests to change payment information and using multi-factor authentication. These are process and account-security controls. They remain necessary when email authentication passes. > Do not change bank details or release a payment based only on an email thread, even when the sender name and wording appear familiar. Confirm the request through an independently verified contact method. BEC and phishing overlap, but they are not interchangeable labels. [Business email compromise versus phishing](/learning/business-email-compromise-vs-phishing) explains the distinction: phishing can target many recipients, while BEC commonly relies on a business relationship or approval workflow that makes the requested action plausible. ## A worked BEC verification example A finance employee receives a message that appears to be from a supplier and asks the company to send the next invoice payment to a new bank account. The right question is not, "Does this email look convincing?" The right question is, "Can the approved supplier contact independently confirm this change?" Use a short, recorded verification rule that separates the email from the approval decision: ```text Request: Change supplier payment instructions Do not approve from the email alone. Verify through: - A phone number or portal contact already recorded for the supplier - A second authorized approver for the payment change - The supplier's established account-management process Record: - Who verified the request - Which independent contact method was used - The date and approved change reference ``` This is an illustrative operational format. It is not a substitute for your organization's payment controls, contractual requirements, or incident-response process. ![Decision flow for a suspicious payment-change email, requiring independent supplier verification before approval](/images/editorial/what-is-the-complete-guide-to-business-email-compromise-bec-attacks-in-2025/what-is-the-complete-guide-to-business-email-compromise-bec-attacks-in-2025-bec-verification-flow.webp "1200x676") *Source: Palisade.* For messages that claim to use your domain, inspect the technical evidence as well. A delivered message's `Authentication-Results` header can show the receiver's authentication assessment. [RFC 8601 defines the Authentication-Results header field](https://www.rfc-editor.org/rfc/rfc8601.html). A header result is evidence about that message at that receiver. It does not validate the requested transaction, show all sending paths, or predict future delivery. ## Practical next steps for a suspected BEC request Start with the evidence you have, in this order: - If you have a payment or data request, stop the approval process and use the independent verification rule. Preserve the message for the security or fraud-response team according to your internal process. - If you have the received message, collect its full headers and compare the visible From domain, return-path domain, and authentication results. Do not forward unredacted sensitive content outside approved channels. - If the message impersonates your domain, use the [DMARC checker](/tools/dmarc) to inspect the public DMARC record. Compare the published policy with the domain your team expects to protect. - If the record is missing or uses `p=none`, do not move directly to a stronger policy based on that lookup alone. First inventory legitimate senders and confirm aligned SPF or DKIM results on real production messages. - If the request came from a real employee or vendor mailbox, investigate account access, mailbox rules, and the affected business process. A DMARC record cannot remediate a compromised mailbox. A safe implementation check has four layers: query authoritative DNS and a public resolver, confirm the relevant sending service's status, inspect a real delivered message from the production path, and review DMARC aggregate reports after they accumulate. Each layer answers a different question. ## Build a controlled path to DMARC enforcement A public DMARC lookup can show whether your domain publishes a policy today. The unresolved operational question is which legitimate services still send mail for the domain and whether each path aligns. Palisade is agentic DMARC software that analyzes DMARC aggregate-report data, identifies sending sources and authentication or alignment issues, and creates prioritized remediation tickets. It can propose the next policy step when the evidence supports it, while your team reviews the evidence and applies any DNS change. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=email&utm_content=what-is-the-complete-guide-to-business-email-compromise-bec-attacks-in-2025) Palisade does not validate an individual payment request, change your DMARC policy without human action, prove every future message will authenticate, or guarantee inbox placement. ## Sources and further reading - [FBI Internet Crime Complaint Center: Business Email Compromise](https://www.ic3.gov/CrimeInfo/BEC) - [Cybersecurity and Infrastructure Security Agency: Business Email Compromise](https://www.cisa.gov/topics/cyber-threats-and-advisories/malware-phishing-and-ransomware) - [RFC 9989: Domain-based Message Authentication, Reporting, and Conformance](https://datatracker.ietf.org/doc/html/rfc9989) - [RFC 8601: Authentication-Results header field](https://www.rfc-editor.org/rfc/rfc8601.html) ## Frequently asked questions ### Is Business Email Compromise the same as phishing? No. Phishing is a broad category of deceptive messages that can seek credentials, data, or money. BEC is typically targeted at a business process or trusted relationship, such as an executive request or supplier payment change. ### Can DMARC stop all BEC attacks? No. DMARC can reduce unauthorized use of a domain's visible From domain when receivers apply the DMARC policy. It cannot stop messages from compromised legitimate accounts, lookalike domains, or fraud that succeeds through a separate communication channel. ### Should a finance team call the number in a suspicious email? No. Use a phone number or contact method already recorded in an approved supplier directory, contract, portal, or internal system. A number supplied in the suspicious message may reach the attacker. ### Does multi-factor authentication prevent BEC? No. Multi-factor authentication helps protect accounts from unauthorized access, but BEC can also use spoofed domains, lookalike domains, or deception that does not require access to the victim's mailbox. ### What should a team preserve after spotting a BEC attempt? Preserve the message and its full headers through the organization's approved security process, along with the transaction request, the verification result, and any related account or payment changes. Keep sensitive customer data, credentials, private keys, and tokens out of unapproved systems. --- # Why does DMARC fail and how do I fix it? Canonical: https://www.palisade.email/learning/why-dmarc-fails-how-to-fix-it > A DMARC fail means neither SPF nor DKIM passed in alignment with the visible From domain. Identify the source, repair it, and retest the same path. DMARC fails when neither SPF nor DKIM produces a passing identifier that aligns with the domain in the visible `From:` header. Start with the delivered message and the sender that produced it. Repair that sender's authentication or domain alignment, then resend through the same route. Changing the DMARC policy does not repair the underlying authentication failure. ## Quick takeaways - DMARC can pass through either aligned SPF or aligned DKIM. Both mechanisms do not need to pass. - An SPF pass for an unrelated envelope sender domain does not satisfy DMARC alignment. - A DKIM pass for an unrelated `d=` signing domain does not satisfy DMARC alignment. - A DMARC policy requests receiver handling for failures. It does not correct SPF, DKIM, or alignment. - A public DNS lookup shows the current published record, not the production sender, receiver decision, or future messages. - Validate a repair with authoritative DNS, a new delivered message, and DMARC aggregate-report data after it accumulates. ## What does the failure mean? [DMARC evaluation in RFC 9989](https://www.rfc-editor.org/rfc/rfc9989.html) checks whether SPF or DKIM has passed and aligned with the visible `From:` domain. SPF alignment compares the authenticated envelope sender domain with `From:`. DKIM alignment compares the signing domain in `d=` with `From:`. A trusted receiver-added authentication result may look like this: ```text Authentication-Results: receiver.example; spf=pass smtp.mailfrom=sender.example; dkim=pass header.d=mailer.example; dmarc=fail header.from=yourdomain.com ``` This is an illustrative redacted evidence shape, not a provider error string. [RFC 8601 defines `Authentication-Results`](https://www.rfc-editor.org/rfc/rfc8601.html), including fields such as `smtp.mailfrom` and `header.d`. Prefer results added by the receiving system over copied authentication headers from an unknown intermediary. The fragment shows two passing authentication mechanisms and a DMARC failure at the same time. Neither authenticated domain aligns with `yourdomain.com`: `sender.example` supplied the SPF identity and `mailer.example` supplied the DKIM identity. The receiver therefore reports `dmarc=fail` for the visible From domain. ![DMARC failure evidence packet showing the From domain, SPF identity, DKIM identity, policy result, record, and source-specific next actions](/images/editorial/why-dmarc-fails-how-to-fix-it/why-dmarc-fails-how-to-fix-it-failure-evidence-packet.webp "1200x666") *Source: Palisade.* ## What usually causes it? ### The envelope sender does not align with the visible From domain A sending service can pass SPF for its own return-path domain while the recipient sees mail from your domain. [RFC 7208 defines SPF evaluation against the envelope sender identity](https://www.rfc-editor.org/rfc/rfc7208.html#section-2.3). DMARC requires that passing SPF identity to align with the visible `From:` domain before it can satisfy DMARC. This often points to a sender that has not been configured with its own authenticated return path or custom MAIL FROM domain. Adding unrelated IP addresses to an SPF record does not repair an unaligned identity. ### DKIM signs with an unrelated domain A message can have a valid DKIM signature whose `d=` domain belongs to the sending platform rather than the visible `From:` domain. [RFC 6376 defines the `d=` and `s=` tags in a DKIM signature](https://www.rfc-editor.org/rfc/rfc6376.html#section-3.5). A valid signature is only useful to DMARC when its signing domain aligns. If SPF passes but DMARC still fails, compare both identities before changing DNS. The [guide to DMARC failing while SPF passes](/learning/email-questions/why-is-dmarc-failing-but-spf-passes) covers that result pattern in more detail. ### SPF or DKIM fails for the affected sender SPF can fail because the sender uses an IP address or envelope domain that its published SPF policy does not authorize. DKIM can fail because the selector record is unavailable, the key cannot be used, or the received message does not verify against the signature. These are separate failures. Use the receiver's results to determine which mechanism needs repair. A published DNS record does not prove that an application selected that record, used the expected return path, or signed the message with the intended domain. ### A forwarded or modified message has different authentication evidence Forwarding can change the connection path, which can cause SPF failure because the forwarder's IP address is not authorized by the original envelope sender's SPF record. A message modified after DKIM signing can also verify differently at the recipient. This is an inference from the route until you compare the original delivery with the forwarded or modified copy. ### A DMARC record is absent or malformed A receiver cannot apply a domain's requested DMARC policy if it cannot retrieve and parse a valid DMARC record at the expected owner name. [RFC 9989 specifies the `_dmarc` DNS record location and record syntax](https://www.rfc-editor.org/rfc/rfc9989.html). A missing or malformed record is a DNS configuration problem. It is different from a message that fails SPF, DKIM, or alignment. > Do not lower or relax `p=` to treat a sender failure. That changes requested enforcement while leaving the failed sender unauthenticated or unaligned. ![DMARC repair decision flow for SPF, DKIM, alignment, and policy-record failures](/images/editorial/why-dmarc-fails-how-to-fix-it/why-dmarc-fails-how-to-fix-it-dmarc-repair-decision-flow.webp "1200x829") *Source: Palisade.* ## When this does not apply This failure workflow does not apply when the receiver reports `dmarc=pass`. One mechanism can fail while DMARC still passes through the other aligned mechanism. Diagnose the failed SPF or DKIM path only if that separate result matters to the sender or to another requirement. A missing or malformed DMARC record is also a different case from a message-level DMARC failure. Repair the public record first, then send a new message and inspect the receiver's result. Do not infer `dmarc=fail` from a DNS error alone. If the rejection names TLS, rate limiting, recipient status, message content, or a private reputation rule while the message shows `dmarc=pass`, changing SPF, DKIM, or the DMARC policy will not repair the named problem. Follow the evidence in the rejection and use this workflow only when the receiver actually reports a DMARC authentication or alignment failure. ## How do I diagnose the failure? ### 1. Preserve the receiver's message evidence Save the raw source of a message sent through the exact path that failed. Record the visible `From:` domain, the envelope sender where available, the `DKIM-Signature` `d=` and `s=` values, and the receiver-added `Authentication-Results`. Keep recipient addresses, message content, identifiers, and full headers out of shared tickets unless they are redacted. A rendered mailbox view can omit the fields needed to establish SPF and DKIM alignment. ### 2. Build a labelled failure evidence packet Collect one packet for each affected sender. It prevents a valid result from one application being mistaken for evidence about another. ```text Visible From domain: yourdomain.com SPF envelope domain and result: sender.example, pass DKIM d= domain, selector, and result: mailer.example, selector1, pass DMARC result, disposition, and alignment: fail, none, SPF unaligned; DKIM unaligned DMARC record owner and value: _dmarc.yourdomain.com, v=DMARC1; p=none Message ID and time: redacted message ID, UTC timestamp Sender application: approved sending application or service Report or receiver evidence: aggregate-report row, receiver Authentication-Results, or both ``` This is illustrative only. Do not publish real message IDs, recipient data, selectors, account-generated DNS targets, private keys, or tokens. The packet separates message evidence from the record a domain publishes. ### 3. Compare the identifiers that DMARC evaluates Use the identities in the failed message, then compare them with the visible `From:` domain. ```text Aligned example From: alerts@yourdomain.com SPF smtp.mailfrom: bounce.yourdomain.com DKIM header.d: yourdomain.com Unaligned example From: alerts@yourdomain.com SPF smtp.mailfrom: sender.example DKIM header.d: mailer.example ``` Under relaxed alignment, related organizational domains can align. Under strict alignment, the identifiers must match exactly. [RFC 9989 describes relaxed and strict identifier alignment](https://www.rfc-editor.org/rfc/rfc9989.html). ### 4. Identify the source in DMARC aggregate reports Find the aggregate-report row that matches the sending IP address, visible `From:` domain, and reporting interval. Record the reported SPF and DKIM results alongside the message evidence packet. Aggregate reports identify observed sources and outcomes. They do not provide every original message header, prove a receiver's private decision, or predict how a later message will be handled. The [DMARC learning hub](/learning/dmarc) explains how authentication, alignment, reports, and policy work together. ### 5. Check the relevant public DNS record When the evidence points to a missing, malformed, or unexpected DMARC record, inspect the published record for the domain with the [DMARC checker](/tools/dmarc). If the message identifies an SPF or DKIM DNS failure, inspect the record named by that message instead. A public check cannot prove which production application sent the message, which selector it used, or why one receiver made a particular delivery decision. Compare DNS results with the raw message before changing a sender setting. ### 6. Confirm the sending platform's status Check the affected platform's documented authentication status and configuration. Confirm its authenticated domain, return-path setup, and DKIM configuration where the platform exposes them. A green platform indicator is useful vendor evidence, but it is not a delivered-message check. If it conflicts with the receiver's raw message, investigate the actual account, route, or application that sent the failed mail. ## How do I fix it? ### Repair an SPF failure on the actual envelope sender When SPF fails, correct the authorized outbound path for the envelope sender domain shown in the receiver evidence. Use the sending application's generated instructions for its own domain and sending route. Then send a new message through that same application. This repair changes sender authentication. It does not change the DMARC policy. > Do not add a broad include mechanism or unrelated IP address without confirming that it belongs to the failing production path. An inaccurate SPF change can authorize mail you did not intend to authorize. ### Repair a DKIM failure for the signing path When DKIM fails, repair the selector lookup, public key publication, or signing configuration identified in the failed message. Publish only the selector record or CNAME target generated for your account by the sending platform. Do not copy a selector, key, or CNAME target from another tenant. A DNS lookup alone cannot prove that the application is signing new mail correctly. Retest with a new delivered message after the record is available. ### Configure an aligned sender identity When SPF or DKIM passes but neither aligns, configure the affected source to use an authenticated domain that aligns with the visible `From:` domain. For SPF, this may mean a custom return-path or MAIL FROM domain. For DKIM, it means signing with an aligned `d=` domain. This changes alignment and sender authentication. It does not change enforcement. The [DMARC rejection troubleshooting guide](/learning/email-rejected-per-dmarc-policy) explains how to handle a bounce after a receiver applies the published policy. ### Publish a valid DMARC record when it is absent or malformed When the DMARC record is missing or malformed, publish one valid record at `_dmarc.yourdomain.com`. Confirm the exact record against RFC 9989 and your domain's intended reporting and policy settings. ```text Illustrative only. Do not copy this value without choosing your own policy and reporting addresses. _dmarc.yourdomain.com TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com" ``` This repair changes reporting and requested enforcement behavior. It does not repair an SPF, DKIM, or alignment failure already shown in a message. ## How do I validate the repair? Validate the repair through the same application, route, content type, and recipient path that produced the failure. First, confirm the relevant record at the authoritative DNS provider and at least one public resolver. Next, check the sending platform's status for the affected domain. Then inspect the receiver-added `Authentication-Results` in a newly delivered production-path message. Confirm that SPF or DKIM passes and aligns with the visible `From:` domain. After aggregate-report data accumulates, check whether the same source continues to report DMARC failure. Keep the repaired message, DNS result, sender configuration change, and report evidence together. A passing DNS lookup or a green vendor status does not replace message-level validation. ## Check the published DMARC record behind this failure If the evidence packet points to a missing, malformed, or unexpected DMARC record, inspect the domain's public record before changing policy. This follows the DNS branch of the diagnosis, while the raw message still identifies whether SPF, DKIM, or alignment caused the failure. [Check the DMARC record](/tools/dmarc) A DMARC record check cannot prove the production sending path, repair a sender configuration, monitor future sources, or explain one receiver's private handling decision. For ongoing work, Palisade is agentic DMARC software. The agent investigates sources observed in aggregate reports, drafts fixes, and proposes each policy step. You approve before anything ships. When you approve a DNS change, [Smart DNS Deployment](/features/dns-deployment) writes the record into your own zone at your own provider. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=dmarc_troubleshooting&utm_content=why-dmarc-fails-how-to-fix-it) ## Sources and further reading - [RFC 9989: Domain-based Message Authentication, Reporting, and Conformance](https://www.rfc-editor.org/rfc/rfc9989.html) - [RFC 8601: Message Header Field for Indicating Message Authentication Status](https://www.rfc-editor.org/rfc/rfc8601.html) - [RFC 7208: Sender Policy Framework](https://www.rfc-editor.org/rfc/rfc7208.html) - [RFC 6376: DomainKeys Identified Mail Signatures](https://www.rfc-editor.org/rfc/rfc6376.html) - [Palisade DMARC checker](/tools/dmarc) ## Frequently asked questions ### Can DMARC fail when SPF passes? Yes. SPF must pass for an envelope sender domain that aligns with the visible `From:` domain. An SPF pass for an unrelated sending-service domain does not satisfy DMARC. ### Can DMARC pass when SPF fails? Yes. A message can pass DMARC through an aligned, passing DKIM signature even when SPF fails. The reverse is also true when aligned SPF passes. ### Does changing DMARC to p=none fix DMARC failure? No. Changing `p=` changes the receiver handling requested for messages that fail DMARC. It does not repair SPF authorization, DKIM verification, or identifier alignment. ### Does a valid DMARC record prove that messages pass DMARC? No. A valid record proves only that public DNS returns a parseable DMARC policy. Inspect a delivered message and later aggregate-report evidence to verify the actual sender path. ### Should I fix SPF or DKIM first? Only fix the mechanism identified by the failed message and source evidence. If one mechanism already passes and aligns, it can satisfy DMARC while you investigate the other mechanism. --- # Why do Google Group messages go to spam? Canonical: https://www.palisade.email/learning/why-do-google-group-messages-go-to-spam > Google Group mail fails for reasons ordinary mail does not, forwarding breaks SPF and rewriting breaks DKIM. How to tell which, and what to change. Google Group messages can go to spam for two different reasons: Google Groups may hold or reject the original post before distribution, or a recipient mailbox may filter a distributed copy into Spam. Start by establishing which happened. Then preserve the recipient's full headers and compare a direct delivery with the group-delivered copy before changing group settings, DNS, or the DMARC policy. ## Quick takeaways - A message in a Google Groups moderation queue was stopped before the group distributed it to members. - A conversation visible in the group can still be filtered by an individual recipient mailbox after distribution. - Google Groups moderation controls, sender authentication results, and a recipient's spam classification are separate signals. - The receiver-added `Authentication-Results` header is stronger evidence than the visible From address. - A passing DMARC result supports authentication but does not guarantee inbox placement. - Do not loosen the DMARC policy to address a Google Groups moderation or recipient-filtering result. ## What does the failure mean? Google Groups can apply spam handling to messages sent to a group. Its [group settings documentation](https://support.google.com/groups/answer/2464926?hl=en) describes options to reject messages marked as spam, send them for moderation, or post suspicious messages for eligible work or school groups. When a post is pending or rejected at this stage, members did not receive a normal distributed copy. ```text Reject all messages marked as spam ``` This is a Google Groups spam-handling option. Google notes that this setting can reject legitimate messages, so use the group's moderation state as the first piece of evidence rather than assuming a recipient mailbox filtered the message. If the conversation appears in the group archive and an affected member has the delivered copy in Spam, Google Groups distributed the post. The later result is the recipient mailbox's classification. Google does not publish a complete list of signals that map a message to one specific spam decision. Treat a single recipient's Spam placement as evidence about that mailbox and message path, not proof of a universal Google Groups rule. For indirect mail such as forwarding and mailing lists, [Google's Gmail sender guidelines](https://support.google.com/a/answer/81126?hl=en) distinguish direct mail from indirect mail flows. That guidance helps legitimate indirect mail authenticate, but it does not require inbox placement. ![Flow for separating Google Groups moderation, authentication evidence, and recipient spam classification](/images/editorial/why-do-google-group-messages-go-to-spam/why-do-google-group-messages-go-to-spam-decision-flow.webp "1200x829") *Source: Palisade.* ## What usually causes it? ### Google Groups held or rejected the original post This is the most likely cause when moderators can see the message in Pending, when the sender received a rejection, or when no member received a distributed copy. Google's [moderate messages documentation](https://support.google.com/groups/answer/2466386?hl=en) describes how moderators review and act on pending messages. A group-level setting changes how the group handles ingress. It does not repair the sender's SPF, DKIM, or DMARC results, and it does not control later recipient filtering. ### The group-delivered copy has different authentication evidence Mailing-list delivery is an indirect message path. SPF checks the SMTP envelope identity used for the delivery being evaluated, while DKIM verification depends on the signed message remaining valid. A remailing path can therefore produce different results from a direct copy. [DMARC RFC 9989](https://www.rfc-editor.org/rfc/rfc9989.html) describes the interoperability problem that indirect mail flows can create for SPF and DKIM authentication. If a direct message passes and the group copy fails, the group path is a reasonable inference to investigate. It does not, by itself, prove which system caused the difference. For broader context on trusted authentication assessments, see [what ARC is](/learning/what-is-arc). ARC can preserve earlier authentication results, but the receiving system decides whether to trust them. ### The recipient mailbox classified a distributed copy as spam A group can distribute a message successfully even if one recipient later finds it in Spam. Authentication may be valid, yet the recipient's mailbox can make a separate placement decision. Google's sender guidance does not promise delivery or inbox placement when its requirements are met. Compare results across affected recipients only to identify a repeatable pattern. Do not use those results to infer unpublished classifier logic. For a broader Gmail-focused workflow outside Google Groups, see [why emails go to spam in Gmail](/email-deliverability/why-are-my-emails-going-to-spam-in-gmail). ### The member's delivery preference explains the apparent absence Google Groups members can receive each message, a digest, no email, or another delivery mode depending on group and member settings. A message that appears in the group can be absent from a member's inbox without being a spam-placement event. Confirm the member's subscription and delivery preference before classifying the incident as filtering. ### The visible From address hides the identities actually evaluated The visible From address does not show the SMTP envelope domain used by SPF or the `d=` domain used by DKIM. [RFC 8601](https://www.rfc-editor.org/rfc/rfc8601.html) defines the `Authentication-Results` header field used to report message-authentication assessments. Use the receiver-added copy of that header, plus the return path and DKIM signature, to determine what the recipient system evaluated. ## How do I diagnose the failure? ### 1. Establish whether Google Groups distributed the message Record the group address, sender address, approximate sending time, subject, and Message-ID. Open the group with an account authorized to view moderation activity. Check whether the message is visible in the archive, Pending, or absent. If the message is pending, capture the moderation outcome and the relevant spam-handling setting. Google's [Workspace troubleshooting guidance for legitimate group mail marked as spam](https://knowledge.workspace.google.com/admin/support/troubleshooting/legitimate-email-to-a-group-marked-as-spam?hl=en) is the appropriate provider path for a Workspace group policy or moderation issue. ### 2. Preserve the affected recipient's original copy When the group distributed the message, preserve one affected recipient's copy in Spam. In Gmail on the web, use **More > Show original** to access full headers, following [Google's instructions for viewing full message headers](https://support.google.com/mail/answer/29436?hl=en). Capture the receiver-added `Authentication-Results`, all `Received` fields, `Message-ID`, `Date`, `From`, `Sender`, `Reply-To`, return path, and any DKIM or ARC fields. Redact addresses, internal hostnames, message content, and recipient data before sharing the packet. Keep an access-controlled original with the incident record. ### 3. Build a group-message evidence packet Use one labelled record per controlled test. This separates observable facts from conclusions about the cause. ```text Google Group message observation, illustrative and redacted Group address: announcements@yourgroup.example Sender address/domain: notices@yourdomain.com / yourdomain.com Message-ID and sent time: <redacted-message-id> / 2026-08-12 14:30 UTC Visible group outcome: Posted to archive, not pending Group and Workspace policy context: Spam handling setting recorded; moderator review not triggered Trusted receiver Authentication-Results: dmarc=pass; dkim=pass; spf=pass Relevant group setting or pending state: No pending item observed Controlled retest date: 2026-08-12 Recipient result: One test recipient placed the distributed copy in Spam ``` The packet has three distinct layers: - **Group moderation and spam controls:** whether Google Groups accepted, held, rejected, or posted the original message. - **Sender authentication evidence:** what the recipient's trusted `Authentication-Results` says about SPF, DKIM, and DMARC. - **Receiver classification:** where the recipient mailbox placed that specific distributed copy. Do not collapse these layers into one diagnosis. A group post can be accepted while a recipient filters it. A recipient can also see a spam result when SPF differs but aligned DKIM still supports DMARC. ### 4. Compare a direct message with the group-delivered copy Send the same approved test message directly to the affected recipient and through the Google Group. Keep the sender, visible From domain, content, and recipient mailbox the same where possible. Record a new evidence packet for each route. Compare the final receiver-added `Authentication-Results` fields. A difference narrows the investigation to the indirect delivery path. It does not prove the exact intermediary or justify changing DNS without further evidence. ![Comparison checklist for direct and Google Group message delivery paths](/images/editorial/why-do-google-group-messages-go-to-spam/why-do-google-group-messages-go-to-spam-google-group-delivery-comparison.webp "1200x524") *Source: Palisade.* ### 5. Classify the authentication result Use a trusted receiver-added header, not a copied header supplied by the sender. ```text Authentication-Results: recipient.example; spf=pass smtp.mailfrom=yourdomain.com; dkim=pass header.d=yourdomain.com; dmarc=pass header.from=yourdomain.com ``` This is an illustrative, redacted structure only. Do not publish an unredacted production header. If DKIM fails only on the group copy, investigate whether the signed message changed after signing. If SPF passes but its envelope domain does not align with the visible From domain, inspect the remailing path and whether aligned DKIM supports DMARC. If DMARC passes and the message still enters Spam, classify that as a recipient-placement result rather than an authentication failure. ## How do I fix it? ### Correct a confirmed group moderation or policy state When the evidence packet shows Pending, rejection, or a group-level spam action, review the documented Google Groups spam-handling and moderation settings with the group owner or Workspace administrator. Change only the setting connected to the observed state, then repeat the same controlled test. > Do not set a group to accept all suspicious messages merely to clear one incident. That can increase unwanted mail reaching members. This repair changes group ingress or moderation behavior. It does not change sender authentication or control a recipient's private spam classification. ### Repair a confirmed sender authentication mismatch When the group-delivered copy shows an authentication failure or loss of DMARC alignment that the direct copy does not show, trace the outbound and remailing path. Confirm the sending domain's published authentication records and compare the direct and indirect headers before changing configuration. A public [DMARC record check](/tools/dmarc) can inspect the current published DMARC record. It cannot prove which production message path Google Groups used, inspect full recipient headers, or explain why one recipient marked a copy as spam. Do not relax `p=` as a repair. Changing the DMARC policy changes requested enforcement. It does not make an altered DKIM signature valid or change a group moderation result. ### Isolate a repeatable group-specific result When messages are posted, authentication is as expected, and the same group route repeatedly reaches Spam for the same recipient context, preserve the evidence packets and retest with controlled changes to one approved variable at a time. Examples include message content, sender identity, recipient mailbox, and direct versus group delivery. Escalate the observed facts through the relevant Google Groups or Workspace support path when your organization has access to it. Do not present an escalation as a way to force inbox placement. ## How do I validate the repair? Repeat the same sender, group, recipient mailbox, content, and timing conditions used to capture the original evidence. First confirm the group outcome: posted, pending, or rejected. Then inspect the recipient's original delivered copy and record its trusted authentication results. Validate each applicable layer: - Check the published DNS record through the authoritative source and a public resolver when a DNS change was part of the repair. - Confirm the relevant Google Groups moderation or Workspace policy state. - Inspect a newly delivered message's receiver-added `Authentication-Results`. - Review DMARC aggregate reports after enough data accumulates to confirm the expected sending source and aligned authentication pattern. A successful retest shows that the confirmed problem changed under the same path. It does not guarantee future inbox placement or reveal the recipient provider's private classification logic. ## Track the sending sources behind the group delivery If the group route exposes inconsistent authentication results, first inspect the published DMARC record and compare it with the delivered-message evidence. Then determine whether the same domain has other production sending sources that need separate review. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=existing_content_migration&utm_content=why-do-google-group-messages-go-to-spam) to have Palisade analyze DMARC aggregate-report data, identify sending sources and authentication or alignment issues, and create prioritized remediation tickets for human review. Palisade does not control Google Groups moderation, change a recipient's spam decision, or guarantee inbox placement. The [vendor email authentication hub](/learning/esp-setup) has related provider-specific implementation and troubleshooting guidance. If the same sender also has Outlook placement issues, compare that incident with [how to stop emails going to spam in Outlook](/email-deliverability/how-to-stop-emails-going-to-spam-in-outlook) rather than assuming the recipient systems use the same decision. ## Sources and further reading - [Google Groups settings: spam handling options](https://support.google.com/groups/answer/2464926?hl=en) - [Google Groups moderation guidance](https://support.google.com/groups/answer/2466386?hl=en) - [Google Workspace troubleshooting for legitimate group email marked as spam](https://knowledge.workspace.google.com/admin/support/troubleshooting/legitimate-email-to-a-group-marked-as-spam?hl=en) - [Google Gmail sender guidelines](https://support.google.com/a/answer/81126?hl=en) - [RFC 8601: Authentication-Results header field](https://www.rfc-editor.org/rfc/rfc8601.html) - [RFC 9989: Domain-based Message Authentication, Reporting, and Conformance](https://www.rfc-editor.org/rfc/rfc9989.html) ## Frequently asked questions ### Does a Google Groups Pending message mean a recipient marked it as spam? No. A Pending message indicates a group moderation or spam-handling state before normal group distribution. Check whether members received a distributed copy before investigating recipient mailbox filtering. ### Can Google Groups break SPF or DKIM? Yes. A Google Groups delivery path can change the SMTP delivery context used for SPF, and indirect message handling can affect DKIM if a signed message changes. Compare the recipient's direct and group-delivered copies to identify the observed difference. ### Does DMARC pass guarantee that a Google Group message reaches the inbox? No. DMARC pass indicates that the receiver found aligned SPF or DKIM evidence under DMARC evaluation. A recipient mailbox can still make a separate placement decision. ### Should I change DMARC to `p=none` when Google Group messages go to spam? No. A DMARC policy change affects requested enforcement for unauthenticated mail. It does not repair group moderation, restore a broken DKIM signature, or control recipient spam classification. ### Can a public DMARC checker explain why one Google Group recipient received Spam? No. A public checker can inspect the published DMARC record. It cannot inspect the recipient's original message, Google Groups moderation history, the production sending path, or the recipient provider's private spam decision. --- # Why does Gmail show 'Looks safe' and hide images? Canonical: https://www.palisade.email/learning/why-does-gmail-show-a-looks-safe-banner-and-hide-images > Gmail shows 'Looks safe' and hides images when it treats a message or sender as suspicious. See what to inspect before trusting it or changing the sender. Gmail can show a "Looks safe" action and withhold external images when it treats a specific message or sender as suspicious. That observation does not identify one broken DNS record or expose Gmail's private safety logic. Preserve the affected message, verify the request outside email, inspect trusted authentication results and image-hosting evidence, then retest only the sending path that the evidence identifies. ## Quick takeaways - A Gmail safety banner is a message-specific observation, not proof of one DNS or DMARC failure. - Gmail can ask before showing external images because of an account setting or because a sender or message appears suspicious. - Do not select "Looks safe", open links, load images, or reply until the request is verified through a separate trusted channel. - Trusted `Authentication-Results` fields can show SPF, DKIM, DMARC, and ARC results, but they do not disclose Gmail's private classifier decision. - A public DNS check can confirm published records, but it cannot prove the production application used them or predict Gmail's future rendering decision. - Retest with a newly delivered message through the same route after correcting an observable sending or image-hosting issue. ## Scope and prerequisites Use this procedure for an affected Gmail message that shows a scam warning, a "Looks safe" action, hidden external images, or more than one of these conditions. Keep a known-good message from the same application or sending route when possible. You need the original message source or full headers, the exact Gmail observation, the visible From address, the sending application or gateway, and access to the relevant sender configuration and DNS zone. Record the owner of the sending route and the person authorized to approve a change. [Google's Gmail safety-warning guidance](https://support.google.com/mail/answer/1074268) explains that Gmail can warn about messages that look like scams, including messages from an address in a recipient's contacts. Google also says Gmail might not automatically show images when it considers a sender or message suspicious. Stop before making broad DNS or sender changes when the evidence does not identify the affected route. If a tested change creates fresh authentication failures, restore the previous known-good sender configuration. Do not lower a DMARC policy to try to remove a Gmail warning. For broader protection guidance, see the [Palisade email security learning hub](/learning). ## Choose the implementation approach Separate the evidence into three layers before choosing a repair: - Sender-controlled evidence: published SPF, DKIM, and DMARC records, sender configuration, authenticated domains, and image-host responses. - Gmail observation: the visible safety banner, image prompt, and behavior in a specific recipient account. - Private classifier logic: Gmail's unpublished internal decision process. The first two layers can be investigated. The third cannot be reconstructed from a message header or DNS lookup. Use the branch that matches the evidence: - If the request, links, attachment, or sender identity appears unsafe, verify it through a known phone number, bookmarked site, or newly composed message to a known address. Do not interact with the affected message. - If an image fails after the recipient chooses to display it, inspect the image URL's hosting, access control, TLS response, and availability. That is an image-delivery or rendering issue, not evidence of Gmail's safety rationale. - If trusted headers show an authentication mismatch, repair only the sender route that created it, then send a new test message. - If authentication passes and the same Gmail-specific result repeats, preserve the evidence and review message content, links, Reply-To handling, and image-hosting context. Google does not publish a complete cause-to-banner mapping. ## How to configure a sender-side investigation ### 1. Preserve the message and verify the request separately Ask the recipient not to select "Looks safe", open attachments, follow links, reply, or load images until the request is confirmed through a separate trusted channel. A familiar display name, contact entry, or existing thread does not establish that a message is safe. Record the exact warning, image behavior, visible From address, recipient account, and time. A cropped screenshot can document what Gmail displayed, but it cannot preserve the routing and authentication evidence required for a sender-side diagnosis. ### 2. Create a redacted message-and-rendering evidence record Export the original delivered message or full headers from the Gmail recipient. Do not rely on a forwarded copy because forwarding can add routing fields and change the evidence available to the receiver. Use a redacted record such as this: ```text message_id: <Message-ID value> received_at_utc: <UTC timestamp> visible_from: alerts@yourdomain.com reply_to: support@yourdomain.com return_path: bounce@mailer.yourdomain.com trusted_authentication_results: <receiver-added SPF, DKIM, DMARC, ARC results if available> authenticated_sender_domain: yourdomain.com image_url_context: https://images.yourdomain.com/... <do not open suspicious content> image_hosting_context: <public, authenticated, expired, blocked, or unknown> gmail_banner_observation: <exact displayed wording> gmail_image_observation: <exact prompt or hidden-image behavior> recipient_test_account: <redacted Gmail account or controlled test account> retest_date_utc: <UTC timestamp after any change> ``` This record separates sender-controlled facts from the Gmail observation. Do not copy private message content, recipient addresses, tracking parameters, credentials, tokens, or unredacted headers into a ticket shared outside the investigation. `Authentication-Results` is a receiver-added header field. [RFC 8601](https://www.rfc-editor.org/rfc/rfc8601.html) defines its syntax and says recipients should trust results added by the receiving system, rather than a similarly named field supplied by an untrusted sender. ![Redacted evidence triage record separating message authentication, image-hosting context, Gmail observations, and retest details](/images/editorial/why-does-gmail-show-a-looks-safe-banner-and-hide-images/why-does-gmail-show-a-looks-safe-banner-and-hide-images-evidence-triage.webp "1200x582") *Source: Palisade.* ### 3. Identify the image condition Ask whether the recipient's Gmail account is configured to ask before displaying external images for ordinary messages, or whether Gmail withheld images only for this sender or message. [Google's Gmail image settings guidance](https://support.google.com/mail/answer/145919) documents the account setting that asks before external images are shown. If Gmail displays images after the recipient allows them but an image is broken, inspect the image host separately. Check whether the URL requires a login, has expired, returns an error, or is blocked by a network control. Do not open a suspicious URL as part of the investigation. Use a known-safe administrative or hosting path to inspect the asset instead. ![Decision flow for separating a Gmail safety warning from image-setting, authentication, and image-hosting evidence](/images/editorial/why-does-gmail-show-a-looks-safe-banner-and-hide-images/why-does-gmail-show-a-looks-safe-banner-and-hide-images-gmail-safety-banner-investigation-flow.webp "1200x980") *Source: Palisade.* ### 4. Compare the delivered message with the intended sender Compare the visible From domain, Reply-To domain, return-path domain, DKIM `d=` domain, and sender route against the intended configuration for this message stream. Google documents how recipients can inspect sender details such as "Mailed by" and "Signed by" in [Gmail sender details](https://support.google.com/mail/answer/180707), though full original headers are stronger evidence for an operator. For DMARC, an aligned SPF or DKIM identifier must correspond to the visible From domain under the [DMARC alignment rules in RFC 9989](https://www.rfc-editor.org/rfc/rfc9989.html). An SPF pass for an unrelated return-path domain or a DKIM pass for an unrelated `d=` domain does not alone establish a DMARC-aligned pass. ### 5. Repair only an identified sending-path issue Apply a change only when the original message identifies a mismatch or failure. - For SPF, add authorization only for the legitimate service that sends with the affected envelope domain. Preserve existing mechanisms because SPF has one policy record for a domain. - For DKIM, publish the sender-generated record for the selector and signing domain used by the affected route. Do not invent a selector or copy a key from another account. - For DMARC, keep one valid policy record for the visible From domain. Use aggregate-report evidence before changing enforcement. - For image hosting, correct the specific access, expiration, TLS, or availability condition found in the controlled inspection. > Do not replace an existing SPF or DMARC record with an example record. A blind replacement can break authorization or reporting for other legitimate mail streams. An illustrative DMARC record shape is: ```text _dmarc.yourdomain.com TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com" ``` This is illustrative only. Use the existing record as the starting point and preserve its legitimate tags and reporting destinations. A DMARC rollout should begin with monitoring, then move to quarantine and reject only when aggregate-report evidence shows that legitimate sources authenticate and align. ## How to validate the setup Validate the repaired route at four separate layers: - DNS: query the affected domain against its authoritative DNS server and at least one public resolver. Confirm the intended SPF, DKIM, or DMARC record answers without removing existing valid records. The [Palisade DMARC checker](/tools/dmarc) can help confirm the published record. - Sender: check the relevant application, ESP, or gateway authentication status for the exact sending domain and selector. A green vendor indicator does not prove a delivered message used that setting. - Message: send a new test message through the same application, account, and gateway. Inspect receiver-added `Authentication-Results`, visible From, return-path, Reply-To, and DKIM `d=` values. - DMARC: after reports accumulate, verify that the source IPs and identifiers for the repaired route pass and align in aggregate-report data. Use a controlled Gmail test account when practical. Compare the result with the affected message and with a known-good message from the same stream. A new successful message confirms only the path tested. It does not explain every past Gmail safety decision or guarantee future inbox placement. If the corrected message still shows a warning or hidden images despite passing authentication, record that result without claiming the protocol repair failed. The remaining issue may be message content, destination links, image-hosting context, recipient account settings, or Gmail's unpublished safety decision. ## Troubleshooting ### Gmail hides images for all ordinary messages Check the recipient account's image-display setting first. [Google's image-display instructions](https://support.google.com/mail/answer/145919) distinguish an account preference to ask before displaying external images from a message-specific safety decision. This is a recipient-side setting, so changing sender DNS will not alter it. ### Gmail hides images only for one sender or message Preserve the exact warning and compare the message with a known-good message from the same sender. Check trusted headers, visible identity, Reply-To handling, links, and image-host access. Treat any conclusion about Gmail's private classifier as an inference because Google does not publish a complete mapping of message features to safety warnings. ### SPF or DKIM passes but DMARC fails Compare the authenticated identifiers with the visible From domain. DMARC needs an aligned SPF or DKIM pass, not only a passing result. Review the `smtp.mailfrom` value for SPF and the DKIM `header.d` value where the receiver reports them. ### The image URL works for an administrator but not a recipient Check whether the image host requires a session cookie, signed URL, private network access, or a non-expired token. Test through the controlled recipient context without opening a suspicious message URL. Correct the image-host condition separately from the Gmail safety investigation. ### A DNS checker passes but Gmail still shows the banner A DNS result only confirms what public DNS returned at the time of the check. It cannot show which application sent the message, whether that application signed it, Gmail's private decision, or future rendering behavior. Return to the original delivered message and compare it with the test message from the exact production route. ## Inspect the headers behind the Gmail warning Use the original message headers to inspect the identity and authentication evidence before changing DNS. [Palisade's email header analyzer](/tools/email-header-analyzer) is appropriate when you have a redacted raw header from the affected message. [Inspect the email headers](/tools/email-header-analyzer) A header analysis cannot prove why Gmail showed a safety warning, test the recipient's image setting, repair image hosting, or predict a future Gmail decision. If the same domain has recurring sources that fail authentication or alignment after the immediate issue is understood, Palisade is agentic DMARC software that analyzes DMARC aggregate-report data, identifies sources and authentication or alignment issues, and creates prioritized remediation tickets. It can propose the next policy step when evidence supports it, while a human reviews the evidence and applies any DNS or DMARC policy change. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=existing_content_migration&utm_content=why-does-gmail-show-a-looks-safe-banner-and-hide-images) Palisade does not change Gmail's private safety decision, automatically change a DMARC policy, prove every future message will authenticate, or guarantee inbox placement. ## Sources and further reading - [Google Gmail safety warnings](https://support.google.com/mail/answer/1074268) - [Google Gmail image-display settings](https://support.google.com/mail/answer/145919) - [Google Gmail sender details](https://support.google.com/mail/answer/180707) - [RFC 8601: Message Authentication Status](https://www.rfc-editor.org/rfc/rfc8601.html) - [RFC 9989: Domain-based Message Authentication, Reporting, and Conformance](https://www.rfc-editor.org/rfc/rfc9989.html) - [Palisade email header analyzer](/tools/email-header-analyzer) ## Frequently asked questions ### Does a "Looks safe" banner mean my DMARC record is broken? No. A Gmail safety banner is a message-specific Gmail observation. Inspect the receiver-added authentication results and the exact sending path before changing SPF, DKIM, or DMARC records. ### Can Gmail hide images because of a recipient setting? Yes. Gmail has an account setting that asks before external images are shown. Check whether the behavior affects ordinary messages from several senders before treating it as a sender-side incident. ### Should a recipient click "Looks safe" to test the message? No. Verify the request through a trusted channel first. Do not use the suspicious message's links, attachments, reply controls, or image controls to establish whether it is legitimate. ### Can passing SPF and DKIM still leave a DMARC problem? Yes. A DMARC pass needs an aligned SPF or DKIM identifier. A passing result for an unrelated envelope domain or DKIM signing domain does not by itself create an aligned DMARC pass. ### Can a public DNS check explain Gmail's safety warning? No. Public DNS can show the records published for a domain. It cannot prove the production application used those records, disclose Gmail's private classifier logic, or predict future Gmail rendering behavior. --- # Mailchimp SPF record: when do you need one? Canonical: https://www.palisade.email/learning/why-does-mailchimp-dmarc-alignment-not-require-adding-mailchimp-to-spf > Mailchimp DMARC alignment can pass through aligned DKIM without Mailchimp in SPF. Inspect headers, verify DNS, and validate the sending path. Mailchimp DMARC alignment does not require adding Mailchimp to the visible From domain's SPF record when the delivered message has a passing DKIM signature aligned with that From domain. DMARC can pass through either aligned SPF or aligned DKIM. Mailchimp may use a separate envelope domain for SPF, while its authenticated sending domain supplies the aligned DKIM result. ## Quick takeaways - DMARC needs one passing aligned identifier, either DKIM or SPF. - SPF checks the SMTP envelope domain, commonly shown as `smtp.mailfrom`, rather than the visible From domain. - A passing SPF result can be unaligned and still coexist with a DMARC pass through aligned DKIM. - Mailchimp's manual email-domain authentication flow provides DKIM CNAME records and a DMARC TXT record. - Adding Mailchimp to an SPF record does not change a campaign's SPF result when the campaign uses a separate Mailchimp-controlled envelope domain. - A DMARC pass for one delivered message does not prove future inbox placement or another receiver's private delivery decision. ## What does the failure mean? The apparent failure is the assumption that Mailchimp must appear in the SPF record for `yourdomain.com` before a Mailchimp campaign can pass DMARC. That combines two separate identities. DMARC evaluates alignment against the visible From domain, while SPF evaluates the SMTP envelope domain. [RFC 9989 defines DMARC evaluation using the RFC5322.From domain and aligned SPF or DKIM results](https://www.rfc-editor.org/rfc/rfc9989.html). A passing DKIM signature whose `d=` domain aligns with the visible From domain can satisfy DMARC even when SPF passes for a different envelope domain. Use a receiver-added `Authentication-Results` field as the starting evidence. [RFC 8601 defines this header field and its authentication-method properties](https://www.rfc-editor.org/rfc/rfc8601.html). ```text Authentication-Results: receiver.example; spf=pass smtp.mailfrom=mailchimp.example; dkim=pass header.d=yourdomain.com; dmarc=pass header.from=yourdomain.com ``` This fragment is illustrative and redacted. It shows SPF passing for `mailchimp.example`, which does not align with `yourdomain.com`, and DKIM passing for `yourdomain.com`, which does align. The aligned DKIM result supplies the DMARC pass. ![Sender-path evidence packet showing the visible From domain, envelope domain, DKIM signing domain, SPF result, and DMARC result needed to diagnose Mailchimp alignment](/images/editorial/why-does-mailchimp-dmarc-alignment-not-require-adding-mailchimp-to-spf/why-does-mailchimp-dmarc-alignment-not-require-adding-mailchimp-to-spf-sender-path-evidence.webp "1200x600") *Source: Palisade.* ![Mailchimp DMARC alignment decision flow showing aligned DKIM satisfying DMARC when SPF uses a separate envelope domain](/images/editorial/why-does-mailchimp-dmarc-alignment-not-require-adding-mailchimp-to-spf/sender-path-alignment-flow.webp "1200x522") *Source: Palisade.* Create a sender-path evidence packet before changing DNS: - **Visible From domain:** Record the domain after `@` in the message's visible From address, such as `yourdomain.com`. - **Mailchimp sending-domain context:** Record whether that private domain is authenticated in the relevant Mailchimp account and product. - **Envelope-domain evidence:** Record `smtp.mailfrom=` or the Return-Path value when the receiver exposes it. - **DKIM evidence:** Record every `dkim=` result and its `header.d=` domain. - **SPF evidence:** Record the `spf=` result and the domain it evaluated. - **DMARC outcome:** Record `dmarc=pass` or `dmarc=fail`, plus `header.from=`. - **Message identity:** Keep the Message-ID, delivery time, recipient provider, and campaign or sending route in an access-controlled record. - **Mailchimp setup status:** Record the current official Mailchimp domain-authentication status for the sending domain. This packet identifies which authenticated identifier actually supplied the DMARC result. It does not prove why a recipient placed the message in the inbox, spam folder, or rejected it for a separate policy reason. ## What usually causes it? ### SPF is being compared with the visible From domain [SPF evaluates the RFC5321.MailFrom identity when it is available](https://www.rfc-editor.org/rfc/rfc7208.html#section-2.3). The visible From address is a message-header identity, so it does not become the SPF identity because it is the address recipients see. If a Mailchimp campaign uses a Mailchimp-managed envelope domain, editing the SPF record at `yourdomain.com` does not change the SPF evaluation for that envelope domain. The received headers determine whether that is the path in use. ### An unaligned SPF pass is being treated as a DMARC failure An SPF pass can be valid without aligning with the visible From domain. It cannot supply DMARC alignment in that case, but [DMARC permits an aligned DKIM pass to satisfy evaluation](https://www.rfc-editor.org/rfc/rfc9989.html). Under relaxed alignment, related domains can align when they share an organizational domain. Under strict alignment, the authenticated domain must exactly match the visible From domain. The active DMARC record determines which alignment mode applies. ### Mailchimp domain authentication is incomplete or unverified [Mailchimp's email-domain authentication instructions](https://mailchimp.com/help/set-up-email-domain-authentication/) describe an automated Microsoft Entra ID option and a manual setup path. The manual path provides two DKIM CNAME records and one DMARC TXT record. Those instructions establish the setup method, but they do not prove the `header.d=` domain on a specific campaign. Confirm that from a newly delivered message sent through the same Mailchimp route. ### A second SPF or DMARC TXT record was added [SPF specifies that multiple SPF records at one domain produce `permerror`](https://www.rfc-editor.org/rfc/rfc7208.html#section-3.2). Adding a second DMARC policy record can also create an invalid or ambiguous setup instead of repairing alignment. > Do not publish a second SPF TXT record or a second DMARC TXT record. Find the existing record first and change it only when the sending path and documented configuration require it. ### A valid SPF result is being mistaken for a DMARC pass A message can show `spf=pass` and `dmarc=fail` when the SPF domain does not align and DKIM does not provide an aligned pass. This is a protocol result, not evidence that Mailchimp must always be added to the visible domain's SPF record. The repair depends on the delivered identities. Treat a conclusion about a different Mailchimp product, account, or sending route as an inference until its message headers confirm it. ## When this answer does not apply This answer does not apply when the delivered message has no aligned DKIM pass and must rely on SPF alignment. If `dkim=fail` or the passing `header.d=` domain is unaligned, inspect `smtp.mailfrom` and the Mailchimp account's current domain-authentication state. If the received headers show that SPF passes for an aligned envelope domain, that SPF result can supply the DMARC pass. It also does not apply to another sending platform just because that platform uses a provider-owned return path. Each service can choose different DKIM and envelope-domain behavior. Preserve a message from the exact product and account route before changing DNS. This is also not an inbox-placement repair. A message can pass DMARC through aligned Mailchimp DKIM and still be filtered for reputation, content, complaint, or receiver-policy reasons. In that case, adding Mailchimp to SPF does not address the observed result. ## How do I diagnose the failure? ### 1. Preserve a message from the exact Mailchimp sending path Send a new test campaign through the same Mailchimp product, authenticated From domain, audience type, and configuration used in production. Open the raw source in the receiving mailbox, then save the complete headers in an access-controlled incident record. Record the `From`, Return-Path when present, `Authentication-Results`, Message-ID, delivery time, and recipient provider. A rendered mailbox view hides the header fields needed to distinguish SPF from DKIM alignment. ### 2. Identify the aligned passing identifier Compare the domains in the received message with the visible From domain. ```text Visible From: newsletter@yourdomain.com SPF identity: smtp.mailfrom=mailchimp.example DKIM identity: header.d=yourdomain.com DMARC result: dmarc=pass header.from=yourdomain.com ``` This is illustrative only. If `header.d=yourdomain.com` passes and aligns with the visible From domain, Mailchimp does not need SPF alignment for that message's DMARC pass. [RFC 6376 defines how a receiver verifies a DKIM signature using the signing domain and selector](https://www.rfc-editor.org/rfc/rfc6376.html#section-6.1). If DKIM passes but `header.d=` does not align, inspect the active DMARC record for relaxed or strict alignment before changing anything. ### 3. Verify Mailchimp's published authentication records In the Mailchimp account that sent the campaign, open the official email-domain authentication setup and compare its account-generated DNS values with authoritative DNS. Mailchimp's documented manual flow uses DKIM CNAME records and a DMARC TXT record. Copy names and targets only from the account that owns `yourdomain.com`. Use the [DMARC checker](/tools/dmarc) to inspect the published DMARC policy. Use the [SPF checker](/tools/spf) to inspect the public SPF record before adding or removing an authorization. Public DNS checks show what resolvers can retrieve. They do not prove that Mailchimp signed a particular campaign, used a particular envelope domain, or that a receiver will make the same decision for future mail. ### 4. Take the safe branch for the observed evidence If the domain is unverified or unauthenticated in Mailchimp, complete Mailchimp's documented domain-authentication setup and wait for the vendor's status to confirm it. Then send a fresh test through the same path. Do not copy DKIM values from another Mailchimp account or domain. If DKIM does not align, compare `header.d=` with the visible From domain and the applicable DMARC alignment mode. Repair the domain-authentication configuration that Mailchimp generated for the actual From domain. Do not change `p=` to hide the result. A DMARC policy change affects requested enforcement, not the message's DKIM alignment. If DMARC fails while SPF is valid, determine whether `smtp.mailfrom` aligns with the visible From domain. If it does not, valid SPF alone cannot supply DMARC alignment. Check whether a DKIM signature passes and aligns, then correct the verified authentication path rather than forcing an unrelated SPF include into the visible domain's record. ### 5. Check SPF only when the actual sending path needs it Do not add a hosted SPF mechanism for Mailchimp merely because a campaign needs DMARC alignment. Add or change SPF only when the actual envelope-domain setup and Mailchimp documentation require it. If the SPF record has an actual DNS-lookup-limit condition, investigate that condition separately. [RFC 7208 limits SPF evaluation to ten DNS-querying terms](https://www.rfc-editor.org/rfc/rfc7208.html#section-4.6.4). A lookup-limit repair does not establish Mailchimp DKIM alignment and should not be treated as one. For a comparison of a provider path that does not supply SPF alignment by default, see [why Brevo does not provide SPF alignment by default](/learning/brevo-spf-alignment). ## How do I fix it? ### Complete Mailchimp authentication for the actual From domain When the Mailchimp domain-authentication status is incomplete, use the records generated in that Mailchimp account for the private domain used in the campaign. Publish the provided DKIM CNAME records exactly, then confirm the vendor's current status. > Do not replace an existing DMARC policy with a Mailchimp example value without reviewing the current policy and its reporting addresses. A DMARC record controls requested receiver handling and reporting. This repair changes DNS authentication configuration. It does not guarantee that every future message will authenticate or that a recipient will place mail in the inbox. ### Correct the DKIM alignment path When the receiver's headers show a passing but unaligned `header.d=`, make the Mailchimp authenticated sending domain match the intended visible From domain according to the applicable alignment mode. Validate with a new message, not only a green vendor status. Do not relax strict alignment as a first response. That changes the DMARC policy's alignment requirement. It does not correct an unverified or incorrect Mailchimp domain-authentication setup. ### Remove duplicate records, not needed authorizations When the public DNS evidence shows duplicate SPF or DMARC TXT records at the same owner name, consolidate records only after identifying their owners and sending systems. Preserve any authorization used by another approved sender. This repair changes published DNS. Retest every known sender that depends on the changed record. ## How do I validate the repair? Send a fresh Mailchimp campaign through the same authenticated From domain and product route. Confirm the following four layers: - **DNS:** Check the authoritative DNS response and at least one public resolver for the Mailchimp-generated DKIM records and the single intended DMARC record. - **Vendor:** Confirm Mailchimp's domain-authentication status for the exact sending domain. - **Message:** Inspect the receiver-added `Authentication-Results` field. Confirm `dkim=pass`, record `header.d=`, and confirm that it aligns with `header.from=`. - **DMARC:** Confirm the delivered message reports `dmarc=pass`, then review DMARC aggregate reports after data accumulates to see whether the same source continues to authenticate as expected. Repeat the test with the production template, links, audience configuration, and recipient provider that exposed the question. A passing minimal test does not prove the full production path. ## Check the DMARC record behind the Mailchimp result After comparing the delivered headers, inspect the published DMARC policy for the visible From domain. This confirms the alignment mode and policy currently visible in DNS before you change Mailchimp authentication or SPF. [Check the DMARC record](/tools/dmarc) A public DMARC record check cannot inspect a Mailchimp campaign's envelope domain, prove which DKIM signature reached a recipient, monitor the sending path, or explain a recipient's private placement decision. If Mailchimp is one of several sending sources for the domain, Palisade's agent investigates sources observed in aggregate DMARC reports, drafts fixes, and proposes each policy step. You approve before anything ships. When you approve a DNS change, [Smart DNS Deployment](/features/dns-deployment) writes the record into your own zone at your own provider. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=email_authentication&utm_content=why-does-mailchimp-dmarc-alignment-not-require-adding-mailchimp-to-spf) Palisade does not ship a DMARC policy change without approval, repair every sender, or prove that a future Mailchimp campaign will authenticate or reach the inbox. For broader DMARC policy and alignment context, visit the [DMARC learning hub](/learning/dmarc). ## Sources and further reading - [Mailchimp: Set up email domain authentication](https://mailchimp.com/help/set-up-email-domain-authentication/) - [RFC 9989: Domain-based Message Authentication, Reporting, and Conformance](https://www.rfc-editor.org/rfc/rfc9989.html) - [RFC 6376: DomainKeys Identified Mail signatures](https://www.rfc-editor.org/rfc/rfc6376.html) - [RFC 7208: Sender Policy Framework](https://www.rfc-editor.org/rfc/rfc7208.html) - [RFC 8601: Authentication-Results header field](https://www.rfc-editor.org/rfc/rfc8601.html) ## Frequently asked questions ### Does Mailchimp need to be in my SPF record for DMARC to pass? No. DMARC can pass when Mailchimp produces a passing DKIM signature aligned with the visible From domain, even if SPF passes for a separate envelope domain. ### Can SPF pass while DMARC fails for a Mailchimp campaign? Yes. SPF can pass for an envelope domain that does not align with the visible From domain. If DKIM also fails or does not align, DMARC can fail. ### Does a green Mailchimp authentication status prove DMARC passes? No. Mailchimp's status confirms its setup state, but the delivered message's receiver-added authentication results show whether DKIM, SPF, and DMARC passed on that sending path. ### Should I add another SPF TXT record for Mailchimp? No. Publishing multiple SPF records at the same domain can cause an SPF `permerror`. Inspect the existing SPF record and the delivered campaign headers before making a supported change. ### Will an aligned Mailchimp DKIM signature guarantee inbox placement? No. An aligned DKIM pass can satisfy DMARC, but mailbox providers make separate reputation and delivery decisions. --- # Why Mailchimp email goes to spam after marked delivered Canonical: https://www.palisade.email/learning/why-does-mailchimp-email-go-to-spam-after-it-is-marked-delivered > Why Mailchimp email goes to spam after marked delivered: separate accepted delivery from mailbox placement, inspect headers, and retest safely. Mailchimp email can go to spam after it is marked delivered because Mailchimp's delivered status means the recipient did not register a hard or soft bounce. It does not prove the receiving mailbox placed the accepted message in the inbox. Start with the delivered copy from the affected mailbox, inspect its trusted authentication and receiver evidence, repair the confirmed sender-side issue, and retest through the same Mailchimp path. ## Quick takeaways - Mailchimp counts a recipient as successfully delivered when that recipient did not register a [hard or soft bounce](/learning/soft-bounce-vs-hard-bounce-email). - Accepted delivery, a mailbox folder observation, and a receiver's private spam classification are different kinds of evidence. - A message in one recipient's spam folder does not by itself prove a campaign-wide Mailchimp, domain, or reputation problem. - Inspect the received message's `Authentication-Results` field before changing DNS or Mailchimp settings. - SPF, DKIM, and DMARC passing can narrow authentication problems, but they do not guarantee inbox placement. - Retest with the same sending domain, campaign path, recipient provider, and comparable audience scope. ## What does the failure mean? Mailchimp's [email campaign report documentation](https://mailchimp.com/help/about-email-campaign-reports/) defines successful deliveries as recipients who did not register a hard or soft bounce. Its [Delivery Insights documentation](https://mailchimp.com/help/about-delivery-insights/) uses this delivery status after campaign sending completes: ```text Your campaign has been delivered ``` That status shows Mailchimp completed delivery without recording a hard or soft bounce for the recipient. It does not show where a receiving system displayed the message. [RFC 5321 explains SMTP reply completion behavior](https://www.rfc-editor.org/rfc/rfc5321.html#section-4.2.5): after a receiving SMTP server accepts a message, it takes responsibility for it. The receiving environment can then apply filtering, mailbox rules, quarantine handling, or organization policy. A sender may see no bounce because the receiver did not reject the message during SMTP. Keep these observations separate: - **Accepted delivery:** Mailchimp did not record a hard or soft bounce for the recipient. - **Mailbox folder observation:** A recipient or administrator found the accepted message in Inbox, Spam, Junk, Quarantine, or another folder. - **Receiver classification:** The receiving provider's private filtering decision and its reasons. A sender cannot establish that decision from Mailchimp's delivered status alone. The [vendor email authentication hub](/learning/esp-setup) covers related sender-platform setup and validation. For this incident, the strongest starting evidence is the raw source of a message from the affected recipient. ![Flow showing that Mailchimp delivery status confirms no recorded bounce, while mailbox placement requires evidence from the receiving environment](/images/editorial/why-does-mailchimp-email-go-to-spam-after-it-is-marked-delivered/why-does-mailchimp-email-go-to-spam-after-it-is-marked-delivered-delivery-placement-flow.webp "1200x829") *Source: Palisade.* ## What usually causes it? ### Recipient-specific filtering or mailbox rules When one recipient finds a campaign in spam while comparable recipients receive it normally, begin with mailbox-specific evidence. Ask the recipient or mail administrator to inspect mailbox rules, local allow and block lists, quarantine, and any security tooling that handled the accepted message. This pattern does not prove the campaign has a broad reputation problem. It is an inference from the observed scope, and the recipient provider may expose more evidence in its own administrative tools. ### A recipient domain quarantined the campaign Mailchimp's [campaign reporting documentation](https://mailchimp.com/help/about-email-campaign-reports/) notes that a domain administrator may quarantine a message when most recipients use the same domain. If the issue appears at one company domain, request the receiving administrator's message trace, quarantine evidence, transport-rule evidence, and gateway verdict for the delivered copy. A Gmail mailbox, a Microsoft 365 tenant, and a corporate filtering gateway can apply different controls. The sender should not infer one receiver's reason from another receiver's result. For Microsoft-specific recipient evidence, see [how to stop emails going to spam in Outlook](/email-deliverability/how-to-stop-emails-going-to-spam-in-outlook). ### The production message does not authenticate as expected Mailchimp distinguishes [email domain verification from authentication](https://mailchimp.com/help/set-up-email-domain-authentication/). Verification confirms access to an email address. Authentication requires DNS records for the sending domain and can improve delivery. An authenticated domain setting is useful vendor evidence, but it is not a delivered-message check. Inspect the received message before changing DNS. [RFC 8601 defines the `Authentication-Results` field](https://www.rfc-editor.org/rfc/rfc8601.html), which receiving systems use to report authentication results. For DMARC, SPF or DKIM must pass with an identifier aligned to the visible From domain. A standalone `spf=pass` or `dkim=pass` does not establish alignment. ### Authentication is clean, but recipient signals remain negative Google's [email sender guidelines](https://support.google.com/mail/answer/81126) require SPF or DKIM for all senders to personal Gmail accounts. Google requires bulk senders to use SPF, DKIM, and DMARC, align the From domain with SPF or DKIM for direct mail, keep spam rates below its published threshold, and support one-click unsubscribe for eligible marketing and subscribed messages. Google states that authentication makes messages less likely to be rejected or marked as spam. It does not guarantee inbox placement. If authentication evidence is clean, compare the affected campaign with a recent healthy campaign. Review audience permission, campaign scope, send volume, subject, template, URLs, and abuse-report evidence in Mailchimp's campaign reporting. ## How do I diagnose the failure? ### 1. Preserve one delivered copy from the affected recipient Get the full source of a message that the recipient found in spam or quarantine. Do not diagnose from a forwarded copy because forwarding can change the route and authentication evidence. Record the visible From address, recipient provider, delivery time, campaign reference, and whether comparable recipients received the same campaign elsewhere. Redact recipient addresses, message content, and tracking identifiers before sharing evidence outside the organization. ### 2. Classify the delivery and placement scope Compare the affected result with a small permission-based cohort at the same provider and at another provider. Use the same Mailchimp audience type, From identity, authenticated sending domain, and campaign stream. Use these safe next-action branches: - **Bounced or not delivered:** Treat this as a delivery failure, not a spam-placement incident. Preserve the exact bounce evidence and investigate the receiving SMTP response or Mailchimp reporting evidence before changing authentication settings. - **One provider or company domain:** Ask that recipient provider's administrator for trace, quarantine, and policy evidence. Do not infer its private filtering reason from a public DNS result. - **Repeatable spam placement across providers after authentication evidence is clean:** Compare the affected campaign with a healthy one and narrow the changed audience, message, URL, send pattern, or permission signal. Authentication does not prove why a receiver classified a message as spam. For a broader Gmail-specific workflow, see [why emails go to spam in Gmail](/email-deliverability/why-are-my-emails-going-to-spam-in-gmail). ### 3. Inspect trusted authentication evidence in the received message Use an [email header analyzer](/tools/email-header-analyzer) to find the receiver-added `Authentication-Results` field. Also inspect the visible `From` domain, `DKIM-Signature` domain and selector, `Return-Path`, `Received` fields, and provider-specific anti-spam or quarantine headers where present. This is an illustrative, redacted observation record. Do not publish header values from a real message. ```text Campaign/message ID: redacted Sending domain: yourdomain.com Authenticated identifiers: DKIM d=yourdomain.com; SPF smtp.mailfrom=mail.yourdomain.com Mailchimp delivery/bounce status: delivered, no recorded hard or soft bounce Recipient/provider observation: recipient found message in Spam Timestamp: 2026-08-12T14:30:00Z Test cohort/scope: 1 of 5 permission-based test recipients at receiver.example Header evidence: Authentication-Results: receiver.example; spf=pass smtp.mailfrom=mail.yourdomain.com; dkim=pass header.d=yourdomain.com; dmarc=pass header.from=yourdomain.com Retest date: pending ``` The record is an evidence packet, not proof of inbox placement. It links the Mailchimp delivery status to the exact message and recipient observation, while preserving the receiver's private classification as unknown unless its administrator provides it. ### 4. Confirm the Mailchimp sending domain and public DNS state Follow [Mailchimp's email domain authentication instructions](https://mailchimp.com/help/set-up-email-domain-authentication/) for the exact domain used in the campaign. Check the vendor's current authentication status, then compare its configured identity with the received message's From, SPF, and DKIM identifiers. Use the [DMARC checker](/tools/dmarc) to inspect the public DMARC record for the visible From domain. A public DNS check can show the record published at the time of the lookup. It cannot prove the production sending path, the receiver's private classification, continuous DNS state, or future inbox placement. > Do not loosen `p=` to treat spam placement as fixed. A DMARC policy change affects requested enforcement. It does not alter a recipient's mailbox rule, quarantine decision, or private spam classification. ![Checklist showing the evidence packet for a Mailchimp delivered-but-spam observation, including campaign status, headers, recipient evidence, and same-path retest](/images/editorial/why-does-mailchimp-email-go-to-spam-after-it-is-marked-delivered/why-does-mailchimp-email-go-to-spam-after-it-is-marked-delivered-evidence-packet.webp "1200x696") *Source: Palisade.* ## How do I fix it? ### Repair a confirmed authentication or alignment problem If the received production message shows failed SPF, DKIM, or DMARC, correct the specific DNS or sender configuration identified by that message. Follow Mailchimp's documented domain-authentication path for its vendor configuration, then verify the resulting message through the same campaign path. This repair changes authentication or alignment. It does not guarantee a recipient will put later messages in the inbox. ### Address a confirmed recipient-domain quarantine path If a receiving-domain administrator confirms quarantine, transport policy, or a security-gateway action, work with that administrator on the evidence from the exact accepted message. Keep the change limited to the confirmed path, such as correcting an allow or block policy where the receiving organization authorizes it. The sender cannot change another receiver's private policy without that receiver's authority. ### Compare the changed campaign condition When authentication passes and spam placement repeats across the test cohort, compare the affected campaign with a recent healthy campaign. Change one confirmed variable at a time, such as audience segment, template, URLs, subject, or send scope. Preserve the prior configuration so the test can be rolled back. Do not present a reduced DMARC policy as a remedy. That changes enforcement reporting and handling, not recipient placement. ## How do I validate the repair? Send a new campaign or approved test message through the same Mailchimp account, authenticated domain, From identity, content path, and recipient-provider cohort. Update the evidence packet with the new campaign reference, timestamp, Mailchimp delivery or bounce status, mailbox observation, raw header evidence, and retest date. Validate each applicable layer: - **DNS:** Confirm the published DMARC record with the authoritative DNS operator and a public resolver. - **Vendor:** Confirm Mailchimp shows the intended sending domain as authenticated under its documented workflow. - **Message:** Inspect the receiver-added `Authentication-Results` field from a newly delivered message on the exact production path. - **DMARC:** Review aggregate-report data after it has accumulated to identify whether sources using the From domain authenticate and align as expected. A green vendor indicator is not enough. A passing DNS record is not enough. The repaired path needs a newly received message and a repeatable observation from the relevant recipient scope. ## Check the DMARC record behind the Mailchimp sending domain After you have preserved the delivery and placement evidence, inspect the public DMARC record for the visible From domain. This helps identify a published-record problem before changing policy and gives you a baseline for comparing the received message's alignment evidence. [Check the DMARC record](/tools/dmarc) A DMARC record check cannot explain one receiver's private spam decision, repair a Mailchimp campaign, monitor later sender changes, or guarantee inbox placement. If recurring Mailchimp and other sending sources make it hard to maintain the evidence packet across domains, [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=vendor_email_authentication&utm_content=why-does-mailchimp-email-go-to-spam-after-it-is-marked-delivered). Palisade is agentic DMARC software that analyzes DMARC aggregate-report data, identifies sending sources and authentication or alignment issues, and proposes prioritized remediation work for human review. It does not control a receiver's private spam classification or guarantee delivery or inbox placement. ## Sources and further reading - [Mailchimp: About email campaign reports](https://mailchimp.com/help/about-email-campaign-reports/) - [Mailchimp: About Delivery Insights](https://mailchimp.com/help/about-delivery-insights/) - [Mailchimp: Set up email domain authentication](https://mailchimp.com/help/set-up-email-domain-authentication/) - [RFC 8601: Authentication-Results header field](https://www.rfc-editor.org/rfc/rfc8601.html) - [Google email sender guidelines](https://support.google.com/mail/answer/81126) ## Frequently asked questions ### Does Mailchimp marked delivered mean the message reached the inbox? No. Mailchimp's delivered status means it did not record a hard or soft bounce for that recipient. The receiving environment may still place the accepted message in Spam, Junk, Quarantine, or another folder. ### Can a Mailchimp message go to spam when DMARC passes? Yes. A passing DMARC result shows that the received message met DMARC authentication and alignment conditions. It does not reveal or override the receiver's private spam classification. ### Should I change DMARC to `p=none` if Mailchimp email goes to spam? No. Changing `p=` changes the domain's requested DMARC handling. It does not repair a recipient mailbox rule, a receiving-domain quarantine action, or a sender reputation signal. ### What evidence should I collect from a recipient who reports spam placement? Collect the campaign or message reference, sending domain and authenticated identifiers, Mailchimp delivery or bounce status, recipient-provider observation, timestamp, test-cohort scope, full headers or bounce evidence when available, and a retest date. ### Can a public DNS checker tell me why one Mailchimp message went to spam? No. A public checker can inspect the current published DNS record. It cannot inspect the exact production sending path, a receiver's private filtering logic, or the folder placement of an individual message. --- # Why does my DKIM signature fail alignment and how can I fix it? Canonical: https://www.palisade.email/learning/why-does-my-dkim-signature-fail-alignment > DKIM signature alignment fails when a passing DKIM d= domain does not align with the visible From domain. Inspect headers, fix signing identity, and. A DKIM signature fails alignment when the domain in the signature's `d=` tag does not align with the visible `From:` domain under the receiving domain's DMARC alignment mode. The DKIM signature can still be valid. Start with the delivered message's trusted authentication results, identify the sender behind the observed signing domain, configure its domain-authentication option where available, then retest the same production path. ## Quick takeaways - A `dkim=pass` result proves that one DKIM signature verified. It does not prove that the signature aligns for DMARC. - DMARC compares the visible `From:` domain with the DKIM signing domain, represented as `header.d` in receiver authentication results. - Relaxed DKIM alignment permits an organizational-domain match, including an aligned subdomain. Strict alignment requires an exact match. - A provider-owned `d=` domain is a common reason for a valid but unaligned DKIM signature. - A missing or invalid DKIM signature is a verification problem first. Do not treat it as an alignment-only problem. - Retest with a new message through the same application and review DMARC aggregate reports after traffic accumulates. ## What does the failure mean? [DMARC uses the domain in the RFC 5322.From field as the identifier that must align with an authenticated SPF or DKIM identifier](https://www.rfc-editor.org/rfc/rfc9989.html#section-3.1). For DKIM, that authenticated identifier is the signing domain in the `d=` tag. A receiver can record its evaluation in an `Authentication-Results` header using the syntax defined by [RFC 8601](https://www.rfc-editor.org/rfc/rfc8601.html). This illustrative, redacted fragment shows a valid DKIM signature that cannot satisfy DMARC through DKIM alignment: ```text Authentication-Results: receiver.example; dkim=pass header.d=mailer.example.net header.s=selector1; dmarc=fail header.from=yourdomain.com ``` The `dkim=pass` result means the receiver verified the signature according to the DKIM verification process in [RFC 6376](https://www.rfc-editor.org/rfc/rfc6376#section-6.1). It does not mean `mailer.example.net` aligns with `yourdomain.com`. In this example, it does not. A compact comparison makes the distinction clear: ```text Unaligned, illustrative only Visible From domain: yourdomain.com DKIM d= domain: mailer.example.net DKIM result: pass DKIM alignment: fail Aligned under relaxed alignment, illustrative only Visible From domain: yourdomain.com DKIM d= domain: mail.yourdomain.com DKIM result: pass DKIM alignment: pass ``` The DMARC record's `adkim` tag controls DKIM alignment. With relaxed alignment, the signing domain and visible From domain need the same organizational domain. With `adkim=s`, the domains must match exactly. RFC 9989 specifies relaxed alignment as the default when `adkim` is absent. The [email authentication learning hub](/learning) explains how DKIM, SPF, and DMARC work together. ![Alignment evidence packet showing the From domain, DKIM d= domain, selector, receiver results, sender application, and DNS record owner](/images/editorial/why-does-my-dkim-signature-fail-alignment/why-does-my-dkim-signature-fail-alignment-evidence-packet.webp "1200x733") *Source: Palisade.* ## What usually causes it? ### A third-party sender signs with its own domain A marketing platform, support system, billing service, or application can sign mail with a provider-owned domain by default. That signature may verify successfully, but it cannot align with your visible From domain unless the provider-owned domain is related to it. When `header.d` is a provider domain, the usual next step is that service's custom-domain authentication or custom DKIM setup. Use the service's current documentation and DNS values generated for your account. Do not reuse another account's selector, CNAME target, or TXT value. ### Custom DKIM is not active on the failing route One service can use different signing identities for separate message streams, regions, accounts, or sending products. If a passing message and a failing message have different `header.d` or `header.s` values, that supports an inference that they took different signing paths. It does not prove a specific provider setting is wrong. Compare the failing message with a known-good message sent by the same application. Identify the application and route before changing DNS. ### The visible From domain changed A template, brand, or application configuration can change the visible From domain while the signer continues to use the previous domain. A valid signature for `oldbrand.example` does not align with `yourdomain.com`. Choose the intended visible From domain and the DKIM signing domain, then make them align under the policy you intend to publish. This repairs identity alignment. It does not repair a broken cryptographic signature. ### Strict DKIM alignment is configured If your DMARC record contains `adkim=s`, `mail.yourdomain.com` does not align with `yourdomain.com`. That same pair can align under relaxed mode. [RFC 9989 defines strict alignment as an exact-domain comparison](https://www.rfc-editor.org/rfc/rfc9989.html#section-3.1). Treat this as a policy decision. If strict alignment is intentional, configure the sender to sign with the exact visible From domain, or use a visible From domain that matches the intended signer. ### The message is unsigned or the DKIM signature is invalid Alignment is evaluated only after DKIM verification produces a passing authenticated identifier. A message with no DKIM signature, or one reported as `dkim=fail`, has a DKIM verification issue before it has a usable DKIM alignment path. Use the receiver-added result as evidence. The message's `DKIM-Signature` header is a sender claim, while [RFC 8601 describes authentication results as assertions made by the receiving system that added the field](https://www.rfc-editor.org/rfc/rfc8601.html#section-7.1). For failed verification, follow the separate [DKIM fail troubleshooting guide](/learning/glossary/dkim-fail). ## How do I diagnose the failure? ### 1. Preserve the receiver's authentication evidence Open the raw source of a message sent through the exact failing production path. Save the full message in an access-controlled incident record. Redact recipient addresses, content, identifiers, and routing details before sharing it outside the team. Record the receiver-added `Authentication-Results` header, the visible `From:` address, each `DKIM-Signature` header, Message-ID, sending time, recipient provider, and sending application. Do not diagnose alignment from the rendered message alone. ### 2. Build an alignment evidence packet Use a labelled packet so the signing identity, policy, and route can be compared without losing the message-level evidence: ```text Alignment evidence packet, illustrative only Visible From domain: yourdomain.com DKIM d= domain: mailer.example.net DKIM selector s=: selector1 DKIM result: pass DMARC result/disposition: fail / reject Observed identifier comparison: mailer.example.net does not align with yourdomain.com Expected aligned identifier: yourdomain.com or an aligned subdomain when adkim=r Message ID and time: <redacted Message-ID>, <UTC timestamp> Sending application: <identified application or provider> DNS record owner name: selector1._domainkey.mailer.example.net ``` ![DKIM alignment diagnosis flow from authentication results to sender configuration and retesting](/images/editorial/why-does-my-dkim-signature-fail-alignment/why-does-my-dkim-signature-fail-alignment-dkim-alignment-diagnosis-flow.webp "1200x856") *Source: Palisade.* The DNS record owner name is derived from the selector and signing domain, not from the visible From domain. It tells you where a verifier looks for the public key. It does not prove which application generated the signature. ### 3. Compare the visible From domain with `header.d` Check whether the observed signing domain matches the visible From domain exactly, or shares its organizational domain when relaxed alignment applies. Then inspect the published DMARC record for `adkim`. Use a public [DMARC checker](/tools/dmarc) to inspect the current record syntax and policy tags. A public DNS check cannot prove that the delivered message used that record, explain one receiver's private decision, or monitor later changes. > Do not change the DMARC policy to hide an alignment failure. Lowering `p=` changes requested enforcement. It does not make the sender's DKIM identity align. ### 4. Identify the service that owns the signing domain Map each observed `header.d` domain to the application, ESP, relay, or service that sent that message class. Use application logs, campaign metadata, outbound relay records, and the message's `Received` chain. Do not infer ownership from a selector name alone. If the message contains multiple DKIM signatures, compare each passing `header.d` value with the visible From domain. DMARC can use a passing aligned DKIM identifier. One passing unaligned signature does not prevent another signature from satisfying DKIM alignment. ### 5. Check the selector as a separate DNS question Once you know the observed selector and signing domain, use the [DKIM checker](/tools/dkim) to inspect whether the corresponding public DKIM record resolves. A selector lookup helps distinguish a missing or malformed public key from an alignment problem. It cannot inspect the delivered message, access the private key, prove that the production sender used the selector, or explain why a particular receiver handled a message in a particular way. ### 6. Inspect aggregate reports after the message check After message evidence identifies the route, review DMARC aggregate reports to see whether the same source repeatedly produces unaligned results. Aggregate reports help establish the scope of a source problem, but they do not replace raw headers for an individual failure. If the receiver reports signature verification failure instead of an alignment mismatch, investigate that evidence with [DKIM signature verification failed guidance](/learning/smtp-error-codes/dkim-signature-verification-failed). ## How do I fix it? ### Configure domain DKIM for the sender with the wrong signing domain When the evidence packet shows a provider-owned or unrelated `d=` domain, enable that sender's custom-domain DKIM or domain-authentication feature if it supports one. Publish only the selector-specific DNS values generated for your account, then wait for the sender's own verification status before retesting. Many providers use CNAME records and others use TXT records. The record type is provider-specific. This repair changes the DKIM signing identity. It does not change DMARC enforcement or guarantee inbox placement. ### Align the subdomain configuration with the DMARC policy When the sender signs with `mail.yourdomain.com` and the visible From domain is `yourdomain.com`, check `adkim`. Under relaxed alignment, the pair can align. Under strict alignment, configure the sender to sign with the exact visible From domain if that is supported and required by your policy. Changing `adkim` is a DMARC policy decision, not a substitute for understanding the sender inventory. Make the decision only after confirming the production paths that rely on the domain. ### Repair an unsigned or invalid DKIM path before retesting alignment If the message has no passing DKIM result, identify why the service did not sign or why verification failed. Check the sender's domain-authentication status, the selector record, and the complete delivered message. [RFC 6376 verification requires the verifier to retrieve and use the relevant public key](https://www.rfc-editor.org/rfc/rfc6376#section-6.1). Do not regenerate keys or change records solely because alignment failed. Rotate or replace a key only when separate evidence establishes a key or verification problem. ## How do I validate the repair? Send a new message through the same application, account, template, route, and recipient provider that produced the failure. Check the receiver-added authentication result for `dkim=pass`, confirm that `header.d` aligns with `header.from` under the published `adkim` mode, and confirm the reported DMARC result. Validate all four relevant layers: - DNS: confirm the selector record through the authoritative DNS provider and at least one public resolver. - Vendor: confirm that the identified sender reports the domain or DKIM configuration as verified. - Message: inspect a newly delivered message from the exact repaired production path. - DMARC: review aggregate reports after sufficient traffic has accumulated. A green sender status is not proof that every production route signs correctly. A passing public DNS lookup is not proof of the delivered message's signing identity. ## Track alignment failures across your sending sources After the message-level repair, use Palisade to identify sources and authentication or alignment issues in DMARC aggregate-report data, then create prioritized remediation tickets for the remaining sources. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=email_authentication&utm_content=why-does-my-dkim-signature-fail-alignment) Palisade can analyze reported DMARC traffic and help prioritize alignment work, but it does not change your DMARC policy, repair every sender automatically, or prove a future message will authenticate or reach the inbox. ## Sources and further reading - [RFC 6376: DomainKeys Identified Mail signatures](https://www.rfc-editor.org/rfc/rfc6376) - [RFC 9989: Domain-based Message Authentication, Reporting, and Conformance](https://www.rfc-editor.org/rfc/rfc9989.html) - [RFC 8601: Authentication-Results header field](https://www.rfc-editor.org/rfc/rfc8601.html) - [Palisade DMARC checker](/tools/dmarc) - [Palisade DKIM checker](/tools/dkim) ## Frequently asked questions ### Can DKIM pass but still fail DMARC alignment? Yes. `dkim=pass` means a signature verified, while DMARC also requires the signing domain to align with the visible From domain unless aligned SPF satisfies DMARC instead. ### Does a subdomain align with the parent domain for DKIM? Only under relaxed DKIM alignment. `mail.yourdomain.com` can align with `yourdomain.com` when `adkim=r` or when `adkim` is absent. With `adkim=s`, the domains must match exactly. ### Will changing DMARC to `p=none` fix DKIM alignment? No. Changing `p=` changes the DMARC policy's requested handling. It does not change the DKIM `d=` domain, the visible From domain, or their alignment. ### Should I fix the DNS key if the DKIM signature is valid but unaligned? No. A valid signature shows that the receiver could verify that signature. First configure the sender to use an aligned signing domain, unless the evidence packet also identifies a separate selector or verification problem. ### Can a DKIM checker prove my production messages align? No. A DKIM checker can inspect a public selector record. It cannot inspect the exact delivered message, prove which signing identity the application used, or determine a receiver's private handling decision. --- # Why do my emails land in Gmail's Promotions tab? Canonical: https://www.palisade.email/learning/why-emails-land-in-gmail-promotions-tab > Why emails land in Gmail's Promotions tab: classify the delivered message, test one sender-controlled change, and validate the same sending path. Emails land in Gmail's Promotions tab because Gmail categorizes delivered mail using documented broad signals: who sent it, its content type, and how Gmail users interact with similar messages. Promotions placement is an observed Gmail outcome, not proof that the message failed authentication or that every recipient sees a deliverability problem. First separate promotional mail from operational mail, then test one sender-controlled variable through the same production path. ## Quick takeaways - Gmail describes Promotions as a category for deals, offers, and other promotional email. - A message in Promotions was delivered to Gmail. It was not rejected or automatically placed in spam. - Gmail says category sorting considers the sender, message content, and Gmail user interaction with similar messages. - Gmail does not publish its complete category-classification logic or a sender control that guarantees Primary placement. - Test the exact production stream, not a manually sent substitute message. - Public DNS checks can confirm published authentication records but cannot explain Gmail's private category decision. ## What does the failure mean? The symptom is a delivered message that Gmail displays in the Promotions tab when the sender expected a different category, often Primary. [Gmail's category documentation](https://support.google.com/mail/answer/3094499) describes Promotions as mail for "deals, offers, and other promotional emails." Gmail also provides Primary, Social, Updates, and Forums categories. Google describes the inputs to Gmail category sorting as: ```text who the email comes from, what type of content is in the message and how Gmail users have interacted with similar content ``` [Google's explanation of Gmail sorting](https://workspace.google.com/blog/productivity-collaboration/how-gmail-sorts-your-email-based-on-your-preferences) says direct recipient input is the most important signal. A recipient can move a message to Primary, reply when a reply makes sense, or add the sender to contacts. This category is a receiver outcome. It does not prove a universal deliverability failure, a DMARC failure, spam placement, or a rejected message. Google has not published a complete weighting system, so a claim that one word, image, link, or email platform caused a specific classification is an inference unless a controlled retest isolates it. ![Decision flow for separating a single Gmail category observation from a repeatable sender-path test and an authentication investigation](/images/editorial/why-emails-land-in-gmail-promotions-tab/why-emails-land-in-gmail-promotions-tab-triage.webp "1200x676") *Source: Palisade.* ## What usually causes it? ### The message is promotional by purpose A newsletter, product offer, sale announcement, or campaign can fit Gmail's documented Promotions category. In that case, no technical repair may be appropriate. Measure the outcome that matters for the campaign rather than treating Promotions placement as an authentication incident. ### The message contains marketing-oriented content Google says Gmail considers the type of content in a message. A campaign layout, offer language, many calls to action, product imagery, or a large marketing footer are reasonable test variables for an operational message. Google does not document a fixed list of triggers or a threshold for category placement. Remove only marketing content that does not belong in the affected transactional or personal stream. Do not redesign a legitimate campaign solely to pursue a Primary placement that Gmail does not guarantee. ### One sender identity is used for unrelated streams Google says the sender is one category signal. If the same visible From identity or domain sends newsletters, receipts, password resets, and personal correspondence, it can be harder to interpret a category observation. Google does not require separate domains or streams, so separating streams is an operational test, not a documented Gmail rule. Map the application, visible From address, envelope sender where available, DKIM signing domain, and route for each message type. A password reset from one service is not evidence about a newsletter sent through another. ### Recipient behavior differs Gmail says interaction with similar content affects sorting, and direct recipient input matters most. The same sender can therefore appear in different categories for different recipients. A recipient who wants a message in Primary can move a representative message there, reply where appropriate, or add the sender to contacts. Those are recipient preferences. They are not sender-side controls that can be imposed across a mailing list. ### An authentication mismatch is a separate failure Promotions placement does not establish an authentication problem, but a raw delivered message may show one. If the trusted receiving system reports DKIM or SPF failure, or DMARC failure, investigate that evidence separately. [Palisade's ESP authentication setup hub](/learning/esp-setup) provides context for provider-specific authentication work. ## How do I diagnose the failure? ### 1. Preserve the delivered-message evidence Use the Gmail message that showed the symptom. Record the visible From address, recipient test account, subject, Gmail category, timestamp, message purpose, and the application or campaign that generated it. Keep complete source and headers in an access-controlled incident record. The raw message helps identify the production path. It also distinguishes a delivered category observation from a test message sent through a different route. ### 2. State the recipient task Write down what the recipient should do with this message. A promotion or newsletter may belong in Promotions. A receipt, confirmation, reminder, or automated account notification may be more comparable to Gmail's Updates category, which [Gmail's category definitions](https://support.google.com/mail/answer/3094499) describe separately. The goal is a category that matches the message's purpose and recipient expectation. It is not automatically Primary. ### 3. Create an observation-and-retest record Use one record per observed message and preserve it through the retest. Separate sender-controlled evidence from Gmail factors that are private or recipient-specific. ```text Illustrative redacted observation record Campaign or message ID: txn-password-reset-2026-08-12-01 Sender domain: yourdomain.com Visible From address: accounts@yourdomain.com Authenticated identifiers observed: DKIM d=yourdomain.com; SPF domain recorded from headers Recipient test account: qa-gmail@example.net Observed Gmail category: Promotions Observed timestamp: 2026-08-12T10:15:00-04:00 Message format and promotion context: HTML password-reset notice; no offer copy; one reset link Official Gmail category context: Gmail says sorting considers sender, content type, and interaction with similar content Retest date: pending ``` The message format, copy, sender identity, and route are evidence the sender can control or document. Gmail's category model, recipient history, and the relative weighting of signals are private classifier factors. Record them as unknowns rather than assigning a cause. ![Illustrative record showing the sender-controlled evidence to retain and the Gmail factors that remain private](/images/editorial/why-emails-land-in-gmail-promotions-tab/why-emails-land-in-gmail-promotions-tab-observation-record.webp "1200x639") *Source: Palisade.* ### 4. Choose the safe next branch For a single-user observation, treat it as one recipient outcome. Confirm the message was delivered, record the category, and avoid changing an entire production template based on one mailbox. For a repeatable test pattern, use controlled test accounts and send through the same application, visible From identity, authenticated domains, and route. Keep the recipient type and core message purpose constant. Change one sender-controlled variable at a time, such as unnecessary promotional copy or a nonessential marketing footer. For an authentication mismatch, preserve the exact trusted `Authentication-Results` values from the delivered message. Do not infer authentication from category placement. A category result and an authentication result answer different questions. ### 5. Check public DNS only when the question is DNS If the message evidence points to a missing or unexpected published DMARC record, use the [DMARC checker](/tools/dmarc) to inspect the public record for the sending domain. If a header identifies a DKIM selector that needs confirmation, use the [DKIM checker](/tools/dkim). A public DNS check can show the record currently visible to public resolvers. It cannot prove that the sending application used that domain, that the delivered message authenticated, why Gmail assigned a category, or how future messages will be placed. ## How do I fix it? ### Keep legitimate promotional mail in Promotions When the message is a deal, offer, newsletter, or campaign, treat Promotions as an expected category unless a tested business requirement shows otherwise. Do not weaken DMARC policy or alter authentication because a delivered promotional message appears in Promotions. Those changes address different problems. ### Remove irrelevant promotional material from operational mail For an account notice, confirmation, receipt, or password-reset email, remove only content that is unrelated to the recipient's task. Test one revision through the same production sender and route. > Do not remove security instructions, legal content, or required account details merely to change a Gmail category. Preserve the recipient task and test the smallest supported change. This repair changes message content. It does not control Gmail's private classification decision. ### Separate streams as a measured operational change If one identity sends both campaigns and operational mail, consider using separately managed streams after documenting the existing route and expected authentication. This is a testable operational change, not a Gmail requirement. Before changing a sender identity, verify that the new production path has its own approved authentication configuration. Changing a visible From address, envelope sender, or DKIM signing domain can create an authentication mismatch if the route is incomplete. ### Repair confirmed authentication failures separately When delivered-message headers show a failure, diagnose that failure from the header evidence and the relevant sending path. A DMARC policy relaxation is not a fix for a DKIM or SPF configuration issue. It changes requested enforcement, while the technical repair restores the failed authentication or alignment condition. ## How do I validate the repair? Resend through the same application, sender identity, route, recipient type, and message purpose that produced the original observation. Update the observation-and-retest record with the new message ID, timestamp, category, and any sender-controlled change. Validate applicable layers independently: - DNS: Confirm the relevant public DMARC or DKIM record only if the repair changed DNS. - Vendor: Check the sending provider's current authentication status if the provider supplies one. - Message: Inspect a newly delivered message's trusted authentication results and confirm it used the intended production identifiers. - DMARC: Review aggregate-report data after it accumulates to identify whether the source authenticates and aligns as expected. A repeated category result across comparable controlled tests is useful operational evidence. It still does not reveal Gmail's complete classifier or guarantee the category for other recipients. ## Check the DMARC record behind the sending domain If your evidence includes the sending domain, inspect its published DMARC record before mixing a category observation with a DNS problem. [Check the DMARC record](/tools/dmarc) A record check cannot prove why Gmail placed one delivered message in Promotions, confirm the application used the record, or guarantee future placement. When a team needs to track which production sources authenticate and align over time, [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=deliverability&utm_content=why-emails-land-in-gmail-promotions-tab). Palisade analyzes DMARC aggregate-report data, identifies sources and authentication or alignment issues, and proposes next policy steps for human review. It does not control Gmail's private category decisions or guarantee Primary placement. ## Sources and further reading - [Gmail inbox categories](https://support.google.com/mail/answer/3094499) - [Google Workspace: How Gmail sorts email based on preferences](https://workspace.google.com/blog/productivity-collaboration/how-gmail-sorts-your-email-based-on-your-preferences) - [Palisade DMARC checker](/tools/dmarc) - [Palisade DKIM checker](/tools/dkim) - [RFC 9989: Domain-based Message Authentication, Reporting, and Conformance](https://www.rfc-editor.org/rfc/rfc9989.html) ## Frequently asked questions ### Does Promotions mean Gmail marked my email as spam? No. Promotions is an inbox category for delivered mail. Spam placement is a separate receiver outcome and needs different evidence. ### Can I force every email into Gmail Primary? No. Gmail does not publish a sender setting that guarantees Primary placement. Recipient interaction and private Gmail classification factors affect the result. ### Should transactional emails always appear in Primary? No. A transactional message may be categorized differently depending on its purpose and recipient preferences. First verify that the message is delivered, appropriate to its recipient task, and authenticating through the intended production path. ### Can a DMARC record move an email out of Promotions? No. A DMARC record supports authentication policy and reporting. It does not select Gmail's inbox category or explain an individual Gmail categorization decision. ### What should I do after one Gmail user reports Promotions placement? Only record the delivered-message evidence, confirm the message purpose, and avoid broad changes based on one recipient. Use comparable controlled tests if the issue repeats. ### What if the Gmail message has an authentication failure? Inspect the trusted delivered-message authentication results and diagnose the specific SPF, DKIM, or DMARC failure. Promotions placement alone does not establish the cause. --- # Why is phishing so effective? Canonical: https://www.palisade.email/learning/why-is-phishing-so-effective > Phishing works by pairing trusted-looking context with pressure and a simple requested action. Learn how to interrupt the decision safely. Phishing is effective because it combines a believable pretext with pressure and a simple action, often before the recipient has time to verify the request. CISA describes phishing as social engineering that lures people to disclose credentials or visit a malicious site. A message that appears to come from a known company, colleague, or service can make that request seem routine. The safest interruption is to pause and verify through a contact method or website you already trust. ## Quick takeaways - A familiar name, logo, or business event can make a message look plausible at a glance. - Urgency is meant to shorten the time available for checking the story. - The requested action is usually small: click a link, open a file, sign in, or send information. - Sender authentication can reduce direct domain spoofing, but it does not decide whether a message's content is deceptive. - Independent verification breaks the attacker's control of the conversation. ![Decision points that interrupt a phishing request](/images/editorial/why-is-phishing-so-effective/phishing-decision-points.svg "1200x600") *Source: Original deterministic decision graphic based on [CISA phishing guidance](https://www.cisa.gov/sites/default/files/2025-03/Phishing%20Guidance%20-%20Stopping%20the%20Attack%20Cycle%20at%20Phase%20One%20508.pdf).* ## Why a plausible message can persuade people Phishing is a form of social engineering. In its phishing guidance, [CISA explains](https://www.cisa.gov/sites/default/files/2025-03/Phishing%20Guidance%20-%20Stopping%20the%20Attack%20Cycle%20at%20Phase%20One%20508.pdf) that attackers use a lure to obtain credentials or deploy malware. The message does not need to be technically complicated. It needs to create a credible reason for the recipient to take the next step. That reason often fits a familiar workflow: a delivery notice, an account problem, an invoice, a document to review, or a request from someone with apparent authority. The [FTC's examples of phishing tactics](https://consumer.ftc.gov/articles/how-recognize-avoid-phishing-scams) include suspicious activity, payment problems, unexpected invoices, and requests to confirm personal or financial information. These cues make a message feel like an ordinary task rather than a security decision. The pressure matters because it narrows attention. An attacker may claim that an account will be locked, a payment is overdue, or a security event needs immediate attention. The FTC advises people to slow down and use a known contact method rather than the information in an unexpected message. That step changes the problem from judging a convincing email to confirming a request through an independent channel. ## Why technical checks do not settle the question Email authentication has an important but limited role. [DMARC](/learning/what-is-dmarc) can help a domain owner tell receiving systems what to do with messages that fail aligned SPF and DKIM checks. The [current DMARC core specification, RFC 9989](https://www.rfc-editor.org/rfc/rfc9989.html), defines that alignment and policy scope. Its companion standards, [RFC 9990](https://www.rfc-editor.org/rfc/rfc9990.html) and [RFC 9991](https://www.rfc-editor.org/rfc/rfc9991.html), separately define aggregate and failure reporting. DMARC is useful against direct impersonation of that domain. It cannot decide whether every delivered message is honest. A phishing message can come from a lookalike domain, a compromised legitimate account, or an attacker-controlled domain that has its own valid authentication. That is why [a phishing email can pass SPF and DKIM](/learning/why-do-phishing-emails-pass-spf-and-dkim). Authentication answers questions about a sending domain and signed message path. It does not validate a payment request, a link destination, or the sender's claimed purpose. This distinction also explains why [email spoofing](/learning/what-is-email-spoofing-and-how-can-you-prevent-it) is only one part of phishing. Spoofing can make a lure more convincing, but a sender does not need to spoof a domain to make a deceptive request. Treat technical signals as evidence, not as permission to skip verification. ## Use a pause-and-verify routine When a message asks you to click, sign in, open an attachment, send money, or disclose information, use the requested action as the trigger for a check. Do not reply through the same thread or use the phone number and link supplied in the message. The FTC specifically recommends contacting the organization through information you already know is real. ### 1. Stop before the requested action Read the request as a security decision, especially when it asks for credentials, payment details, an attachment, or an urgent response. Do not click a link merely to see whether it is legitimate. ### 2. Verify through an independent route Open a saved bookmark, type the organization's known web address, or contact the person through an established phone number or separate conversation. If the request is real, that route should confirm it without relying on the suspicious message. ### 3. Report and preserve the right evidence Use your organization's reporting process or your mailbox provider's phishing-reporting option. Preserve the message according to that process. If someone entered credentials, sent information, or opened a harmful file, escalate it as a possible incident rather than treating it as routine spam. When you report the message, a short record helps keep the verification decision separate from the attacker-controlled thread: ```text Claimed sender: the person or organization named in the message Requested action: click, sign in, open, pay, or send information Independent route used: known website, contact record, or separate conversation Possible exposure: credentials, payment details, approval, file, or information ``` ## Check a suspicious destination without opening it If you need to inspect a destination, copy the link rather than visiting it and use a checker as one input to your reporting decision. [Check a suspicious link with Palisade](/tools/phishing-link-checker) A link check cannot prove that a message is safe or replace your organization's incident-response process. ## Sources and further reading - [CISA: Phishing Guidance, Stopping the Attack Cycle at Phase One](https://www.cisa.gov/sites/default/files/2025-03/Phishing%20Guidance%20-%20Stopping%20the%20Attack%20Cycle%20at%20Phase%20One%20508.pdf) - [FTC: How To Recognize and Avoid Phishing Scams](https://consumer.ftc.gov/articles/how-recognize-avoid-phishing-scams) - [IETF RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance](https://www.rfc-editor.org/rfc/rfc9989.html) - [IETF RFC 9990: DMARC Aggregate Reporting](https://www.rfc-editor.org/rfc/rfc9990.html) - [IETF RFC 9991: DMARC Failure Reporting](https://www.rfc-editor.org/rfc/rfc9991.html) ## Frequently asked questions ### Is phishing effective only when a sender spoofs a trusted domain? No. Direct domain spoofing can make a message look convincing, but phishing can also use lookalike domains, compromised accounts, or attacker-owned domains. The decisive risk is the deceptive request and the action it tries to obtain. ### Can phishing still work when SPF and DKIM pass? Yes. SPF and DKIM evaluate aspects of the sending path and message authentication. They do not determine whether a message's content, payment request, or link destination is honest. Verify an unexpected request independently. ### Why do phishing messages create urgency? Urgency is meant to make a recipient act before checking the request. The FTC advises slowing down and contacting the purported sender through a known website or phone number instead of using details in the unexpected message. ### What should you do if you clicked a phishing link? Report the message through your organization's security process promptly. If you entered credentials, change them through a known legitimate route and follow the incident-response instructions for your organization or mailbox provider. ### Does a phishing link checker guarantee that a website is safe? No. A checker can add evidence about a destination, but it cannot prove a message is legitimate, inspect every attachment, or replace the reporting and incident-response process your organization uses. --- # Why should MSPs offer email security services? Canonical: https://www.palisade.email/learning/why-should-msps-offer-email-security-services > Why should MSPs offer email security services? Build a repeatable client workflow for sender evidence, ownership, remediation, approvals, and reviews. MSPs should offer email security services when they can deliver a repeatable operating process across clients, rather than an undefined security add-on. The service should establish domain scope, sender evidence, ownership, approval paths, exceptions, and client reviews. That gives each client a defensible way to assess email authentication work while keeping DNS changes, sender configuration, and business-risk decisions with the parties that control them. ## Quick takeaways - An MSP email security service needs documented scope, client contacts, an approval model, and a review cadence for every client. - A public DNS check can confirm a published record, but it cannot prove a production sender uses that record correctly. - DMARC evidence, sender-platform status, and delivered-message headers answer different operational questions. - Unknown or low-volume sending sources need an owner and review date instead of being removed from the queue. - Client authorization, DNS publication, sender configuration, and mailbox-provider handling remain separate responsibilities. - A useful client report records evidence, decisions, exceptions, and next actions instead of claiming a universal security score. ## Operating context and ownership A multi-client email security service crosses systems that an MSP does not fully control. The MSP can collect evidence, identify authentication or alignment gaps, coordinate remediation, and document recommendations. The client decides whether a sender is legitimate and approves business-impacting changes. The DNS host controls record publication. Each sending platform controls its authentication configuration. Receiving mailbox providers make their own message-handling decisions. DMARC evaluates whether an authenticated identifier aligns with the domain in the visible From field. [RFC 9989 defines the DMARC policy and alignment model](https://datatracker.ietf.org/doc/html/rfc9989). That protocol model helps an MSP assess evidence, but it does not prescribe a service package, authority model, or client approval process. Use one accountable MSP service owner per client. That owner maintains the domain scope, identifies the client approver, keeps exceptions visible, and confirms every open item has an owner and review date. The client should name a business contact who can confirm a sender's purpose and a technical contact who can coordinate authorized access and validation. This workflow is a Palisade-authored framework, not an external requirement. It is designed for the recurring ownership and handoff work involved in multi-client DMARC operations. The [Palisade MSP workflow](/for-managed-service-providers) provides related context for teams managing client domain portfolios. ## Service decision record Before offering the service to a client, create a service decision record. This Palisade-authored framework separates commercial choices, operating responsibilities, and protocol evidence. It prevents a broad request for "email security" from becoming an unbounded promise to administer every client system. The decision record should include: - Client segments in scope, such as managed domains, selected business units, or defined sender categories. - Baseline evidence needed before recommendations, including public DNS answers, sender inventory inputs, and message evidence where available. - Included work, excluded tasks, and any separate incident-response or mailbox-filtering services. - MSP, client, DNS-host, and sender-owner responsibilities. - Escalation contacts for business-critical sending paths and specialist issues. - Reporting cadence, review audience, and the operational artifact delivered. - Change approval requirements, rollback conditions, and change-window limits. - Risks requiring specialist escalation, such as an active compromise, unavailable sender access, or business-critical mail failures. - The next review date for unresolved evidence or accepted risk. ```yaml client: example-client segments_in_scope: - primary corporate domain - marketing sending domain baseline_evidence: - public DMARC record - client sender inventory - redacted production message sample included_work: - evidence review - sender ownership coordination - approved remediation recommendations excluded_tasks: - unapproved DNS changes - mailbox incident response - third-party licensing administration ownership: msp: maintain evidence register and coordinate retests client: confirm senders and approve changes dns_host: publish authorized DNS records sender_owner: configure sender authentication settings escalation_path: client technical approver, then sender specialist reporting_cadence: monthly operational review change_approval: client approval required before production changes specialist_risks: - suspected account compromise - failed business-critical mail flow next_review_date: 2026-09-15 ``` The record is not proof that mail is configured correctly. It is the operating artifact that shows what evidence is missing, who controls the next action, and when the client will revisit it. ![Service decision flow showing the evidence, ownership, approval, escalation, and review decisions required for each MSP client](/images/editorial/why-should-msps-offer-email-security-services/why-should-msps-offer-email-security-services-service-decision-record.webp "1200x980") *Source: Palisade.* ## Evidence to collect Create one working record per client domain. Keep onboarding statements separate from observed evidence. A sender named by the client is not yet a confirmed production path, and a published DNS record is not proof that a particular application signs or sends with the intended domain. Collect: - Client name, domain, business owner, technical contact, and escalation contact. - MSP service owner and the scope the client has authorized. - DNS host, change authority, approval path, and change-freeze periods. - Known employee-mail, marketing, CRM, billing, support, and application senders. - Dated DNS answers, sender-platform status, redacted message headers, support tickets, and client confirmations. - A next action, responsible party, review date, and rollback condition for proposed changes. - An exception state for blocked, unknown, retired, or accepted-risk items. Use labels that preserve uncertainty. `client-confirmed` means the client has confirmed a sender's business purpose. `observed` means it appears in evidence but remains unconfirmed. `message-verified` means a redacted production message supports the observed result. `blocked` means necessary access, ownership, evidence, or a safe test window is unavailable. `retired` means the client has confirmed the sender is no longer used. For a domain-level question, the [DMARC checker](/tools/dmarc) can inspect the public DMARC record. A public record check does not show whether every production sender authenticates, identify every low-volume source, monitor future DNS changes, or determine how a receiving provider will handle a later message. ## How to run the workflow ### 1. Define the service boundary Owner: MSP service owner. Input: client agreement, contacts, and domain list. Output: an approved scope record. Document whether the service assesses, recommends, implements approved changes, or reports findings only. State where it stops, such as endpoint protection, incident response, mailbox-filter administration, or third-party licensing. A DNS assessment is not a commitment to configure every sender the client has ever used. ### 2. Build a sender inventory Owner: MSP analyst, with client business and technical contacts. Input: onboarding responses, existing tickets, DNS evidence, and available message evidence. Output: a sender inventory with confidence labels. Include routine and infrequent paths. Invoice systems, password-reset mail, support platforms, campaign tools, and application alerts may use the same visible domain. Assign an owner to every uncertain sender and retain it until the client confirms, remediates, or retires it. The email threats MSPs should know provides useful context for the client conversation. The service record still needs the client's actual domains, systems, and evidence. ### 3. Validate at four separate layers Owner: MSP analyst. Input: DNS results, sender-platform status, redacted delivered-message headers, and later DMARC evidence. Output: a dated evidence package. Use separate checks for a material authentication decision: - DNS: Query the authoritative DNS service and at least one public resolver for the published record. - Vendor: Confirm the sending platform's current authentication or verification status. - Message: Review a real delivered message from the exact production path. [RFC 8601 defines the `Authentication-Results` header field](https://www.rfc-editor.org/rfc/rfc8601.html), which records authentication assessment results. - DMARC: Review aggregate-report data after reports have had time to accumulate. Each layer answers a different question. A green sender-platform indicator does not prove a delivered message used the intended path. A successful delivered message does not prove all client senders are configured correctly. Aggregate reports can identify observed sources, but client confirmation is still needed to establish a source's business purpose. ![Four-layer email authentication validation flow covering DNS, vendor, message, and DMARC evidence](/images/editorial/why-should-msps-offer-email-security-services/why-should-msps-offer-email-security-services-validation-layers.webp "1200x829") *Source: Palisade.* ### 4. Turn evidence gaps into assigned work Owner: MSP service owner. Input: sender inventory and evidence package. Output: a remediation or decision ticket with a named control owner. Write observable, owner-specific work. For example: "Client marketing owner must confirm whether the observed campaign sender remains active and provide a redacted delivered-message sample." The ticket identifies the party that controls the next action and the same-path retest required to close it. The client may confirm whether a sender is allowed. A DNS administrator may publish an approved record. A sender provider may expose the authentication settings. The MSP coordinates the evidence and records the result. ### 5. Review and authorize changes Owner: client approver, with MSP support. Input: proposed change, evidence, rollback condition, and maintenance timing. Output: an approved, declined, or deferred change record. Do not apply a production change because it improves a portfolio metric. The client should review the affected business path, expected impact, and rollback trigger. The MSP should retain the before-and-after record values, approval, publication time, and post-change evidence. > A DMARC policy change can affect legitimate mail. Do not move a client toward enforcement until legitimate sending paths have evidence, owners, and a documented response if a business-critical path fails. ### 6. Report the decision and review the queue Owner: MSP service owner. Input: current evidence register, tickets, exceptions, and client decisions. Output: a client operational review. Use a monthly operating review and a periodic client service review. Include domains in scope, sender states, open remediation work by owner, approved changes, exceptions, accepted risks, and the next review date. Keep detailed DNS, header, and report evidence in an appendix or ticket record. The related guide on [running an email security assessment for a new client](/learning/how-do-msps-run-an-email-security-assessment-for-a-new-client) can help establish the initial baseline. Ongoing service work should show what changed after the assessment and which decisions remain open. ## Exceptions and escalation Escalate when the MSP cannot establish ownership, safe validation, or authority for a material mail path. Common examples include an unknown high-volume source, a business-critical sender with no test window, unclear DNS ownership, sender-platform limits that block the requested configuration, and conflicting evidence between reports and the client inventory. Use the service decision record to route each exception: - If the business purpose is unknown, send it to the client business owner. - If DNS publication is required, send the proposed record and approval requirement to the DNS change owner. - If sender configuration is required, send the observed authentication gap to the sender-platform owner. - If a message is failing now, follow the client's incident process. Do not treat the normal service queue as an incident-response channel. - If the issue needs security, legal, contractual, or provider-specific expertise beyond the agreed service, record the handoff and keep the item blocked until the client decides. An accepted risk needs a named client approver, evidence date, reason, and next review date. It should not disappear because a reporting period was quiet. ## Reporting and success measures Measure the health of the operating process, not a claim that every message is secure. Useful service measures include: - In-scope domains with a current client approver and technical contact. - Senders with dated evidence and an assigned state. - Unknown sources without an owner or review date. - Open remediation work past its agreed review date. - Proposed changes with complete approval, rollback, and post-change evidence. - Exceptions that remain accepted after their next review date. These measures show whether the MSP can operate the service consistently across tenants. They do not prove future inbox placement, every future message's authentication result, or a receiving provider's private filtering decision. ## Build a recurring evidence queue for each client Once a client has more than a one-time public DNS question, the recurring gap is usually sender inventory, evidence review, remediation ownership, and policy-readiness decisions across domains. Palisade is agentic DMARC software that analyzes DMARC aggregate-report data, identifies sending sources and authentication or alignment issues, creates prioritized remediation tickets, and proposes the next policy step when the evidence indicates readiness. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=msp_operations&utm_content=why-should-msps-offer-email-security-services) Palisade does not authorize client senders, make external DNS changes without the required access and approval, repair every sender automatically, or guarantee how receiving mailbox providers will handle mail. ## Sources and further reading - [RFC 9989: Domain-based Message Authentication, Reporting, and Conformance](https://datatracker.ietf.org/doc/html/rfc9989) - [RFC 8601: Message Header Field for Indicating Message Authentication Status](https://www.rfc-editor.org/rfc/rfc8601.html) - [Palisade documentation](https://docs.palisade.email/) ## Frequently asked questions ### Should an MSP offer email security as a one-time assessment? Only if the scope clearly states that it is an assessment. A one-time review can identify public DNS and available message-evidence gaps, but it cannot establish ongoing ownership for new senders, later DNS changes, or unresolved remediation work. ### Can a DMARC record check prove a client's mail is secure? No. A DMARC record check can inspect the public record for a domain. It cannot prove that a production sender uses the intended authentication path, that all senders are known, or that a receiving provider will accept a future message. ### Who should approve an MSP's email authentication changes? The client should approve business-impacting production changes through the agreed change process. The MSP can prepare evidence and recommendations, while the DNS host and sender owner carry out actions they control. ### What evidence should an MSP collect for each client sender? An MSP should collect client confirmation of purpose, DNS evidence where relevant, sender-platform status, and a redacted delivered-message header from the production path when possible. DMARC aggregate reports add observed source evidence after reporting data accumulates. ### Does DMARC enforcement remove the need for an MSP email security service? No. DMARC enforcement addresses a defined authentication policy and alignment model. Clients can still add senders, change DNS, lose sender ownership context, or need evidence reviews and approved remediation work across their domain portfolio. --- # Yahoo bulk sender requirements Canonical: https://www.palisade.email/learning/yahoo-bulk-sender-requirements > Yahoo bulk sender requirements: authentication, DMARC alignment, unsubscribe, complaint-rate, DNS, and validation checks for Yahoo Mail senders. Yahoo requires bulk senders to use SPF and DKIM, publish a valid DMARC policy of at least `p=none`, and pass DMARC with alignment to the visible From domain. Marketing and subscribed bulk mail also needs List-Unsubscribe support, a visible unsubscribe link, and processing within two days. Yahoo does not publish a numeric threshold for bulk-sender status. Its [Sender Hub requirements](https://senders.yahooinc.com/best-practices/?is_listing=false) are the controlling public guidance. ## Quick takeaways - Last checked: August 12, 2026 - Next review: October 28, 2026 - Content owner: Palisade editorial - Yahoo describes bulk mail as "significant volume" but does not publish a numeric threshold in its [Sender Hub FAQ](https://senders.yahooinc.com/faqs/). - Bulk senders need SPF, DKIM, DMARC, and alignment between the visible From domain and a passing SPF or DKIM identifier. - Yahoo says bulk marketing and subscribed mail needs a functioning unsubscribe process. A body link alone does not meet the requirement. ## Who is affected Yahoo's sender guidance applies to mail sent to Yahoo Mail-hosted consumer domains. The [Yahoo Sender Hub FAQ](https://senders.yahooinc.com/faqs/) says Yahoo evaluates a sender using the authenticated domain or From-header domain and other available information, including content and IP addresses. Yahoo calls bulk sending "significant volume" and says it will not specify a threshold. Treat recurring promotional and subscribed traffic as in scope unless you have a documented reason to classify it differently. This is a cautious operating decision, not a published Yahoo threshold. Transactional mail, such as password-reset and order-confirmation messages, is outside Yahoo's stated one-click unsubscribe scope. It still needs the applicable authentication, DNS, and message-format controls. For background on the authentication controls, see the [email authentication learning hub](/learning), [what SPF is](/learning/what-is-spf), [what DKIM is](/learning/what-is-dkim), and [what DMARC is](/learning/what-is-dmarc). ![Requirements-to-evidence checklist for Yahoo bulk senders](/images/editorial/yahoo-bulk-sender-requirements/yahoo-bulk-sender-requirements-evidence-checklist.webp "1200x600") *Source: Palisade.* ## Current requirements ### Authentication and DMARC alignment - Applies to: Yahoo bulk senders. - Effective: February 2024, according to the [Yahoo Sender Hub FAQ](https://senders.yahooinc.com/faqs/), checked July 28, 2026. - Required evidence: A delivered production message shows SPF and DKIM results, and DMARC passes with the visible From domain aligned to either the SPF domain or DKIM domain. Public DNS must also show the relevant records. - Consequence: Yahoo's [sender requirements](https://senders.yahooinc.com/best-practices/?is_listing=false), checked July 28, 2026, list SPF, DKIM, a valid DMARC policy of at least `p=none`, DMARC pass, and alignment for bulk senders. Yahoo states that relaxed alignment is acceptable. A published SPF record or DKIM key is only DNS evidence. It does not prove that the active production platform uses the expected envelope identity or signs each message path. ### Unsubscribe for marketing and subscribed messages - Applies to: Yahoo bulk marketing and subscribed messages. Transactional mail is excluded from Yahoo's stated one-click requirement. - Effective: June 2024 for List-Unsubscribe enforcement, according to the [Yahoo Sender Hub FAQ](https://senders.yahooinc.com/faqs/), checked July 28, 2026. - Required evidence: A marketing or subscribed message has a functioning `List-Unsubscribe` header, a clearly visible body unsubscribe link, and suppression evidence showing the request was honored within two days. - Consequence: Yahoo's [sender requirements](https://senders.yahooinc.com/best-practices/?is_listing=false), checked July 28, 2026, require the unsubscribe controls and two-day handling period. Yahoo's [Subscription Hub guidance](https://senders.yahooinc.com/subhub/) documents the relationship between `List-Unsubscribe` and `List-Unsubscribe-Post`. It says the RFC 8058 POST method is highly recommended, while `mailto:` is acceptable. [RFC 8058](https://www.rfc-editor.org/rfc/rfc8058) defines the one-click header mechanism. ### Complaint rate, DNS, and message compliance - Applies to: Complaint-rate guidance applies to Yahoo bulk senders. Valid forward and reverse DNS and RFC compliance apply as Yahoo states in its sender guidance. - Effective: February 2024 for the sender-requirements rollout, according to the [Yahoo Sender Hub FAQ](https://senders.yahooinc.com/faqs/), checked July 28, 2026. - Required evidence: Yahoo Sender Hub or ESP complaint evidence, forward and reverse DNS results for each sending IP, and a delivered-message or MTA record showing the production path meets applicable RFC requirements. - Consequence: Yahoo says bulk senders should keep spam rates below `0.3%`. Its FAQ says Yahoo continuously evaluates mail and may defer mail from domains with high complaint rates. Yahoo's [sender requirements](https://senders.yahooinc.com/best-practices/?is_listing=false), checked July 28, 2026, also call for valid forward and reverse DNS and compliance with RFC 5321 and RFC 5322. A `0.3%` complaint rate is a provider threshold, not an inbox-placement guarantee. Yahoo's [SMTP error-code reference](https://senders.yahooinc.com/smtp-error-codes/) shows that permanent errors can have authentication, RFC, policy, or other causes. Do not diagnose an individual SMTP reply as a complaint-rate issue without matching provider evidence. ## Implementation and validation ### 1. Map each production sending identity Record the visible From domain, envelope sender, DKIM `d=` domain and selector, sending IP, message type, sending platform owner, and Yahoo-recipient volume for every production stream. Include low-volume systems such as support, billing, recruiting, and incident notifications. The map identifies who can repair an alignment or unsubscribe problem. ### 2. Check DNS and a delivered production message Inspect the public DMARC, SPF, and DKIM records. Then send a representative message through the exact production route to a Yahoo-hosted test mailbox and retain its full headers. Confirm SPF and DKIM results. Confirm that DMARC passes because either the SPF identifier or DKIM identifier aligns with the visible From domain. Receiver-added [Authentication-Results](https://www.rfc-editor.org/rfc/rfc8601.html) are message evidence. An ESP status indicator is not a delivered-message check. ### 3. Test each marketing unsubscribe path Inspect a marketing or subscribed message for the header and visible body link. Use a test recipient to submit the unsubscribe request, then confirm the address is suppressed within Yahoo's two-day period. ```text Yahoo bulk-sender evidence record From domain: <visible-from-domain> Envelope sender: <smtp.mailfrom-domain> DKIM d=: <signing-domain> DMARC result: <pass/fail> Aligned identifier: <SPF or DKIM domain> List-Unsubscribe test: <endpoint and request time> Suppression evidence: <system event within two days> Complaint-rate evidence: <Yahoo or ESP metric and denominator> PTR and forward DNS evidence: <sending IP and lookup result> ``` > Do not use a real recipient address, opaque unsubscribe URL, token, private header, or customer data in shared evidence records. A header shape for an RFC 8058-capable endpoint is: ```http List-Unsubscribe: <https://example.com/unsubscribe/opaque-id> List-Unsubscribe-Post: List-Unsubscribe=One-Click ``` The endpoint and opaque identifier are illustrative only. Generate real values in the sending platform that owns recipient suppression. ### 4. Review complaint and delivery evidence Review the applicable Yahoo complaint evidence and any Complaint Feedback Loop enrollment or ESP-provided equivalent. Compare the same DKIM domain, campaign, time period, and denominator before interpreting a rate. Keep SMTP responses separately. They document a delivery attempt, while complaint data and Yahoo Sender Hub data address different provider signals. ### 5. Retest after a scoped repair Repair one confirmed cause, such as an unsigned stream, an unaligned identity, or an unsubscribe endpoint that does not create a suppression event. Repeat the same-path message and unsubscribe tests. Complete the four layers before marking a stream ready: - DNS: Verify authoritative DNS and at least one public resolver. - Vendor: Review the sending platform's current authentication or suppression status. - Message: Inspect a newly delivered message from the exact production path. - DMARC: Review aggregate-report data after it accumulates. A passing checklist does not control Yahoo's private reputation decisions or guarantee future delivery. ## Change log ### August 12, 2026 Confirmed unchanged against Yahoo's public Sender Hub requirements, FAQ, Subscription Hub guidance, and SMTP error reference. The tracker retains Yahoo's unpublished bulk threshold, February 2024 sender-requirements rollout, June 2024 List-Unsubscribe enforcement, `0.3%` complaint-rate guidance, and two-day unsubscribe handling requirement. The next scheduled review remains October 28, 2026. ### July 28, 2026 Established the maintained tracker from Yahoo Sender Hub guidance. Recorded that Yahoo does not publish a numeric bulk-sender threshold, bulk authentication requires SPF, DKIM, DMARC, and alignment, and marketing or subscribed bulk mail needs List-Unsubscribe support, a visible body link, and processing within two days. ## Check the public authentication posture before comparing message evidence Use the [Email Security Score](/tools/email-security-score) to inspect the sending domain's public authentication controls before changing DNS. Compare the result with the production headers, sending-path inventory, and unsubscribe test collected above. A public check cannot prove that Yahoo received the message, that every production stream signs and aligns, that an unsubscribe request created suppression, or that Yahoo will take a particular future delivery action. ## Sources and further reading - [Yahoo Sender Hub sender requirements and recommendations](https://senders.yahooinc.com/best-practices/?is_listing=false) - [Yahoo Sender Hub FAQs](https://senders.yahooinc.com/faqs/) - [Yahoo Subscription Hub guidance](https://senders.yahooinc.com/subhub/) - [Yahoo SMTP error codes](https://senders.yahooinc.com/smtp-error-codes/) - [RFC 8058: Signaling one-click functionality for List-Unsubscribe](https://www.rfc-editor.org/rfc/rfc8058) - [RFC 8601: Authentication-Results header field](https://www.rfc-editor.org/rfc/rfc8601.html) ## Frequently asked questions ### Does Yahoo publish a bulk-sender volume threshold? No. Yahoo describes bulk mail as significant volume but says it does not specify a numeric threshold. Plan recurring promotional and subscribed traffic as in scope unless documented facts support a different classification. ### Does Yahoo require DMARC enforcement at `p=quarantine` or `p=reject`? No. Yahoo's published bulk-sender guidance requires a valid DMARC policy of at least `p=none`, plus DMARC pass and alignment. A stricter policy can be an organization decision after legitimate sending paths are validated. ### Is a visible unsubscribe link enough for Yahoo bulk mail? No. Yahoo says bulk marketing and subscribed mail needs a functioning List-Unsubscribe header and a clearly visible body unsubscribe link. The request must also be honored within two days. ### Does a passing DNS check prove Yahoo bulk-sender compliance? No. Public DNS can show published records, but it cannot prove that the production platform signs the message, that DMARC aligns on the delivered path, or that an unsubscribe request creates suppression. ### Does a complaint rate below `0.3%` guarantee inbox placement at Yahoo? No. Yahoo's `0.3%` guidance is not an inbox-placement guarantee. Yahoo evaluates mail continuously and can use other information, including authenticated-domain, From-domain, content, and IP signals. --- # How do you authenticate an email for Gmail? Canonical: https://www.palisade.email/learning/authenticate-email-for-gmail > Authenticate email for Gmail with SPF, DKIM, and DMARC, then validate the exact sending path in Gmail headers and DMARC reports, and verify sender paths. To authenticate email for Gmail, configure SPF or DKIM for each domain and service that sends to personal Gmail accounts. If you are a bulk sender, Gmail requires SPF, DKIM, and DMARC, with either the SPF envelope domain or DKIM signing domain aligned to the visible From domain for direct mail. Start with the domain and sending service in the message, then validate a newly delivered Gmail message. A DNS record alone does not prove the production path is using it. ## Quick takeaways - Gmail requires all senders to personal Gmail accounts to use SPF or DKIM. - Gmail requires bulk senders to use SPF, DKIM, and DMARC. - DMARC passes only when SPF or DKIM passes with an identifier aligned to the visible From domain. - Each mail system can use different envelope and DKIM signing domains, so test every real sending path. - Public DNS checks confirm published records, not whether an application signs mail or whether Gmail will place it in the inbox. - Authentication supports delivery, but it does not guarantee inbox placement. ## What should I check before configuring Gmail authentication? First, identify the system that actually sends the message. Gmail can receive mail from a mailbox provider, marketing platform, CRM, invoicing service, ticketing system, or relay. Each can have its own SPF authorization, DKIM selector, return path, and signing domain. Gmail's [email sender guidelines](https://support.google.com/mail/answer/81126?hl=en) apply to mail sent to personal Gmail accounts. They distinguish between baseline sender authentication and additional bulk-sender requirements. Check whether the route is direct mail from your own infrastructure, mail sent through a third-party platform, or mailbox-hosted mail. The configuration belongs in the system and DNS zone that own that route. You need access to the authoritative DNS zone for the sending domain and enough permission in the sending platform to enable or inspect its authentication settings. If an MSP manages the domain, record the customer domain, sending platform, DNS owner, approver, and test mailbox before making a change. > Copy DNS values from the account and domain you are configuring. Do not publish selectors, targets, tokens, or hostnames from another account or from an online example. Use the [vendor email authentication hub](/learning/esp-setup) when the sending service has its own domain-authentication workflow. The vendor generates the real DNS values for its account and domain. Do not substitute an example record. ## Which setup method should I use? Use the method supported by the sender that produces the mail. For mailbox-hosted mail, enable DKIM in the mailbox provider's documented administration settings and publish the exact record it generates. For a marketing or transactional platform, authenticate a sending domain or branded domain through that platform, then publish its generated SPF, DKIM, return-path, or CNAME records as instructed. For mail sent directly from your own infrastructure, configure the relevant SPF authorization and DKIM signing system before publishing DNS. Google's sender guidelines do not provide a single Gmail configuration screen that authenticates every external sending service. The correct path is the authentication interface of the service sending the message, followed by Gmail header validation. When an application submits through a Google mailbox or Workspace relay, use the [Gmail SMTP settings guide](/learning/gmail-smtp-settings) for the endpoint, ports, authentication choice, and same-path test. ![Decision flow for authenticating a sending domain used to send mail to Gmail](/images/editorial/authenticate-email-for-gmail/authenticate-email-for-gmail-authentication-flow.webp "1200x829") *Source: Palisade.* If your mailbox-hosted route is Google Workspace, the Admin console's **Authenticate email** panel is where Google shows the selected domain, DKIM status, and the DNS values it generated. This is one provider-specific example, not a universal Gmail setup screen and not proof that another sending service or delivered message is authenticated. ![Google Admin Authenticate email panel with a selected domain, DKIM status, DNS host name, and TXT record value.](/images/editorial/authenticate-email-for-gmail/google-workspace-dkim-authenticate-email.png "3456x1992") *Source: authorized current Google Admin console capture, checked 2026-07-27. It shows an existing Google Workspace DKIM state and the public DNS material for the selected organization-owned domain; it does not prove another domain's configuration or a delivered Gmail result. [Google's DKIM setup documentation](https://knowledge.workspace.google.com/admin/security/set-up-dkim) describes this Workspace workflow.* Use a dedicated IP only when the sending provider and your operating requirements call for one. A dedicated IP does not replace SPF, DKIM, or DMARC. Gmail's requirements apply to the message authentication evidence and sending behavior, regardless of whether a route uses shared or dedicated infrastructure. ## How do I configure SPF and DKIM for Gmail-bound mail? ### 1. Open the sending service's domain-authentication settings Open the documented domain, sender authentication, or DKIM settings for the service that sends the message. Select the domain that appears after the `@` in the visible From address. Confirm the selected account and domain before generating records. A platform can expose several domains, subdomains, or sending identities. The records it generates are specific to the current account and selected domain. ### 2. Record the visible From domain and sending identities Send a test message through the exact route you are configuring, then inspect it in Gmail. Record the visible From domain, the SPF envelope domain if shown, and the DKIM `d=` signing domain and `s=` selector. This baseline shows what the service currently does. It also prevents a common mistake: publishing records for the visible From domain while the sending platform uses a different return path or signing domain. ### 3. Publish the generated SPF and DKIM records Copy the DNS records from the selected sending service into the authoritative DNS zone. SPF is a TXT record. DKIM may use a TXT record or a provider-generated CNAME record. An SPF policy must be a single record for one domain. If the domain already has SPF, merge the sender's authorized mechanism into the existing policy according to the sending provider's instructions. Do not add a second SPF TXT record. **SPF record type:** `TXT` **SPF host, illustrative only:** ```text yourdomain.com ``` **SPF value, illustrative only:** ```text v=spf1 include:sender.example.net -all ``` **DKIM record type:** `TXT` or `CNAME` **DKIM host, illustrative only:** ```text selector1._domainkey.yourdomain.com ``` **DKIM value, illustrative only:** ```text v=DKIM1; k=rsa; p=PUBLIC_KEY_MATERIAL_FROM_YOUR_SENDING_SERVICE ``` > Do not publish these examples. Copy the complete host and value generated in the sending service for your account and domain. The example DKIM key cannot authenticate mail because it has no matching private key. Some DNS providers automatically append `yourdomain.com` to the host field. If you paste a complete name into a field that appends the zone, the resulting owner can become `selector1._domainkey.yourdomain.com.yourdomain.com`. Check the final fully qualified record name before saving. Do not overwrite an existing DKIM selector without confirming whether it is active. If the selector is already in use, use the sending service's rotation process or generate a distinct selector. ### 4. Verify the domain in the sending service Return to the service and use its documented verification or authentication-status check after DNS has propagated. A successful status indicates that the service accepted the DNS configuration it expected. Keep the provider's status with the change record, but do not treat it as the final test. A green indicator does not prove that the production application is sending through the configured path or that the delivered message has aligned authentication. ### 5. Send a real Gmail test message Send a new message from the exact production path to a personal Gmail mailbox where you can inspect the message details or original source. Do not use an old message sent before the DNS or service change. Test each materially different source separately. A staff mailbox, marketing platform, billing service, and support platform can all send with the same visible domain while using different authentication identities. ## How does this setup affect DMARC? DMARC evaluates SPF and DKIM results against the visible From domain. Under [RFC 9989's DMARC evaluation rules](https://www.rfc-editor.org/rfc/rfc9989.html), an SPF or DKIM pass contributes to DMARC only when its authenticated identifier aligns with the RFC5322.From domain. For example, a service can pass DKIM with `d=sender.example.net` while sending a message that displays `From: notices@yourdomain.com`. That signature can be valid but unaligned. It does not create a DKIM-aligned DMARC pass for `yourdomain.com`. Use Palisade's DMARC checker when you have the sending domain to inspect the published DMARC record. A public record check cannot show which production services are signing, whether Gmail received an aligned pass, or how a receiver will handle future messages. Google's [sender requirements for bulk senders](https://support.google.com/mail/answer/81126?hl=en) require DMARC and alignment for direct mail. Configure DMARC after you understand every legitimate sender that uses the domain. A published DMARC policy does not create SPF or DKIM passes by itself. ## How do I validate the setup? ![Gmail authentication validation checklist covering DNS, sender status, message headers, and DMARC reports](/images/editorial/authenticate-email-for-gmail/authenticate-email-for-gmail-validation-checklist.webp "1200x524") *Source: Palisade.* ### Check public DNS Query the exact SPF domain and DKIM selector that the sending service uses. Compare the authoritative DNS answer with at least one public resolver. Confirm that the expected SPF policy and DKIM record are publicly available. ```bash dig +short TXT yourdomain.com dig +short TXT selector1._domainkey.yourdomain.com ``` DNS output proves the records are published. It does not prove that an application uses the records or that a message survives its full delivery path. ### Check the sender's verification status Return to the sending service and confirm that it reports the selected domain as authenticated or verified. If it remains pending, compare the complete DNS owner and value against the account-generated instructions. Check for a duplicated DNS suffix, truncated TXT value, an incorrect selector, or an SPF record that was added as a second policy instead of merged into the existing one. ### Inspect a delivered message Inspect a newly delivered Gmail message from the exact path. Confirm that SPF or DKIM passes, then compare the authenticated domain with the visible From domain. For bulk senders, confirm that the message has the required SPF, DKIM, and DMARC evidence described in Google's [email sender guidelines](https://support.google.com/mail/answer/81126?hl=en). Save a redacted copy of the relevant message results with the change record. Do not include private recipient addresses, message content, tokens, or unredacted headers in a ticket or external request. #### Compare the message evidence before changing DNS A correct DNS record can still be unused by the production sender. Copy these four values from one newly delivered test message before publishing another record or replacing an existing one: - **Visible From domain:** `example.com`. This is the domain the recipient sees and the domain DMARC evaluates. - **SPF envelope domain:** `mail.example-vendor.net`. This is the domain beside a passing `spf=` result. - **DKIM signing domain:** `example-vendor.net`. This is the domain beside a passing `dkim=` result. - **DMARC result:** `pass` or `fail`, plus the visible From domain that Gmail reports with it. For example, this message has passing SPF and DKIM results but still fails DMARC: ```text wrap From: Billing <billing@example.com> Authentication-Results: mx.google.com; spf=pass smtp.mailfrom=mail.example-vendor.net; dkim=pass header.d=example-vendor.net; dmarc=fail header.from=example.com ``` The `Authentication-Results` syntax is standardized in [RFC 8601](https://www.rfc-editor.org/rfc/rfc8601.html). Read the result Gmail added to the delivered copy of the message, not a header supplied by the sending system. The SPF and DKIM domains in this example do not align with `example.com`. The next safe action is to identify the sending platform and configure its approved aligned return-path or DKIM signing domain. Adding another SPF record would not repair this alignment failure. Use the [SPF checker](/tools/spf) to inspect the public SPF policy and the [DMARC checker](/tools/dmarc) to inspect the public DMARC record. Those tools do not expose the private authentication evidence in a delivered message, so keep the Gmail header as the final proof for this sending path. #### When SPF is hard to maintain If the SPF check shows multiple records, a lookup-limit problem, or a record that changes whenever a new sender is added, inventory every legitimate sender before changing DNS. For a domain with frequent sender changes, Palisade Hosted SPF can manage the delegated SPF record behind one include. It is a maintenance option, not a substitute for confirming alignment in a real message. [View Hosted SPF](https://docs.palisade.email/page-breakdowns/hosted-spf/). ### Review DMARC reports After DMARC aggregate reports accumulate, review the sending sources using the domain and identify any source that fails authentication or alignment. Separate legitimate sources from unknown traffic before considering a stricter policy. A single Gmail test proves one delivered path at one time. DMARC reporting adds broader evidence about the sources using the domain after reports arrive. ## Troubleshooting ### Gmail shows SPF pass but DMARC fail Compare the SPF envelope domain with the visible From domain. A passing SPF result can fail DMARC alignment when the domains do not align under the published DMARC policy. Use the sending service's custom return-path or authenticated-domain option when it supports one. Then retest a new message through the same route. ### Gmail shows DKIM pass but DMARC fail Check the DKIM `d=` value in the delivered message. The signature may pass for a domain that does not align with the visible From domain. Enable the sending platform's custom DKIM or branded-domain configuration if its current signing domain is provider-owned. A valid signature is still useful authentication evidence. It is not necessarily aligned DMARC evidence. ### The sending service cannot verify DNS Compare the exact host and value in the service with the authoritative DNS response. DNS interfaces that append the zone name can create a duplicated owner name. Also confirm that the selected domain in the service is the same domain queried in DNS. Allow normal DNS propagation before changing records again. Repeatedly replacing values can extend the troubleshooting window and obscure which change corrected the issue. ### SPF has more than one record Consolidate the authorized mechanisms into one SPF TXT record for the domain. Do not leave parallel `v=spf1` records in place. Review every sender before removing an existing mechanism. Removing an authorization for a billing system or relay can cause legitimate mail to fail SPF. ### A mailbox test passes but marketing mail fails Treat each platform as a separate sending path. The mailbox provider's DKIM configuration does not authenticate messages sent by a marketing platform, CRM, or alerting system. Authenticate the affected platform's selected sending domain, then repeat the DNS, vendor-status, delivered-message, and DMARC-report checks for that route. ## Check the domain configuration before expanding the rollout If you have the sending domain, run Palisade's [Email Security Score](/tools/email-security-score) to inspect its public authentication configuration after you publish the records. Compare the result with the Gmail message evidence you collected for the specific sender. A public score can identify visible DNS gaps, but it cannot prove that a particular application is signing mail, verify Gmail's private placement decision, monitor every future sending path, or repair an unaligned source. For teams handling several domains or recurring sender changes, Palisade is DMARC software that analyzes DMARC aggregate-report data, identifies sending sources and authentication or alignment issues, and creates prioritized remediation tickets. A human reviews the evidence and applies DNS or DMARC policy changes. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=existing_content_migration&utm_content=authenticate-email-for-gmail) If Gmail has already blocked mail, use the Gmail unauthenticated-sender fix. If authentication passes but placement remains poor, investigate [why emails go to spam in Gmail](/email-deliverability/why-are-my-emails-going-to-spam-in-gmail). ## Sources and further reading - [Google email sender guidelines](https://support.google.com/mail/answer/81126?hl=en) - [RFC 9989: Domain-based Message Authentication, Reporting, and Conformance](https://www.rfc-editor.org/rfc/rfc9989.html) ## Frequently asked questions ### Is SPF alone enough for Gmail? Only for senders that are not subject to Google's bulk-sender requirements. Google requires SPF or DKIM for all senders to personal Gmail accounts, but requires SPF, DKIM, and DMARC for bulk senders. Google also recommends using all three authentication methods. ### Does a DMARC record authenticate an email for Gmail? No. DMARC evaluates SPF or DKIM results and their alignment with the visible From domain. Publishing a DMARC record does not make an application send SPF-authorized mail or add a DKIM signature. ### Why does Gmail show DKIM pass but DMARC fail? The DKIM signature can pass for a signing domain that does not align with the visible From domain. Inspect the `d=` value in the delivered message and compare it with the visible From domain under the DMARC alignment mode. ### Can a DNS checker prove Gmail authentication is working? No. A DNS checker can inspect public SPF, DKIM, or DMARC records for a domain. It cannot prove that the production application uses those records, that a delivered Gmail message passed alignment, or that future messages will reach the inbox. ### Does authenticated email always reach the Gmail inbox? No. Google's sender guidelines state that authenticated mail is less likely to be rejected or marked as spam, but authentication does not guarantee inbox placement. Gmail also evaluates other documented delivery requirements and sender signals. --- # Best email security: 8 options compared Canonical: https://www.palisade.email/learning/best-email-security > Best email security: 8 options checked on deployment model, threats named and published pricing, from first-party vendor pages read on 12 August 2026. There is no single best email security product. The right one depends on where you want protection to sit: a gateway or API filter that inspects inbound mail, the filtering already included with Microsoft 365 or Google Workspace, or the authentication layer that stops your own domain being spoofed. This comparison records what eight options publish on their own pages, seven inbound vendors plus the authentication layer, covering which deployment models they document and which of them show a price. Detection quality cannot be tested from a vendor page, so nothing here is ranked on it. ## Quick takeaways - **Deployment is a setting inside most of these products.** Proofpoint, Mimecast, Barracuda, Abnormal and Cloudflare each document a connection that leaves MX records alone. - **Three of the eight options publish a list price.** Microsoft, Google and Palisade. The other five show none. - **Microsoft 365 already gives you a filtering baseline.** Anti-malware, anti-spam and anti-phishing protection is on by default and cannot be switched off. - **Filtering and domain authentication are separate purchases**, even when one vendor sells both. - **Ask what an administrator can do with a verdict.** That decides what a false positive costs. - **Every fact below was read from a vendor page on 12 August 2026.** ## Who this comparison is for An IT admin, security lead or MSP technician told to pick a product, who wants the shortlist cut down by checkable facts. It assumes mail runs on Microsoft 365 or Google Workspace. If "email security gateway" is doing the work in your requirements document, read [what an email security gateway is](/learning/email-security-gateway) first, because the label covers several architectures. Head-to-head evaluations of authentication platforms sit on the [comparison hub](/compare). This page compares named options. If you have not yet settled on which kind of product you need, start with the category guide to [email security software](/learning/email-security-software), which separates the four types by where each one sits in the mail flow. Picking the type first cuts most of the list below before you read a single vendor page. ## How the options were evaluated Each option was read on its own product or documentation pages on 12 August 2026. Review sites and marketplace listings were excluded. Four things were recorded, and nothing beyond them was inferred: - **Deployment model.** Whether the vendor documents an MX-routed gateway, an API connection, post-delivery inspection, or a choice among them. - **Threats named.** The categories the vendor claims to address, in its own words. - **Published pricing.** Whether a price appears on the vendor's own page. Discounts, minimums and contract terms are not knowable from outside. - **Admin control.** What an administrator can do with a verdict once the product has produced one. Several pages advertise detection percentages. Each vendor measured its own, and no statement below rests on one. ### Criterion: what you already own Microsoft documents anti-malware, anti-spam and anti-phishing protection as included in all organizations with cloud mailboxes, and on by default through the default threat policies. An admin cannot turn them off, but can override them with preset or custom policies. See [Microsoft's built-in security features for cloud mailboxes](https://learn.microsoft.com/en-us/defender-office-365/eop-about). Measure a product against that baseline, not against zero. ### Criterion: admin control over the verdict Google documents three actions an administrator picks per setting: keep the message in the inbox with a warning, move it to spam, or hold it in admin quarantine for review before release. See [Google's advanced phishing and malware protection settings](https://knowledge.workspace.google.com/admin/gmail/advanced/advanced-phishing-and-malware-protection). Put the same question to every vendor on your shortlist. ![How email security products are deployed: gateway, API connected, native provider controls, and the authentication layer](/images/editorial/best-email-security/best-email-security-deployment-models.webp "1200x488") *Source: Palisade.* ## The options, one by one Listed alphabetically, from each vendor's own page. ### Abnormal Security [Abnormal's inbound email security page](https://abnormal.ai/products/inbound-email-security) states "Deploy in 60 seconds via API. No MX changes." and describes the product as built for attacks with no payload and no prior signature. Abnormal positions itself as combining with Microsoft or Google to replace a secure email gateway, which is the vendor's position rather than a tested outcome. Its [platform page](https://abnormal.ai/platform) lists native API integrations with Microsoft 365, Google Workspace, Okta, CrowdStrike and Splunk, "no agents, no proxies", and eleven further modules. ### Barracuda Email Protection [Barracuda's Email Protection page](https://www.barracuda.com/products/email-protection) states that the product connects to Microsoft 365 or Google Workspace with no mail exchange (MX) changes and is operational in minutes rather than weeks. Barracuda names phishing, malware, spam, account takeover, domain fraud with DMARC and post-delivery weaponization among the threats covered, and names Barracuda IQ and Bailey as its detection and explanation technology. ### Cloudflare Email Security [Cloudflare's Email Security documentation](https://developers.cloudflare.com/cloudflare-one/email-security/) documents three deployment approaches: an API connection, post-delivery inspection through BCC or journaling, and pre-delivery placement through MX or inline. Cloudflare says the service uses AI, threat intelligence and security rules to analyze every incoming email, and names phishing, malware, business email compromise, vendor email fraud and spam. The page states no price. ### Google Workspace and Gmail [Google Workspace pricing](https://workspace.google.com/pricing) publishes per-seat prices for the Business tiers and lists "Phishing and spam protection that blocks more than 99.9% of attacks" on every one of them, which is Google's own figure. Data loss prevention, S/MIME encryption and context-aware access are listed under Enterprise, which is quoted by sales. The advanced protections are administrator settings rather than a separate product. ### Microsoft Defender for Office 365 Microsoft documents a ladder rather than one product. [Its Defender for Office 365 overview](https://learn.microsoft.com/en-us/defender-office-365/mdo-about) says Plan 1 "protects email and collaboration features from zero-day malware, phishing, and business email compromise (BEC)" through Safe Attachments, Safe Links, impersonation protection and Real-time detections. Plan 2 "adds phishing simulations, post-breach investigation, hunting, and response, and automation", naming Threat Explorer, Campaigns and Automated Investigation and Response. ### Mimecast Advanced Email Security [Mimecast's Advanced Email Security page](https://www.mimecast.com/products/email-security/) presents two paths to one product. The MX-based path routes all incoming mail through Mimecast's gateway first and intercepts threats in line. The API path connects in minutes, with no MX record changes and no mail flow disruption. Mimecast names phishing, business email compromise, ransomware and zero-day exploits. Which capabilities differ between the two paths is not stated, so ask. ### Proofpoint Core Email Protection [Proofpoint's Core Email Protection page](https://www.proofpoint.com/us/products/threat-defense) lists "Flexible Deployment via API or SEG", so the gateway question here is a configuration decision rather than a choice between suppliers. The page names phishing, business email compromise, ransomware and account takeover, describes post-delivery detection with automated remediation, and covers sandboxing for URLs and attachments. It integrates with Microsoft 365 and Google environments. ## How pricing was handled Three of these options publish a price. [Microsoft's Defender for Office 365 page](https://www.microsoft.com/en-us/security/business/siem-and-xdr/microsoft-defender-office-365) lists Plan 1 at $2.00 per user per month and Plan 2 at $5.00 per user per month, both paid yearly on an auto-renewing annual subscription. Google publishes per-seat prices on its Workspace pricing page, though the currency and any promotional rate depend on your region. Palisade publishes its plans and prices, including a free tier. The others publish nothing. [Barracuda's plans page](https://www.barracuda.com/products/email-protection/plans) names three tiers, Advanced, Premium and Premium Plus, with a feature comparison and no cost figure. [Mimecast's product index](https://www.mimecast.com/products/) lists eight products with no price beside any of them, and Proofpoint's page routes buyers to a demo request. Abnormal and Cloudflare show no price on the pages cited above. Quoted pricing is normal in this segment and says nothing about cost. ## Where Palisade fits Filtering and domain authentication are bought separately, even from one supplier. Mimecast, for instance, sells DMARC Analyzer as its own product beside Advanced Email Security on [its product index](https://www.mimecast.com/products/). Palisade sits in that authentication row and nowhere else. [Palisade's documentation](https://docs.palisade.email/) covers DMARC, SPF, DKIM, BIMI and MTA-STS, domain onboarding, hosted DNS records, aggregate report processing, sender classification and PSA ticketing. It does not filter, sandbox, rewrite links in or quarantine inbound mail, so it replaces none of the products above. Its narrow job is your own domain: [hosted DMARC](https://docs.palisade.email/page-breakdowns/hosted-dmarc) publishes and maintains the record through a CNAME delegation, so a policy move needs no further DNS edit, and the documentation requires resolving the senders list before enforcement. If DMARC is new to you, start with [what DMARC is](/learning/what-is-dmarc). ## How to choose - **You run Microsoft 365 and have not configured what you own.** Set up the built-in policies and measure first. Defender for Office 365 Plan 1 or Plan 2 is the smallest documented step up. - **You need inspection in the delivery path.** Proofpoint, Mimecast and Cloudflare each document an MX or inline deployment. Expect a quote rather than a price. - **You cannot change mail flow.** Abnormal, Barracuda, Cloudflare, Mimecast and Proofpoint all document a connection that leaves MX records untouched. - **Attackers are spoofing your domain rather than reaching your users.** That is the authentication layer, and a separate purchase from every filtering product above. - **You are not sure which layer is failing.** Run a domain through the free [email security score](/tools/email-security-score) before shortlisting anyone. ## Sources and further reading Every page below was read on 12 August 2026. - [Proofpoint Core Email Protection](https://www.proofpoint.com/us/products/threat-defense). - [Mimecast Advanced Email Security](https://www.mimecast.com/products/email-security/) and the [Mimecast product index](https://www.mimecast.com/products/). - [Barracuda Email Protection](https://www.barracuda.com/products/email-protection) and its [plans page](https://www.barracuda.com/products/email-protection/plans). - [Abnormal inbound email security](https://abnormal.ai/products/inbound-email-security) and the [Abnormal platform page](https://abnormal.ai/platform). - [Microsoft Defender for Office 365 overview](https://learn.microsoft.com/en-us/defender-office-365/mdo-about), [built-in security features for cloud mailboxes](https://learn.microsoft.com/en-us/defender-office-365/eop-about) and the [Defender for Office 365 plans and pricing page](https://www.microsoft.com/en-us/security/business/siem-and-xdr/microsoft-defender-office-365). - [Cloudflare Email Security documentation](https://developers.cloudflare.com/cloudflare-one/email-security/). - [Google Workspace pricing](https://workspace.google.com/pricing) and [advanced phishing and malware protection](https://knowledge.workspace.google.com/admin/gmail/advanced/advanced-phishing-and-malware-protection). - [Palisade documentation](https://docs.palisade.email/), [hosted DMARC](https://docs.palisade.email/page-breakdowns/hosted-dmarc) and Palisade pricing. ## Frequently asked questions ### What is the best email security software? No product is best for every organization, because these products do different jobs. Microsoft and Google secure the mailbox you already pay for. Proofpoint, Mimecast, Barracuda, Abnormal and Cloudflare add inspection in the delivery path or through an API. Palisade works on domain authentication, which none of the others replaces. Decide which layer your evidence points at, then compare only those products. ### Do I still need email security software if I use Microsoft 365? Not automatically. Microsoft documents anti-malware, anti-spam and anti-phishing filtering as on by default for every organization with cloud mailboxes, and those policies cannot be turned off. Configure them, apply the preset security policies, then see what still gets through. Defender for Office 365 Plan 1 and Plan 2 add impersonation protection, Safe Links, Safe Attachments, hunting and automation. ### Is a secure email gateway still required? Not in every case. Barracuda, Abnormal, Cloudflare, Mimecast and Proofpoint all document a connection that needs no MX record change, and Cloudflare documents post-delivery inspection by BCC or journaling. A gateway remains the documented option when you want mail inspected before delivery, or when you route mail for systems other than Microsoft 365 and Google Workspace. ### Does email security software stop someone spoofing my domain? Not by itself. Inbound filtering protects the mailboxes you own. It does nothing about mail an attacker sends to other people using your domain in the visible From address. That is what DMARC, with SPF and DKIM alignment, is for, and it is a separate purchase from every filtering product here. ### Which email security companies publish public pricing? Microsoft publishes per-user list prices for Defender for Office 365, Google publishes per-seat Workspace prices, and Palisade publishes its plans. Proofpoint, Mimecast, Barracuda, Abnormal and Cloudflare publish no price on their own product pages, routing buyers to a quote or a demo instead. --- # Email security software: how to choose a category fit Canonical: https://www.palisade.email/learning/email-security-software > Email security software covers four types: secure email gateways, API-connected tools, native provider controls, and the DMARC layer. Find your fit. Email security software is one label for four different kinds of product: a secure email gateway that filters mail before it reaches the mailbox, an API-connected tool that inspects mail after delivery in a cloud tenant, the native controls already included with Microsoft 365 or Google Workspace, and the authentication layer that tells receivers which mail may claim your domain. They stop different attacks and fail in different ways, so pick the type before the vendor. ## Quick takeaways - Email security software is a category label. Its four types are rarely substitutes for each other. - The dividing question is where a control sits relative to delivery: in front of the mailbox, inside it after delivery, inside the provider, or in DNS. - Several email security platforms sell more than one deployment mode, so confirm which mode a proposal covers. - Inbound filtering protects your users. Domain authentication protects everyone who receives mail claiming to be from you. - Turn on what your provider already includes before buying a layer on top of it. ![Four email security software types positioned by where they act in the mail flow](/images/editorial/email-security-software/email-security-software-types.webp "1200x488") *Source: Palisade.* ## Who this comparison is for This is for an IT admin, security lead, or MSP technician narrowing the category before building a shortlist. It compares product types and names vendors only as examples of a type. For head to head vendor pages, use the [comparison hub](/compare). It does not cover archiving, encryption at rest, or data loss prevention, which are sold beside these products. For a ranked read on specific products rather than the categories, see [the eight options compared](/learning/best-email-security). If a vendor calls itself a gateway, check [what an email security gateway actually means](/learning/email-security-gateway). The label alone does not tell you how a product is deployed. ## How the options were evaluated Five criteria separate the types, checked against current first-party vendor documentation on 2026-08-12. - **Position relative to delivery.** Before the mailbox, after the message lands, or never at all. - **What it can do to a message.** Block, quarantine, rewrite, claw back after delivery, or only report. - **What you have to change.** An MX record, a tenant permission grant, a license tier, or a DNS record. - **Direction of protection.** Mail arriving at your users, or mail sent to other people using your domain. - **Evidence it leaves.** Quarantine logs, message trace, tenant alerts, or aggregate reports from receivers. Deployment mode is often a setting inside a product rather than a property of the vendor. Proofpoint documents "Flexible Deployment via API or SEG" for Core Email Protection, and Cloudflare documents that its Email Security service deploys through "API, BCC/Journaling, or MX/Inline". Ask which mode a proposal assumes: it changes the migration work more than the detection engine does. ![Five criteria for evaluating email security software options](/images/editorial/email-security-software/email-security-software-evaluation-criteria.webp "1200x582") *Source: Palisade.* ## Secure email gateway A gateway sits in front of the mailbox. You point your MX record at the vendor, the vendor inspects and filters, and only surviving mail reaches your mail system. Barracuda's Email Gateway Defense documentation states the prerequisite plainly: "Before you can use Email Gateway Defense, you must modify your domain's MX records to point to Barracuda Networks mail servers", and warns that any record still pointing elsewhere can interfere with its ability to filter. Mimecast and Proofpoint sell the same shape. The model buys one enforcement point that works regardless of what runs behind it. On-premises Exchange, a hybrid migration, several platforms across acquired companies: a gateway covers them the same way and can refuse a message before any user account is involved. The cost is that you have joined your mail flow. An MX cutover is a change window, a vendor outage becomes an organization-wide delivery event, and a false positive sits in a quarantine the user cannot see. Gateways are a reasonable answer when pre-delivery blocking is a requirement and an expensive one when it is not. ## API-connected cloud email protection The API model connects to Microsoft 365 or Google Workspace with granted permissions instead of a routing change. Abnormal states its deployment as "Deploy in 60 seconds via API. No MX changes." Cloudflare's API and BCC or journaling modes put a product in the same position, beside the mail path rather than in it. Two things follow. These tools read the mailbox and the tenant, not only the message, so they can learn who normally emails whom and flag payload-free impersonation a content filter has nothing to match on. Abnormal names "novel BEC, AI-generated lures", account takeover, and invoice and payment fraud as its targets. They also act after delivery, pulling a message back out of the mailbox once a verdict changes. That is also the tradeoff: the message reaches the mailbox before anything pulls it back, an exposure window for anyone who reads mail quickly. The model also needs a supported cloud provider and a broad tenant permission grant. ## Native provider controls Both large cloud providers ship email security systems you already pay for. Microsoft documents a ladder: the built-in security features for all cloud mailboxes "prevent broad, volume-based, known email attacks", while Defender for Office 365 Plan 1 "protects email and collaboration features from zero-day malware, phishing, and business email compromise (BEC)" and Plan 2 adds simulations, hunting, and automated investigation. Google Workspace exposes named settings an admin switches on, including "Protect against domain spoofing based on similar domain names", "Protect against spoofing of employee names", and "Protect against any unauthenticated emails". For each one the admin chooses whether the action is a warning, a move to spam, or quarantine. Starting here costs no migration, and the tuning is work any product would need. Teams still buy a layer on top because capability is tied to license tier and default policies are often left as they shipped, so check what is actually enabled in your tenant first. Microsoft's own guidance also sends admins back to SPF, DKIM, and DMARC records in DNS so the service can more accurately protect against spoofing attacks. ## The email authentication layer The fourth type protects different people. Filters decide what reaches your users. Authentication decides what the rest of the internet does with mail claiming to come from your domain, including mail your gateway never sees because it was never addressed to you. [RFC 9989](https://www.rfc-editor.org/rfc/rfc9989.html) defines the mechanism: DMARC "permits the owner of an email's Author Domain to enable validation of the domain's use", to state a handling preference for mail that fails validation, and to "request reports about the use of the domain name." Two limits in the same document matter at buying time. A receiving organization "can choose to honor the Domain Owner's requested message handling for validation failures, but it is not required to do so", and "a DMARC pass by itself does not guarantee that delivery to the recipient's inbox would be safe or desirable." This layer is not an inbound filter and cannot be scored as one. It is the only one of the four that reduces impersonation of your brand in other people's inboxes. [How DMARC works](/learning/what-is-dmarc) covers the record and the alignment rule. ## How to choose ### 1. Write down the mail systems you actually have Count every mail platform in the organization, including the ones from acquisitions. A single cloud tenant opens the API option. Anything mixed or on-premises usually does not. ### 2. Decide whether pre-delivery blocking is a requirement If an auditor or your own risk position says a malicious message must never reach a mailbox, that is a gateway requirement. If the concern is fraud that reads like ordinary correspondence, post-delivery detection matches the threat better. ### 3. Enable and tune the native controls first Compare the policy state in your tenant against the settings each provider documents. A layer bought to cover a control you own but left switched off is the most common wasted line here. ### 4. Publish and maintain authentication either way No filtering type stops someone sending as your domain to your customers. That work is SPF, DKIM, and DMARC, and it continues after the filter is chosen. ### 5. Compare the evidence, not the detection claims Ask what an analyst can retrieve six weeks later: which messages were held, on what basis, who released them, and how the sender authenticated. Detection rates are vendor-measured; evidence is what you use during an incident. ## Where authentication tooling fits Palisade belongs to the fourth type only. It automates DMARC and email authentication: it reads the aggregate reports receivers send back, identifies the systems sending as your domain, drafts the SPF and DKIM fixes, and proposes each policy step for a person to approve. Palisade's [documentation](https://docs.palisade.email/) describes it as an email deliverability monitoring and DMARC compliance platform. It is not a gateway and not an API filter. It never sits in the mail path, so it cannot block, quarantine, or release an inbound message, and it will not stop a phishing email reaching your users. If inbound filtering is the open problem, the other three types are where to look. To see where a domain stands on authentication before any of these decisions, run the [email security score tool](/tools/email-security-score) and review the published records. ## Sources and further reading - [Microsoft Defender for Office 365 overview](https://learn.microsoft.com/en-us/defender-office-365/mdo-about) - [Google Workspace advanced phishing and malware protection settings](https://knowledge.workspace.google.com/admin/gmail/advanced/advanced-phishing-and-malware-protection) - [Cloudflare Email Security documentation](https://developers.cloudflare.com/cloudflare-one/email-security/) - [Proofpoint Core Email Protection](https://www.proofpoint.com/us/products/threat-defense) - [Barracuda Email Gateway Defense MX record documentation](https://documentation.campus.barracuda.com/wiki/display/EGD/How+to+Configure+MX+Records+to+Direct+Mail+Flow+to+Barracuda) - [Abnormal inbound email security](https://abnormal.ai/products/inbound-email-security) - [RFC 9989: Domain-based Message Authentication, Reporting, and Conformance](https://www.rfc-editor.org/rfc/rfc9989.html) ## Frequently asked questions ### Is a secure email gateway still needed with Microsoft 365? Not always. Microsoft documents built-in protection for all cloud mailboxes plus two Defender for Office 365 tiers, so a single-tenant organization may already be covered by what it licenses. A gateway earns its place when mail must be filtered before delivery, or when mail systems outside the tenant need one enforcement point. ### Does an API-connected platform replace a gateway? Not exactly. It removes the MX change and adds post-delivery remediation, but the message still lands in the mailbox before anything acts on it. A strict pre-delivery blocking requirement, or a mail system with no API integration, still points to the in-line path. ### Can email security software stop someone spoofing my domain to my customers? No. Inbound filtering only inspects mail addressed to your users, and mail sent from elsewhere to your customers never touches it. That abuse is the job of SPF, DKIM, and DMARC on your domain, and even then RFC 9989 notes receivers are not required to honor a published policy. ### What is the difference between an email security platform and an email security service? Usually the delivery model rather than the technology. A platform is software your team configures and operates. A service adds people and a defined scope of work, such as tuning policies or reviewing quarantine. Compare what the contract commits someone else to do. ### Where should a small team start? With the controls your mail provider already includes, enabled and tuned, then authentication on every sending domain. Neither costs extra. Add a gateway or an API-connected system once you can name the attack the current setup misses. --- # Google's stricter email sender rules (Nov 2025) Canonical: https://www.palisade.email/learning/google-is-making-email-sender-requirements-stricter-starting-nov-2025 > Google's stricter email sender rules: track Gmail's authentication, alignment, TLS, DNS, spam-rate, and unsubscribe requirements after Nov 2025. Google's stricter email sender rules refer to Gmail's ramped-up enforcement of its existing sender requirements, which Google says began in November 2025. For mail sent to personal Gmail accounts, authentication, DNS, TLS, spam controls, and unsubscribe behavior remain the documented controls. Bulk senders have additional DMARC alignment and one-click unsubscribe requirements, and Google says noncompliant traffic can experience temporary or permanent rejections. ## Quick takeaways - Last checked: August 12, 2026 - Next review: September 12, 2026 - Content owner: Samuel Chenard - Google's [email sender guidelines](https://support.google.com/a/answer/81126) apply to mail sent to personal Gmail accounts. - Google describes bulk senders as organizations that send close to 5,000 or more messages to personal Gmail accounts in 24 hours, and says bulk-sender status does not expire once assigned in its [sender-guidelines FAQ](https://support.google.com/a/answer/14229414). - Google says enforcement of its sender requirements ramped up beginning in November 2025, with noncompliant mail subject to temporary and permanent rejections. ## Who is affected Google's [current email sender guidelines](https://support.google.com/a/answer/81126) apply to senders delivering messages to personal Gmail accounts, including addresses ending in `@gmail.com` and `@googlemail.com`. Google separates the requirements into two sender classes: - All senders that deliver mail to personal Gmail accounts. - Bulk senders, which Google's [sender-guidelines FAQ](https://support.google.com/a/answer/14229414) describes as senders of close to 5,000 or more messages to personal Gmail accounts within 24 hours. Google says it combines messages sent from the same primary domain when determining bulk-sender status. The FAQ also says the classification does not expire once assigned. Treat the threshold as a planning boundary, not as a daily switch that becomes safe again after a lower-volume day. This tracker covers Gmail only. For Microsoft's separate requirements, see [What are Microsoft's new email authentication rules?](/learning/microsoft-email-auth-requirements). For broader protocol context, use the [email authentication learning hub](/learning). ![Timeline showing Gmail's February 2024 sender-requirement start and November 2025 enforcement ramp](/images/editorial/google-is-making-email-sender-requirements-stricter-starting-nov-2025/google-is-making-email-sender-requirements-stricter-starting-nov-2025-timeline.webp "1200x589") *Source: Palisade.* ## Current requirements ### Authentication for all senders - Applies to: All senders to personal Gmail accounts. - Effective: February 1, 2024. Google lists this date in its [email sender guidelines](https://support.google.com/a/answer/81126), checked August 12, 2026. - Required evidence: A newly delivered production message shows that SPF or DKIM passed. - Consequence: Google says messages that do not meet its requirements might be rate-limited, blocked, marked as spam, or not delivered as expected. A published DNS record is only one layer of evidence. It cannot prove that the application used that domain or selector for the message actually delivered to Gmail. For the sender-side record and delivered-message checks in that first requirement, follow the [Gmail email-authentication procedure](/learning/authenticate-email-for-gmail). ### DMARC and alignment for bulk senders - Applies to: Bulk senders to personal Gmail accounts. - Effective: February 1, 2024, according to Google's [email sender guidelines](https://support.google.com/a/answer/81126), checked August 12, 2026. - Required evidence: SPF and DKIM are set up, a DMARC record is published, and direct mail aligns the visible From domain with either the SPF domain or the DKIM signing domain. Google says a DMARC policy of `p=none`, [which requests no enforcement](/learning/glossary/dmarc-p-none), is acceptable for this requirement. - Consequence: Google says noncompliant mail might not be delivered as expected or might be marked as spam. A passing SPF result and a passing DKIM result do not by themselves prove DMARC alignment. Compare the visible From domain with the authenticated domains in a delivered message. ### Forward and reverse DNS - Applies to: All senders to personal Gmail accounts. - Effective: February 1, 2024. Google's [email sender guidelines](https://support.google.com/a/answer/81126) list valid forward and reverse DNS as a sender requirement, checked August 12, 2026. - Required evidence: Each production sending IP has a PTR record, and the hostname returned by that PTR record resolves back to the same IP through A or AAAA DNS. - Consequence: Google says mail that fails applicable sender requirements might be rate-limited, blocked, marked as spam, or not delivered as expected. ### TLS and message formatting - Applies to: All senders to personal Gmail accounts. - Effective: February 1, 2024. Google's [email sender guidelines](https://support.google.com/a/answer/81126) require TLS for transmission and messages formatted according to RFC 5322, checked August 12, 2026. - Required evidence: Production SMTP logs or a controlled delivery test confirms TLS on the sending path, and the delivered message is correctly formatted. - Consequence: Google says mail that fails applicable sender requirements might not be delivered as expected. Public DNS does not prove that a particular SMTP connection used TLS. Use the production MTA or sending-service evidence for this check. ### Spam rate - Applies to: All senders to personal Gmail accounts. - Effective: Google's current [email sender guidelines](https://support.google.com/a/answer/81126) state the operational guidance, checked August 12, 2026. - Required evidence: The domain's spam rate in Google Postmaster Tools. - Consequence: Google advises senders to keep spam rates below `0.10%` and avoid reaching `0.30%` or higher. The `0.10%` figure is an operating recommendation. The `0.30%` figure is a boundary Google tells senders to avoid, not a target for normal operations. A public checker cannot access Gmail's private complaint and reputation signals. ### One-click unsubscribe - Applies to: Marketing and subscribed messages from bulk senders. Google excludes transactional messages from this requirement. - Effective: Google's bulk-sender requirements began February 1, 2024. The [sender-guidelines FAQ](https://support.google.com/a/answer/14229414) says senders that already had an unsubscribe link had until June 1, 2024 to implement one-click unsubscribe for commercial and promotional messages, checked August 12, 2026. - Required evidence: A delivered covered message includes the one-click unsubscribe headers and a visible body unsubscribe link. The unsubscribe endpoint accepts the required request and suppresses the recipient in the actual sending system. - Consequence: Google says it does not automatically reject or mark a message as spam solely because one-click unsubscribe is missing. Google also says senders without it are ineligible for delivery-issue mitigation. ## Implementation and validation ### 1. Inventory every sending path List each platform that sends mail using the domain, including marketing, support, billing, identity, recruiting, and low-volume automated systems. Record its visible From domain, envelope domain, DKIM signing domain, sending IPs, and whether it sends covered promotional mail. For a useful interpretation of report data during this inventory, see [What do Google's updated DMARC reports reveal?](/learning/how-do-google-updated-dmarc-reports-reveal-sender-requirement-failures). ### 2. Check public DNS before changing records Inspect the published DMARC record for the exact visible sending domain, then compare it with a real delivered message. A structural DMARC example is below. > Do not publish this example as a production record without confirming the reporting addresses, policy plan, and every legitimate sending source. ```text _dmarc.yourdomain.com TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com" ``` Use the [DMARC checker](/tools/dmarc) to inspect the public record. It can show the record visible in public DNS, but it cannot prove every production sender aligns, reveal Gmail's private enforcement decision, or guarantee later delivery. ### 3. Validate a delivered message from each production path Send a controlled message from every listed source to a personal Gmail mailbox you can inspect. Confirm SPF, DKIM, and DMARC results in the receiver-added authentication results. Then compare the domains used by the message with the visible From domain. Repeat this check after a DNS or sending-platform change. A green status in a sender platform does not replace evidence from the message path Gmail received. ### 4. Validate transport, DNS, and unsubscribe controls For each sending IP, confirm the PTR hostname and forward resolution. Use production logs or the sending provider's documented transport evidence to confirm TLS. For covered marketing or subscribed messages, verify these message headers and test the one-click endpoint without a login, cookie, or redirect: ```text List-Unsubscribe: <https://example.com/unsubscribe/opaque-id> List-Unsubscribe-Post: List-Unsubscribe=One-Click ``` A successful HTTP response is not enough if the recipient remains eligible to receive later marketing mail. Confirm suppression in the system that sends the message. ### 5. Review Gmail's private signals and aggregate evidence Use Google Postmaster Tools for spam-rate and compliance evidence. Then use DMARC aggregate reports to identify sources and alignment failures that a one-time DNS check cannot show. Google's February update is useful historical context in Just In: February 14th Update for Google's Email Sender Requirements. ## Change log ### August 12, 2026 Rechecked Google's [email sender guidelines](https://support.google.com/a/answer/81126) and [sender-guidelines FAQ](https://support.google.com/a/answer/14229414). Confirmed the all-sender and bulk-sender classes, the February 1, 2024 requirement start, the close-to-5,000-message bulk-sender description, permanent bulk classification, and the documented November 2025 enforcement ramp. Clarified the difference between Google's `0.10%` operating recommendation and its instruction to avoid `0.30%` or higher. ### November 2025 Google's sender-guidelines FAQ says enforcement ramped up beginning in November 2025. Google states that messages failing its sender requirements can experience disruptions, including temporary and permanent rejections. ## Check the published DMARC control, then close the sender inventory gap Start by checking the public DMARC record for the domain used in the visible From address. Compare the result with headers from a recently delivered Gmail message before changing policy. A public record check does not identify every production source that uses the domain, show which source later fails alignment, or control Gmail's private delivery decision. Palisade is agentic DMARC software that analyzes DMARC aggregate-report data, identifies sources and authentication or alignment issues, and creates prioritized remediation tickets. It can propose the next policy step when the evidence supports it, while your team reviews the evidence and applies the change. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=provider_requirements&utm_content=google-is-making-email-sender-requirements-stricter-starting-nov-2025) For a provider-specific implementation of these authentication checks, see [Why does Gmail report TLS errors?](/learning/gmail-tls-errors). ## Sources and further reading - [Google email sender guidelines](https://support.google.com/a/answer/81126) - [Google sender-guidelines FAQ](https://support.google.com/a/answer/14229414) - [RFC 9989: Domain-based Message Authentication, Reporting, and Conformance](https://www.rfc-editor.org/rfc/rfc9989.html) ## Frequently asked questions ### Did Gmail create new sender requirements in November 2025? No. Google's sender requirements began in February 2024. Google says enforcement ramped up beginning in November 2025, including temporary and permanent rejections for mail that fails the requirements. ### Are small senders exempt from Gmail's requirements? No. Google's guidelines apply to all senders to personal Gmail accounts. The bulk-sender classification adds requirements such as DMARC alignment and one-click unsubscribe for covered messages. ### Does a DMARC policy need to be set to quarantine or reject for Gmail? No. Google's email sender guidelines state that bulk senders can meet the DMARC publication requirement with a `p=none` policy. The sender must still meet Google's documented alignment requirement for direct mail. ### Does a passing DMARC DNS check prove Gmail will deliver my email? No. A DNS check shows the public record at the time of the lookup. It does not prove the sending platform authenticated a specific message, that every source aligns, or that Gmail will make a particular delivery decision. ### Is a 0.30% spam rate acceptable? No. Google advises senders to keep spam rates below `0.10%` and to avoid reaching `0.30%` or higher. Treat `0.10%` as the operating target and investigate rising complaints before the rate approaches Google's upper boundary. --- # MSP email sender inventory Canonical: https://www.palisade.email/learning/msp-email-sender-inventory > MSP email sender inventory: build a client-by-client record of senders, evidence, ownership, authorization, exceptions, and review dates today. An MSP email sender inventory is a per-client record of each service that sends as a client domain, the evidence for that activity, its business owner, its authentication state, and its authorization decision. Build it before changing SPF, DKIM, or DMARC policy. DMARC reports and public DNS identify candidates, but they do not prove that a client approves a sender or that the service uses the expected production path. ## Quick takeaways - Keep sender records separate by client, domain, service, and sending identity. - Treat DMARC reports, DNS answers, interviews, and delivered-message headers as different evidence types. - Record business approval separately from SPF, DKIM, and DMARC results. - Give unknown, seasonal, retired, and blocked sources an exception state and review date. - A public DMARC lookup documents a published record, not the full production sender population. - Use the inventory as the handoff record for remediation, enforcement decisions, and client reporting. ## Operating context and ownership A sender inventory is the durable record produced during a broader [client email security assessment](/learning/how-do-msps-run-an-email-security-assessment-for-a-new-client). The assessment finds initial domains and sources. The inventory keeps those findings reviewable when a client adds a marketing service, changes a return path, retires an application, or acquires another domain. This is a Palisade-authored operating framework, not a mailbox-provider requirement. [RFC 9989 defines DMARC evaluation and receiver policy disposition for the RFC5322.From domain](https://www.rfc-editor.org/rfc/rfc9989.html). A source observed in DMARC data is therefore a candidate for review. It is not automatically an approved sender. Assign responsibilities for every client record: - The MSP maintains the register, collects evidence, coordinates remediation, and records handoffs. - The client service owner confirms the business purpose and authorizes continued use of the domain. - The sender owner confirms the sending-service configuration and supplies a delivered-message sample. - The DNS change owner approves and applies DNS changes after the required client approval. - The sender platform controls its own configuration options. - The receiving mailbox provider controls its own message-handling decision. A small client may assign several roles to one person. Keep the fields separate. A sender can pass an authentication check while no client owner can confirm its business purpose. A client can approve a service whose sender owner still needs to correct alignment. This separation matters across tenants. [Palisade's MSP guidance](/for-managed-service-providers) is relevant when an MSP needs a repeatable record, but an approval, exception, or owner for one client must never transfer to another client using the same sending platform. ## Evidence to collect Create one record per client domain and sending identity. [RFC 9990 defines DMARC aggregate feedback reports that include source IP, authentication, and policy-result data](https://www.rfc-editor.org/rfc/rfc9990.html). Aggregate reports help discover candidates, but they need corroboration before an MSP treats a source as authorized. Collect four evidence layers where they apply: - DNS: public DMARC, SPF, and DKIM records from authoritative DNS and a public resolver. - Vendor: the sender platform's current authentication or verification status. - Message: a real delivered message from the exact production path. - DMARC: aggregate-report evidence after data accumulates. Public DNS proves what is published. It does not prove that an application is using that identity. A vendor indicator does not replace a delivered-message check. A receiver's `Authentication-Results` field also needs a trust boundary: [RFC 8601 requires a consumer to assess its trust relationship with the validating MTA and message path](https://www.rfc-editor.org/rfc/rfc8601.html). Use this portable record in a PSA ticket, internal register, or client reporting package: ```yaml client: northwind.example domain: yourdomain.com sending_platform_service: billing-service owner: client-finance-operations business_purpose: invoices and payment notices visible_from: billing@yourdomain.com envelope_domain: mail.yourdomain.com dkim_d_selector: yourdomain.com / selector1 spf_authorization_reference: include:spf.example-sender.test dmarc_alignment_result: pending message verification evidence_capture_date_source: 2026-08-12 / aggregate report and redacted header change_approval: pending client approval review_owner_date: msp-service-owner / 2026-10-01 authorization_state: pending-confirmation next_action: sender owner supplies a current production-message sample ``` This is a fictional, redacted example. Do not copy account-generated selectors, CNAME targets, tokens, or hostnames from another tenant. Record the actual generated values only in the applicable client's restricted operational record. ![Sender inventory lifecycle showing evidence collection, owner confirmation, authorization or exception, and scheduled review for each client domain](/images/editorial/msp-email-sender-inventory/msp-email-sender-inventory-lifecycle.webp "1200x980") *Source: Palisade.* ![Sender inventory decision flow from observed source to evidence review, owner confirmation, authorization, exception, or remediation](/images/editorial/msp-email-sender-inventory/msp-email-sender-inventory-decision-flow.webp "1200x676") *Source: Palisade.* Use the [DMARC checker](/tools/dmarc) to record the publicly visible policy and aggregate-report destination for each client domain. That is a useful inventory input. A public lookup cannot reveal every sender, confirm a sender-platform account, authorize a source, verify the exact production path, or predict a mailbox provider's future handling decision. ## How to run the workflow ### 1. Define client scope and accountable owners Owner: MSP service owner. Input: contracted domain list, client contacts, and DNS ownership details. Output: a client-scoped domain register with named business approvers and DNS change owners. List organizational domains, sending subdomains, and protected non-sending domains separately. Record the client boundary before collecting candidates. If a discovered source belongs to an out-of-scope domain, record it as a handoff rather than treating it as an authorized change request. ### 2. Add observed sender candidates Owner: MSP analyst. Input: DMARC aggregate reports, DNS records, client interviews, and sender documentation. Output: candidate records marked `report-observed` or `unknown`. [Google's sender guidelines recommend DMARC reports to monitor mail sent from, or appearing to be sent from, a domain](https://support.google.com/mail/answer/81126). Compare report observations with client context and published DNS. Ask owners of billing, support, marketing, HR, and line-of-business systems what each service sends, which visible From domain it uses, whether it remains active, and who can provide a current message sample. A quiet report period does not establish that a low-frequency source is retired. ### 3. Attach evidence and test the claimed path Owner: MSP analyst with the sender owner. Input: report period, DNS answers, vendor status, and a message sent through the real path. Output: an evidence-backed record or a stated evidence gap. For a material sender, retain the relevant report period, DNS result, and a redacted message sample from the exact sending route. Confirm the visible From domain, envelope domain, DKIM `d=` domain and selector, plus SPF and DMARC results. The purpose is to prove the claimed path well enough to make an operational decision, not to claim that a single sample proves every future message will authenticate. > Do not advance a DMARC policy because a public record looks correct. Validate the sender platform, a delivered message, and later aggregate-report evidence for the affected client domain. ### 4. Obtain owner confirmation and record the decision Owner: client service owner and sender owner. Input: the candidate record and attached evidence. Output: an authorization state and owner-specific next action. Use states such as `authorized`, `pending-confirmation`, `unauthorized`, `retired`, and `exception`. Record why the state was selected, who made the decision, and when it must be reviewed. An SPF include is not business authorization. [RFC 7208 specifies SPF evaluation through DNS mechanisms](https://www.rfc-editor.org/rfc/rfc7208.html), but it does not define client ownership or business approval. Treat authorization as an MSP operating decision supported by client confirmation. ### 5. Create a scoped remediation handoff Owner: MSP service owner. Input: an authorized record with an authentication or alignment gap. Output: a ticket assigned to the sender owner or DNS owner. Write the handoff around observable evidence: affected domain and identity, current result, requested limited change, approving party, rollback condition, and same-path retest. "Fix DMARC" does not identify a safe action. For clearly inventoried services that change sender authorization frequently, Hosted SPF can be considered as a documented SPF-maintenance option. It does not replace sender ownership, message validation, or client approval. ### 6. Hand verified inventory into policy planning Owner: MSP service owner and client approver. Input: completed sender records, exceptions, and review dates. Output: a client-specific enforcement recommendation or a documented reason to wait. Use the inventory as the input to a staged policy decision. [Google's stricter sender requirements](/learning/google-is-making-email-sender-requirements-stricter-starting-nov-2025) may affect client priorities, but provider requirements do not remove the need to validate each sender path and obtain client approval. Do not use portfolio progress as proof that a particular client is ready. Each domain needs its own evidence, approval, rollback condition, and post-change review. ## Exceptions and escalation Keep an exception register linked to the sender inventory. Escalate when: - No client owner can confirm whether a source has a business purpose. - The sender owner cannot provide a safe production-message sample. - DNS ownership or approval authority is unclear. - A business-critical sender has no test window or rollback path. - Public DNS, vendor status, and delivered-message evidence conflict. - A sender is retired in client documentation but continues to appear in reports. The MSP records the evidence, affected tenant, requested decision, owner, and next review date. The client accepts any remaining business risk before an enforcement change. The sender platform and mailbox provider retain control over their respective systems and decisions. Use an `exception` state when evidence is incomplete. Do not convert it to `authorized` because a service name is familiar or because another client uses the same provider. ## Reporting and success measures Review the portfolio monthly and provide a client-facing summary on the agreed cadence. Report evidence and decisions, not a universal protection score: - In-scope domains with a named client approver and DNS change owner. - Sender records by authorization state. - Unknown sources without an assigned owner. - Exceptions past their review date. - Authentication or alignment remediation tickets by owner. - Policy changes with recorded approval, before-and-after evidence, and rollback conditions. The recurring gap begins after the first register is complete. Senders, owners, and client decisions change over time. Palisade's [guidance for fixing authentication issues](https://docs.palisade.email/guides/fixing-authentication-issues/) describes report-based, source-specific authentication issues and recommended actions. Palisade is agentic DMARC software that analyzes DMARC aggregate-report data, identifies sources and authentication or alignment issues, and creates prioritized remediation tickets. It can propose the next policy stage when evidence indicates readiness, while a human reviews the evidence and applies any change. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=msp_operations&utm_content=msp-email-sender-inventory) when the sender register has become recurring portfolio work rather than a one-time intake task. Palisade does not authorize a client's senders, make external DNS changes without the required access and approval, or guarantee delivery outcomes at receiving mailbox providers. ## Sources and further reading - [RFC 9989: Domain-based Message Authentication, Reporting, and Conformance](https://www.rfc-editor.org/rfc/rfc9989.html) - [RFC 9990: DMARC aggregate report format](https://www.rfc-editor.org/rfc/rfc9990.html) - [RFC 8601: Authentication-Results header field](https://www.rfc-editor.org/rfc/rfc8601.html) - [RFC 7208: Sender Policy Framework](https://www.rfc-editor.org/rfc/rfc7208.html) - [Google email sender guidelines](https://support.google.com/mail/answer/81126) - [Palisade guidance for fixing authentication issues](https://docs.palisade.email/guides/fixing-authentication-issues/) ## Frequently asked questions ### What is an MSP email sender inventory? An MSP email sender inventory is a client-specific register of services that send as a domain, their authentication evidence, business purpose, accountable owners, authorization decision, exceptions, and review date. ### Does a DMARC aggregate report prove that a sender is authorized? No. A DMARC aggregate report can identify a source and show authentication or policy-result evidence, but client approval and sender-owner confirmation determine whether that source is authorized for the domain. ### Can an SPF record identify every approved sender? No. SPF evaluates DNS-based authorization for an envelope identity. It does not identify the client business owner, confirm a service is still approved, or prove the application uses the expected production configuration. ### Should MSPs keep one sender list for all clients using the same platform? No. Each client needs a separate authorization, owner, evidence record, exception state, and review date. A platform used by one client does not establish approval for another tenant. ### When can an MSP use a public DMARC checker? An MSP can use a public DMARC checker to capture the published DMARC policy and reporting destination as domain-level evidence. The result does not verify the complete sender population or the exact production sending path. --- # Proofpoint competitors: who else serves the same job Canonical: https://www.palisade.email/learning/proofpoint-competitors > Proofpoint competitors grouped by deployment model: MX gateways, API-connected tools, native Microsoft and Google controls, and the DMARC layer. Proofpoint's competitors sort by where they sit in the mail path rather than by feature list. Mimecast and Cloudflare document an MX-routed gateway, the placement Proofpoint also supports. Abnormal, Barracuda, Mimecast and Cloudflare all document an API connection that leaves MX records alone. Microsoft and Google run controls inside the platform you already pay for. Authentication products, including Proofpoint's own Email Fraud Defense, work in DNS and sit beside a filter instead of replacing one. ## Quick takeaways - **Deployment model decides what genuinely replaces Proofpoint.** A gateway swap changes mail routing. An API connection does not. - **Microsoft is the only rival here with a published per-user price:** Defender for Office 365 Plan 1 at $2.00 and Plan 2 at $5.00 per user per month, paid yearly. - **Proofpoint's own list pricing covers Essentials only**, in two data sheets stamped 10/21 and 5/22 whose figures disagree. - **Mimecast, Barracuda, Abnormal and Cloudflare publish no price**, so shortlists get built on scope rather than cost. - **DMARC is a separate purchase in Proofpoint's catalog**, sold as Email Fraud Defense and packaged in the top Prime tier. - **Every vendor fact below was read from a first-party page on 12 August 2026.** ## Who this comparison is for An IT admin, security lead or MSP technician holding a Proofpoint quote or renewal who wants to know which products do the same job. It assumes mail runs on Microsoft 365 or Google Workspace. If the category itself is still fuzzy, [the four types of email security software](/learning/email-security-software) sets out the map first. Head-to-head vendor pages sit on the [comparison hub](/compare). ![Who competes with Proofpoint, grouped by how they deploy](/images/editorial/proofpoint-competitors/proofpoint-competitors-field.webp "1200x630") *Source: Palisade.* ## How the options were evaluated Each product was read on its own vendor pages on 12 August 2026. Review sites and reseller catalogs were excluded. Four things were recorded: - **Deployment model.** MX-routed gateway, API connection, post-delivery inspection, or a choice among them. - **Replacement or addition.** Whether the product takes over the placement Proofpoint occupies, or sits beside it. - **Published price.** Whether a figure appears on the vendor's own page. - **Where DMARC sits.** Whether domain authentication is included, sold separately, or absent. Several of these pages advertise detection percentages. Each vendor measured its own, so nothing below rests on one. ### What counts as the same job Proofpoint sells one filtering product with two placements. [Its Core Email Protection page](https://www.proofpoint.com/us/products/threat-defense) lists "Flexible Deployment via API or SEG" and names phishing, business email compromise, ransomware and account takeover. [Its buying page](https://www.proofpoint.com/us/products/how-to-buy/collaboration-security) packages that into Core, Tier 2, Tier 3 and Prime, adding account takeover protection, then threat-guided training, then impersonation protection with hosted DMARC, DKIM and SPF services. A rival replaces Proofpoint only if it covers the package you were quoted. *Source: Palisade.* *Source: Palisade.* ## Gateways in the MX path [Mimecast's integrated cloud email security page](https://www.mimecast.com/products/email-security/integrated-cloud-email-security/) describes MX-based deployment as perimeter protection, with all incoming mail routed through its gateway first and threats blocked in line. [Cloudflare's Email Security documentation](https://developers.cloudflare.com/cloudflare-one/email-security/) lists pre-delivery placement through MX or inline as one of three supported approaches, covering phishing, malware, business email compromise, vendor email fraud and spam. These are the options that take Proofpoint's place in the delivery path. The swap is a routing change, so it brings a cutover window and a period where both vendors' policies apply; [check your current MX records](/tools/mx) before you scope one. If your requirements say mail must be inspected before delivery, this group satisfies them. ## Tools connected by API [Abnormal's inbound email security page](https://abnormal.ai/products/inbound-email-security) states "Deploy in 60 seconds via API. No MX changes." and describes the product as built for attacks with no payload and no prior signature. [Its platform page](https://abnormal.ai/platform) lists native API integrations with Microsoft 365, Google Workspace, Okta, CrowdStrike and Splunk, with no agents or proxies. [Barracuda's Email Protection page](https://www.barracuda.com/products/email-protection) states the product connects to Microsoft 365 or Google Workspace with no mail exchange (MX) changes and is operational in minutes rather than weeks. Its threat list spans phishing, malware, spam, account takeover, domain fraud with DMARC and post-delivery weaponization. Mimecast and Cloudflare sell this model too: Mimecast as protection layered into the cloud email platform with no MX record changes and no mail flow disruption, Cloudflare as post-delivery deployment through BCC and journaling. All of them read messages that have already arrived, so the question is what each can do with a message already in a mailbox, and how fast. ## Native controls you may already own [Microsoft documents anti-malware, anti-spam and anti-phishing protection](https://learn.microsoft.com/en-us/defender-office-365/eop-about) as included in all organizations with cloud mailboxes and on by default through the default threat policies. An administrator cannot switch them off, though preset or custom policies can override them, so measure any quote against that baseline. [Defender for Office 365](https://learn.microsoft.com/en-us/defender-office-365/mdo-about) then splits in two: Plan 1 adds Safe Attachments, Safe Links, impersonation protection and real-time detections, Plan 2 adds phishing simulations, post-breach investigation, hunting and automation. [Microsoft's pricing page](https://www.microsoft.com/en-us/security/business/siem-and-xdr/microsoft-defender-office-365) lists Plan 1 at $2.00 and Plan 2 at $5.00 per user per month, both paid yearly. Google Workspace carries Gmail filtering in the seat price. Every published tier [lists phishing and spam protection that blocks more than 99.9% of attacks](https://workspace.google.com/pricing), which is Google's own figure, while data loss prevention and S/MIME sit under Enterprise. [Advanced phishing and malware protection](https://knowledge.workspace.google.com/admin/gmail/advanced/advanced-phishing-and-malware-protection) is a set of administrator settings, and for each one the administrator chooses whether a suspicious message arrives with a warning banner, moves to spam, or is held in admin quarantine. ## The authentication layer beside the filter Nothing in this last group filters inbound mail. It governs which senders may use your domain, which is what stops mail sent to other people in your name. Proofpoint sells this work separately. [Email Fraud Defense](https://www.proofpoint.com/us/products/email-protection/email-fraud-defense) is its own product, offering hosted SPF, hosted DKIM and hosted DMARC records with dedicated consultants who guide the buyer through each step of the rollout, and those hosted services appear only in Prime. [Mimecast's DMARC Analyzer](https://www.mimecast.com/products/dmarc-analyzer/) is likewise its own product, built around aggregate, forensic and TLS reports, self-service tools and a recommendation engine; it makes no claim to publish or change a customer's DNS records. Barracuda names domain fraud with DMARC inside its threat list. A vendor that sells both a filter and a DMARC product is first-party evidence that the two are different purchases. If Proofpoint's DMARC path is what you are pricing, the [Proofpoint DMARC alternative comparison](/proofpoint-dmarc-alternative) covers Email Fraud Defense on its own terms. ## What each vendor publishes about price Proofpoint publishes list prices for the Essentials line only. [A US data sheet](https://www.proofpoint.com/sites/default/files/data-sheets/pfpt-uk-ds-essentials-pricelist-msrp-us.pdf) stamped 10/21 quotes Business at $2.75, Advanced at $3.75 and Professional at $5.33 per active user per month. [An EMEA sheet](https://www.proofpoint.com/sites/default/files/data-sheets/pfpt-uk-ds-essentials-price-list-monthly-msrp-emea.pdf) stamped 5/22 adds a Beginner package and shows different USD figures. Both are dated records, not a rate card. For Core, Tier 2, Tier 3 and Prime, Proofpoint states only that budgetary pricing comes from the number of user licences and the contract term, with exceptions that depend on consumption. [Mimecast's plans page](https://www.mimecast.com/products/mimecast-plans/) names Critical, Advanced and Premium for threat protection and replaces every figure with contact-for-pricing wording. It adds that from 15 August 2025 new customers buy the new email security plans, and that migrating can carry an additional cost. [Barracuda's plans page](https://www.barracuda.com/products/email-protection/plans) names Advanced, Premium and Premium Plus with a feature comparison and no figure. Abnormal and Cloudflare publish none. Quote-only pricing is normal here and says nothing about cost. ## Where Palisade fits Palisade belongs in the last group and nowhere else. It is DMARC automation, not a gateway: it does not filter, sandbox, rewrite links in or quarantine inbound mail, so it replaces nothing above. [Its documentation](https://docs.palisade.email/) covers DMARC, SPF, DKIM, BIMI and MTA-STS, hosted records, aggregate report processing, sender classification and PSA ticketing. [Hosted DMARC](https://docs.palisade.email/page-breakdowns/hosted-dmarc) publishes and maintains the record through a CNAME delegation, so a later policy move needs no further DNS edit. The agent investigates every sender, drafts every fix and proposes each policy step, and you approve before anything ships. If Prime is on your quote for its hosted DMARC services, this is the layer to compare it against. ## How to choose - **You are replacing a placement, not a product.** Only an MX-routed option takes Proofpoint's spot in the delivery path. Mimecast and Cloudflare each document one. - **You cannot touch mail routing.** Abnormal, Barracuda, Cloudflare and Mimecast all document a connection that leaves MX records untouched. - **You have not configured what you already pay for.** Microsoft's default policies are on and cannot be turned off, so establish that baseline before buying a layer above it. - **Prime is on the quote because of DMARC.** That is a separate market, and Mimecast, Barracuda and Palisade sell into it without a gateway attached. - **You do not yet know which layer is failing.** Run the domain through the free [email security score](/tools/email-security-score) before shortlisting anyone. ## Sources and further reading Every page below was read on 12 August 2026. - [Proofpoint Core Email Protection](https://www.proofpoint.com/us/products/threat-defense), [the collaboration security buying page](https://www.proofpoint.com/us/products/how-to-buy/collaboration-security) and [Email Fraud Defense](https://www.proofpoint.com/us/products/email-protection/email-fraud-defense). - Proofpoint's [US Essentials price list](https://www.proofpoint.com/sites/default/files/data-sheets/pfpt-uk-ds-essentials-pricelist-msrp-us.pdf) and [EMEA Essentials price list](https://www.proofpoint.com/sites/default/files/data-sheets/pfpt-uk-ds-essentials-price-list-monthly-msrp-emea.pdf). - [Mimecast integrated cloud email security](https://www.mimecast.com/products/email-security/integrated-cloud-email-security/), [Mimecast plans](https://www.mimecast.com/products/mimecast-plans/) and [Mimecast DMARC Analyzer](https://www.mimecast.com/products/dmarc-analyzer/). - [Barracuda Email Protection](https://www.barracuda.com/products/email-protection) and [its plans page](https://www.barracuda.com/products/email-protection/plans). - [Abnormal inbound email security](https://abnormal.ai/products/inbound-email-security) and [the Abnormal platform page](https://abnormal.ai/platform). - [Microsoft Defender for Office 365 overview](https://learn.microsoft.com/en-us/defender-office-365/mdo-about), [built-in protection for cloud mailboxes](https://learn.microsoft.com/en-us/defender-office-365/eop-about) and [Defender for Office 365 plans and pricing](https://www.microsoft.com/en-us/security/business/siem-and-xdr/microsoft-defender-office-365). - [Cloudflare Email Security documentation](https://developers.cloudflare.com/cloudflare-one/email-security/). - [Google Workspace pricing](https://workspace.google.com/pricing) and [advanced phishing and malware protection](https://knowledge.workspace.google.com/admin/gmail/advanced/advanced-phishing-and-malware-protection). - [Palisade documentation](https://docs.palisade.email/) and [hosted DMARC](https://docs.palisade.email/page-breakdowns/hosted-dmarc). ## Frequently asked questions ### Who are Proofpoint's main competitors? Mimecast, Barracuda, Abnormal Security and Cloudflare Email Security compete for the same filtering budget, and the native controls in Microsoft 365 and Google Workspace compete by already being included. On the authentication side, where Proofpoint sells Email Fraud Defense, the rivals are Mimecast DMARC Analyzer and the DMARC platforms. ### Can Abnormal or Barracuda replace a Proofpoint gateway? Only in part. Both connect by API and leave MX records alone, so they take over detection without taking Proofpoint's place in the delivery path. Abnormal states its own position that Abnormal with Microsoft or Google replaces a gateway, which is positioning rather than a tested result. ### Is Microsoft Defender for Office 365 enough on its own? Not automatically, and answering it needs your own data. Microsoft documents anti-malware, anti-spam and anti-phishing filtering as on by default for every organization with cloud mailboxes. Configure those policies, add Plan 1 or Plan 2, then measure what still arrives. ### Which Proofpoint competitors publish their prices? Microsoft publishes per-user list prices for Defender for Office 365, and Google publishes per-seat Workspace prices, though currency and promotional rates vary by region. Mimecast, Barracuda, Abnormal and Cloudflare publish none, and Proofpoint publishes list prices only for Essentials. ### Does switching away from Proofpoint fix domain spoofing? No. Inbound filtering protects the mailboxes you own. Mail an attacker sends to other people using your domain never passes through your filter. Stopping that is the authentication layer: SPF, DKIM and DMARC alignment published in your DNS. It stays a separate purchase after any gateway swap. --- # Why does Gmail report an SPF error? Canonical: https://www.palisade.email/learning/why-does-gmail-report-an-spf-error > Gmail SPF errors mean Gmail could not authorize the sending IP for the envelope domain it evaluated. Inspect headers, repair the SPF path, and retest now. Gmail reports an SPF error when it cannot authorize the IP address that connected to Gmail for the envelope sender domain it evaluated, or when it cannot evaluate that domain's SPF policy. Start with Gmail's trusted `Authentication-Results` header and its `smtp.mailfrom` value. The visible From address can be different, so editing that domain's SPF record may not affect the failing mail stream. ## Quick takeaways - SPF evaluates the SMTP envelope sender domain, usually shown as `smtp.mailfrom`, rather than the visible From address. - `fail` means the connecting IP is not authorized by the evaluated SPF policy. - `permerror` commonly points to a permanent SPF record problem, including duplicate records or too many DNS lookups. - `temperror` points to a temporary DNS evaluation failure and should be investigated before rewriting the policy. - An SPF pass does not prove DMARC passes, because SPF must also align with the visible From domain. - A forwarded message can fail SPF because Gmail receives it from the forwarder's IP. ## What does the failure mean? [SPF authorizes an SMTP client for the domain used in the SMTP `MAIL FROM` command](https://www.rfc-editor.org/rfc/rfc7208.html#section-2.1). If that command has an empty reverse-path, SPF can evaluate the SMTP HELO identity instead. Google's [authentication troubleshooting guidance](https://support.google.com/a/answer/81126) directs senders to inspect message headers when diagnosing authentication results. This illustrative redacted header fragment shows the evidence to preserve: ```text Authentication-Results: mx.google.com; spf=fail (google.com: domain of bounce@yourdomain.com does not designate 192.0.2.10 as permitted sender) smtp.mailfrom=bounce@yourdomain.com ``` [RFC 8601 defines `Authentication-Results` as a receiver-added field for reporting message-authentication checks](https://www.rfc-editor.org/rfc/rfc8601.html). In this example, Gmail evaluated `yourdomain.com` for `bounce@yourdomain.com` and found that `192.0.2.10` was not authorized. The result establishes what Gmail evaluated for that received message. It does not identify the owner of the sending IP, prove why Gmail made an inbox or rejection decision, or show every service that sends with the domain. ![Flow showing Gmail Authentication-Results evidence, the evaluated SPF domain, its public SPF record, and a same-path retest](/images/editorial/why-does-gmail-report-an-spf-error/why-does-gmail-report-an-spf-error-spf-evidence-flow.webp "1200x676") *Source: Palisade.* ## What usually causes it? ### The sending service is missing from the evaluated SPF policy A marketing platform, CRM, help desk, billing service, or outbound relay may use an IP address that the envelope domain does not authorize. Google's [SPF setup guidance](https://knowledge.workspace.google.com/admin/security/set-up-spf) says to identify every service that sends mail for a domain and add the required authorization to that domain's SPF record. This is the likely cause only when the header identifies an expected service's IP and the provider documents the authorization it needs. Do not add an [`include:` value](/learning/glossary/spf-include) because it appears in another domain's SPF record. ### The record was changed on the visible From domain SPF normally evaluates `smtp.mailfrom`, not the address recipients see in the From field. A message can have `From: notices@yourdomain.com` while Gmail evaluates `smtp.mailfrom=bounce@mail.yourdomain.com`. This follows from the SPF protocol rule. It is not a documented Gmail-specific mapping. If Gmail evaluated `mail.yourdomain.com`, [inspect the TXT record published there](/tools/dns-lookup). Updating `yourdomain.com` does not repair a policy published on its subdomain. ### More than one SPF record exists [RFC 7208 requires `permerror` when a DNS lookup returns more than one SPF record](https://www.rfc-editor.org/rfc/rfc7208.html#section-4.5). This often happens when a second TXT record beginning with [`v=spf1`](/learning/glossary/spf-v-spf1) is added instead of merging required mechanisms into the existing policy. The evaluated hostname needs one SPF policy. Other TXT records can exist, but they must not be additional SPF records. ### The SPF policy exceeds the DNS lookup limit [RFC 7208 limits SPF evaluation to 10 DNS-querying mechanisms and modifiers](https://www.rfc-editor.org/rfc/rfc7208.html#section-4.6.4). `include`, `a`, `mx`, `exists`, `redirect`, and nested lookups can contribute to that limit. Exceeding it produces `permerror`. Remove services that no longer send mail before altering the record. If frequent sender changes make the policy difficult to maintain, evaluate an SPF management approach only after confirming the lookup count and the actual active senders. That approach still needs public DNS validation and does not prove delivery at Gmail. ### DNS evaluation had a temporary failure A `temperror` means the SPF evaluation encountered a temporary error. [RFC 7208 distinguishes temporary errors from permanent SPF policy errors](https://www.rfc-editor.org/rfc/rfc7208.html#section-2.6.6). Check authoritative DNS and public resolver responses before changing the record. A public DNS result is a point-in-time observation. It cannot prove Gmail used the same resolver response or that the production sender used the expected return path. ### A forwarder changed the connecting IP [Google explains that forwarding and mailing lists can affect authentication](https://support.google.com/mail/answer/180707). SPF depends on the final SMTP connection, so a forwarder can cause Gmail to see its IP instead of the original sender's authorized IP. Forwarding is an inference until the original sending route and Gmail-received copy are compared. DKIM may still provide aligned authentication for DMARC after SPF fails on a forwarded message. ## How do I diagnose the failure? ### 1. Preserve the Gmail-received message source Open the original message source in Gmail and save the complete headers. Record the exact `Authentication-Results` line, `Return-Path`, visible From domain, `smtp.mailfrom`, `smtp.helo`, SPF result, DKIM result, DMARC result, Message-ID, and sending time. Use Gmail's receiver-added result. Do not diagnose from a screenshot of the rendered message or a copy that someone forwarded, because forwarding can create a different SMTP path. ### 2. Build an SPF evidence packet Keep these items together before requesting a DNS or sending-platform change: - Visible From domain: the domain in the recipient-visible `From:` field. - SPF envelope domain: the domain or address shown in `smtp.mailfrom`, or the HELO identity if the reverse-path was empty. - Exact result: the complete trusted `spf=pass`, `spf=fail`, `spf=softfail`, `spf=temperror`, or `spf=permerror` diagnostic. - Public SPF owner record: the TXT record at the exact hostname Gmail evaluated. - Include chain: each active `include:` or `redirect=` target needed to reach the authorization decision. - Lookup-count evidence: the DNS-querying terms and nested paths, when `permerror` or a lookup limit is suspected. - Message evidence: Message-ID, sending time, connecting IP shown in the result, and the sending service or relay expected to use that route. - Controlled retest: a newly sent message through the same application, return path, relay, and recipient path. This illustrative SPF-chain fragment is a structural example only. Do not publish it as a production record or copy it without validating every sender. ```text yourdomain.com. IN TXT "v=spf1 include:spf.sender.example -all" spf.sender.example. IN TXT "v=spf1 ip4:192.0.2.10 -all" ``` The sending provider must document the real authorization values. [Inspect the public SPF record with Palisade's SPF checker](/tools/spf) after identifying the evaluated domain. A public record lookup cannot inspect the raw Gmail message, prove the sender used that record, monitor later changes, or explain Gmail's private delivery decision. ![Checklist showing the SPF evidence packet: Gmail headers, envelope domain, public SPF record, lookup chain, connecting IP, and controlled retest](/images/editorial/why-does-gmail-report-an-spf-error/why-does-gmail-report-an-spf-error-spf-evidence-checklist.webp "1200x639") *Source: Palisade.* ### 3. Match the connecting IP to the real sending path Compare the IP named in Gmail's SPF diagnostic with the application, outbound relay, and documented IP or include mechanism for that mail stream. Check whether the service uses a custom return path or a separate bounce subdomain. If the IP belongs to an expected service, compare its documented authorization with the SPF policy on the evaluated domain. If the IP is unexpected, investigate the service configuration, routing, or account access before editing DNS. ### 4. Check DNS publication and SPF lookups Query the evaluated hostname through its authoritative DNS servers and at least one public resolver. Confirm that one usable SPF record begins with `v=spf1` and that no duplicate SPF record remains. Trace each DNS-querying term, including nested `include:` values. A record can look short while its includes consume the lookup budget. Record the actual evaluated path rather than estimating from visible mechanisms alone. ### 5. Check DMARC separately SPF and DMARC are separate checks. [DMARC requires an authenticated identifier to align with the domain in the visible From field](https://www.rfc-editor.org/rfc/rfc9989.html#section-4.4). An SPF pass for `mail.yourdomain.com` may still fail DMARC for `yourdomain.com` under strict SPF alignment. An aligned DKIM pass can allow DMARC to pass when SPF fails. For the broader protocol relationship, use the [email authentication learning hub](/learning). If Gmail reports a transport issue rather than an SPF result, see [why Gmail reports TLS errors](/learning/gmail-tls-errors). ## How do I fix it? ### Repair a missing SPF record If the evaluated hostname has no SPF record, publish one policy that authorizes only its confirmed sending paths. Obtain the provider's actual mechanism or return-path instructions from its documentation. > Do not replace a working root-domain SPF record with a subdomain policy, and do not add a second `v=spf1` TXT record. A DNS change can interrupt mail from another active sender. This repair changes SPF authentication. It does not guarantee Gmail delivery or resolve an unrelated DMARC alignment failure. ### Reduce an SPF lookup-limit `permerror` If the evidence packet shows more than 10 DNS-querying terms, remove inactive includes and obsolete mechanisms first. Consolidate only when the sending providers document a supported configuration. Retest every remaining sender, including less frequent transactional paths. Do not loosen the DMARC policy as a response. DMARC policy changes requested enforcement. They do not reduce SPF lookups or repair an SPF `permerror`. ### Authorize the confirmed sending source If Gmail's connecting IP belongs to an expected provider and that provider's documented SPF authorization is absent, add that authorization to the single SPF record for the evaluated envelope domain. Preserve existing required mechanisms. If the source is unknown, stop before authorizing it. Adding an unknown relay to SPF expands who can send mail using that envelope domain. ### Investigate an SPF pass with another failure If Gmail reports `spf=pass`, SPF has authorized the connecting IP for the evaluated identity. Check whether that identity aligns with the visible From domain for DMARC, then inspect DKIM and DMARC results. The SPF pass does not establish that Gmail will place the message in the inbox, nor does it explain a TLS, content, reputation, or recipient-policy issue. For a wider set of provider error symptoms, see [how to resolve Yahoo and Gmail email error codes](/learning/how-can-you-resolve-yahoo-and-gmail-email-error-codes). ## How do I validate the repair? Send a new message through the same application, envelope sender, outbound relay, content path, and Gmail recipient path. Check the new receiver-added `Authentication-Results` header for the expected SPF result and record the connecting IP. Validate four layers independently: - DNS: verify the evaluated hostname has one correct public SPF policy through authoritative DNS and a public resolver. - Vendor: confirm the sending service reports the expected authenticated domain or return-path state, where that service provides such a status. - Message: confirm the new Gmail-received message has the expected SPF result for the intended `smtp.mailfrom` identity. - DMARC: review aggregate reports after data accumulates to confirm that the source and alignment pattern remain understood. A green vendor indicator is not message evidence. A passing Gmail test is also not proof that every application or future DNS response will authenticate. ## Check the SPF record behind Gmail's result When the trusted header identifies the evaluated envelope domain, [check that public SPF record with Palisade]( https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=email_authentication&utm_content=why-does-gmail-report-an-spf-error ). Start with Palisade to inspect DMARC aggregate-report data, identify sending sources and authentication or alignment issues, and create prioritized remediation tickets after you have repaired the immediate SPF path. Palisade does not control Gmail's private filtering decision, change the DMARC policy without human review, or prove future messages will authenticate. ## Sources and further reading - [RFC 7208: Sender Policy Framework](https://www.rfc-editor.org/rfc/rfc7208.html) - [RFC 8601: Authentication-Results header field](https://www.rfc-editor.org/rfc/rfc8601.html) - [Google Workspace Admin Help: Set up SPF](https://knowledge.workspace.google.com/admin/security/set-up-spf) - [Google Workspace Admin Help: Troubleshoot authentication](https://support.google.com/a/answer/81126) - [RFC 9989: Domain-based Message Authentication, Reporting, and Conformance](https://www.rfc-editor.org/rfc/rfc9989.html) ## Frequently asked questions ### Does an SPF error mean the visible From domain is wrong? No. SPF usually evaluates the envelope sender domain shown as `smtp.mailfrom`, which can differ from the visible From domain. Use Gmail's `Authentication-Results` header to identify the actual evaluated identity. ### Can Gmail report an SPF error when there is no SPF record? Yes. If the evaluated domain has no usable SPF policy, Gmail cannot authorize the connecting IP through SPF. Confirm the exact result in the trusted header before publishing a new record. ### Does an SPF pass mean DMARC passes? No. SPF must also align with the visible From domain for DMARC to use that SPF pass. An aligned DKIM pass may satisfy DMARC when SPF does not align. ### Should I add the failing IP address directly to SPF? Only if the IP belongs to a confirmed, approved sending path and the provider documents that direct IP authorization is appropriate. An unknown IP may indicate an unintended relay, configuration issue, or account-access problem. ### Can a forwarded message fail SPF at Gmail? Yes. A forwarder can change the SMTP client IP Gmail evaluates. Compare the original path with Gmail's received copy, then inspect DKIM and DMARC results as well. --- # Why does DMARC say an rua or ruf domain is not authorized? Canonical: https://www.palisade.email/learning/dmarc-rua-ruf-domain-authorization > DMARC says an rua or ruf domain is not authorized when an external report destination lacks the DNS consent record required for that policy domain. DMARC says an `rua` or `ruf` domain is not authorized when a report address points outside the applicable DMARC policy domain and the destination domain has not published the required DNS consent record. This check prevents one domain from directing DMARC reports to an unrelated recipient. Check the exact policy domain, the domain after `@` in each reporting address, and the authorization record defined by [RFC 9990](https://www.rfc-editor.org/rfc/rfc9990.html). ## Quick takeaways - An external DMARC reporting address needs DNS authorization from the domain that receives the reports. - The authorization record belongs under the report destination domain, not only under the domain publishing DMARC. - `rua` and `ruf` addresses require separate checks when they use different destination domains. - An unauthorized report destination does not by itself make SPF, DKIM, or DMARC alignment fail. - The lookup name includes the exact DMARC policy domain, so a subdomain can produce a different authorization name. - A DNS result confirms publication, not that a report processor is receiving and handling production reports. ## How external DMARC report authorization works [DMARC policy records](https://www.rfc-editor.org/rfc/rfc9989.html) can request aggregate feedback through `rua` and can include failure-report destinations through `ruf`. Reporting addresses are normally within the policy domain. When an address uses another domain, the receiving domain must explicitly authorize that relationship through DNS. For aggregate reporting, [RFC 9990](https://www.rfc-editor.org/rfc/rfc9990.html) defines the external-destination check. The receiver forms a TXT lookup name from the policy domain and the destination domain. A valid authorization record tells the receiver that the destination agrees to accept reports about that policy domain. This is separate from message authentication. A report destination can be unauthorized while a message still has an aligned SPF or DKIM pass. For the broader protocol, see the [DMARC learning hub](/learning/dmarc). ![Flow showing a receiver checking an external DMARC reporting address against its required DNS authorization record](/images/editorial/dmarc-rua-ruf-domain-authorization/dmarc-rua-ruf-domain-authorization-flow.webp "1200x829") *Source: Palisade.* ## When an rua or ruf domain is not authorized Treat an address as external when its domain is neither the policy domain nor a subdomain of that policy domain. The important comparison is against the domain whose DMARC policy supplies the reporting URI. For example, if the policy record is published for `example.com` and includes `rua=mailto:reports@processor.example`, the report address is external. The receiver checks whether `processor.example` authorizes reports for `example.com`. The answer can change in these cases: - A reporting address at `reports.example.com` is within `example.com`, so it is not an external destination for this check. - A policy published specifically for `marketing.example.com` creates an authorization relationship for `marketing.example.com`, not automatically for `example.com`. - Multiple `rua` or `ruf` addresses can use different destination domains. Check each external domain separately. - A destination service may provide a customer-specific address and publish the needed authorization itself. Use the address and DNS instructions assigned by that service. Do not replace the policy-domain label with an organizational-domain guess. RFC 9990 ties the authorization lookup to the policy domain in the reporting relationship. ## Worked authorization-record example For this illustrative DMARC policy: ```text v=DMARC1; p=none; rua=mailto:dmarc-reports@processor.example ``` If `example.com` is the policy domain, the external authorization lookup is: ```text example.com._report._dmarc.processor.example IN TXT "v=DMARC1" ``` This is illustrative only. Do not publish this exact record in another domain's DNS. The report destination provider must supply or confirm the real authorization record for its own domain. The parts have distinct jobs: - `example.com` is the exact domain whose DMARC policy contains the reporting URI. - `_report._dmarc` identifies the external DMARC reporting authorization namespace. - `processor.example` is the domain after `@` in the destination address. - `v=DMARC1` identifies the authorization record format specified by RFC 9990. A common failure is publishing a record under `_dmarc.example.com`, or under the source domain's zone. Neither location gives `processor.example` consent to receive external reports. ## What to check next Start with the evidence you have. If you have only the domain name, use the [DMARC checker](/tools/dmarc) to inspect the public DMARC record and copy each `rua` or `ruf` destination exactly. Then identify the policy domain that supplied the record and query the required external authorization name. If you control the report destination domain, confirm the TXT record on its authoritative DNS servers and through at least one public resolver. If the answers differ, investigate the destination zone, delegation, and DNS propagation before changing the DMARC record. If a hosted reporting service owns the destination domain, use the reporting address it assigned and its current onboarding instructions. Do not copy an authorization hostname from another customer or assume that a wildcard record is accepted. After DNS confirms the record, check the report processor for accepted aggregate files once receivers have had time to send them. Receiving systems determine when they generate reports, so immediate arrival is not proof of a successful change. If you are also investigating a delivery rejection, keep that work separate from report authorization. For example, [SMTP error 550 5.7.509](/learning/smtp-error-codes/550-5-7-509) concerns a sender's DMARC verification, not an external report mailbox. ## Check the external DMARC report destination Inspect the published DMARC record first, then construct the authorization lookup from the exact policy domain and report destination domain. [Check the DMARC record](/tools/dmarc) A public DNS check cannot prove that every receiver will send reports, that a mailbox or processor accepted a report file, or that the production sending path passes DMARC. Palisade is agentic DMARC software that analyzes aggregate-report data, identifies sources and authentication or alignment issues, and creates prioritized remediation tickets. A human reviews the evidence and applies any DNS or policy change. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=existing_content_migration&utm_content=dmarc-rua-ruf-domain-authorization) ## Sources and further reading - [RFC 9989: Domain-based Message Authentication, Reporting, and Conformance](https://www.rfc-editor.org/rfc/rfc9989.html) - [RFC 9990: DMARC aggregate reporting](https://www.rfc-editor.org/rfc/rfc9990.html) - [Palisade DMARC checker](/tools/dmarc) ## Frequently asked questions ### Does an internal rua address need external authorization? No. An `rua` address whose domain is the policy domain or one of its subdomains is not an external destination for this DNS authorization check. The mailbox or report processor must still be able to receive and process reports. ### Who publishes the external authorization record? The domain receiving the reports publishes the record. A DMARC reporting provider commonly publishes it in its own DNS zone after assigning the customer's report address. ### Does one authorization record cover both rua and ruf? Only when the relevant reporting addresses use the same destination domain and the same policy domain. Check every distinct external destination relationship. ### Can I publish the authorization record in my own DMARC domain? No. The authorization record must be published under the destination domain because that domain is granting consent to receive the reports. ### Does an unauthorized report address make DMARC fail? No. DMARC message evaluation depends on aligned SPF or DKIM results for the visible From domain. External report authorization controls whether a receiver can send reports to the requested external destination. --- # What are the best email verification tools? Canonical: https://www.palisade.email/learning/what-are-the-best-email-verification-tools > What are the best email verification tools? Compare syntax, DNS, mailbox, and list-validation checks with their deliverability limits before you send. The best email verification tool depends on the evidence you need. Use a syntax and DNS validator to reject malformed or non-routable addresses, a mailbox-validation service when you need a current deliverability signal for a list, and your sending platform's suppression data for addresses that have already bounced. None of these tools proves inbox placement, consent, or future delivery. ## Quick takeaways - Email verification evaluates a recipient address. Email authentication evaluates the domain that sends the message. - Syntax checks can identify malformed address shapes, but RFC 5322 syntax does not prove that a mailbox exists. - DNS and MX checks can show where a domain receives mail, but they cannot confirm that a particular recipient will accept a message. - SMTP-based mailbox validation has limits because receiving servers can restrict verification commands or defer their final decision until after message acceptance. - Treat catch-all and uncertain results as review cases, not as confirmed deliverable addresses. - A clean recipient list can reduce avoidable bounces, but it does not prove sender reputation or inbox placement. ## Who this comparison is for This comparison is for marketing, operations, IT, and MSP teams choosing a way to assess email addresses before adding them to a list or sending to an older segment. The options are not interchangeable. A form validator is useful when a person enters an address. A bulk validation service fits a list that needs a triage result before a campaign. DNS tools help investigate a domain-level problem. Your ESP's own bounce and suppression records are the relevant evidence after a real send. For the sender-side controls that affect whether a receiver can authenticate your domain, use the [email deliverability learning hub](/email-deliverability). Verification can reduce bad-recipient risk, but it does not replace SPF, DKIM, or DMARC. ## How the options were evaluated The criteria below distinguish what each option can establish from what remains unknown. They were defined before drawing a recommendation. - Input fit: Does the option accept a newly typed address, a CSV list, a domain, or results from an actual send? - Evidence scope: Does it test address shape, public DNS, a receiving server's response, or a confirmed delivery outcome? - Decision timing: Can it prevent bad data at capture, help triage a list, or explain a completed send? - Uncertainty handling: Does it preserve "unknown" or catch-all outcomes rather than relabeling them as valid? - Deliverability boundary: Does the result avoid claiming recipient consent, inbox placement, or a mailbox provider's private filtering decision? RFC 5322 defines the Internet Message Format, including address syntax. [RFC 5321 defines SMTP routing and recipient commands](https://www.rfc-editor.org/rfc/rfc5321), including the role of MX records and the fact that SMTP servers can reject, accept, or defer mail-handling decisions. These standards explain why no public check can establish every fact needed for a sending decision. ![Decision flow for choosing syntax, DNS, mailbox, or bounce evidence when evaluating an email address](/images/editorial/what-are-the-best-email-verification-tools/what-are-the-best-email-verification-tools-validation-flow.webp "1200x829") *Source: Palisade.* ![Email verification evidence flow from address capture to post-send bounce records](/images/editorial/what-are-the-best-email-verification-tools/what-are-the-best-email-verification-tools-verification-evidence-flow.webp "1200x829") *Source: Palisade.* ## Form and syntax validation tools Form validation tools are the best fit when the address has just been entered and the immediate goal is to catch obvious mistakes before they reach a CRM or ESP. - Best fit: Signup, registration, checkout, and lead-capture forms. - Relevant evidence: The address has a structurally plausible local part, `@` separator, and domain shape. [RFC 5322 address syntax](https://www.rfc-editor.org/rfc/rfc5322) is the relevant technical baseline. - Tradeoff: A syntactically valid address can still point to a domain with no mail service or a mailbox that does not exist. Use form validation to correct visible errors such as a missing `@` or an incomplete domain. Keep the UI clear about what it has established: valid format is not the same as a confirmed recipient. A form checker also should not be used as a consent check. An address can be formatted correctly and still be entered by someone else, belong to a shared inbox, or be unsuitable for the message the person expects. ## DNS and MX lookup tools DNS and MX lookup tools are the best fit when you need to establish whether the recipient domain publishes mail-routing information. - Best fit: Investigating a domain in a rejected address, checking a domain before a bulk-import decision, or diagnosing a mail-routing question. - Relevant evidence: An MX record identifies a mail exchanger for a domain. SMTP specifies MX lookup as part of routing mail to a destination domain in [RFC 5321](https://www.rfc-editor.org/rfc/rfc5321). - Tradeoff: A published MX record does not establish that `person@yourdomain.com` exists or that the receiving server will accept mail for that recipient. Use an [MX record checker](/tools/mx) when the only evidence you have is the domain. Compare its public DNS result with the domain in the address. A lookup is a point-in-time view of public DNS. It does not show a recipient's mailbox state, a provider's private reputation decision, or future delivery. A structural example looks like this: ```text yourdomain.com. IN MX 10 mail.yourdomain.com. ``` > Do not copy an example MX host into production DNS. Your mail provider supplies the real hostnames and routing values for your domain. Some domains may accept mail through an implicit fallback when MX records are absent, subject to SMTP routing rules. That is another reason an MX lookup alone should not become an absolute "deliverable" verdict. ## Mailbox-validation services Mailbox-validation services are the best fit when you need to triage a list beyond format and public DNS checks, while retaining uncertain outcomes for review. - Best fit: Aged lists, imported contacts, re-engagement planning, and list hygiene before a high-volume campaign. - Relevant evidence: The service's result for the submitted address, often grouped into deliverable, undeliverable, risky, catch-all, or unknown outcomes. - Tradeoff: SMTP does not require a receiving server to disclose mailbox existence through a pre-delivery verification command. SMTP defines `VRFY` for verifying a user or mailbox, but [RFC 5321 permits servers to disable or limit VRFY](https://www.rfc-editor.org/rfc/rfc5321#section-7.3). Servers can also accept a message during the SMTP transaction and later generate a delivery failure. A mailbox-validation result is therefore evidence for prioritizing list decisions, not a guarantee that the next campaign will be delivered. Treat these outcomes differently: - Deliverable: Keep as a service result for that address and time. Do not translate it into inbox-placement proof. - Undeliverable: Suppress or investigate according to your organization's retention and consent rules. - Catch-all: Keep separate from confirmed deliverable addresses. The domain may accept any local part, so a server response may not identify a real mailbox. - Unknown or risky: Do not force these into a binary pass or fail bucket. Review recent engagement, acquisition source, and the intended send before deciding. ## ESP suppression and bounce records Your ESP's own suppression and bounce records are the best fit after you have sent a message through the exact production path. - Best fit: Deciding whether to retry, suppress, or investigate an address after a real send. - Relevant evidence: The sending platform's observed delivery event, bounce classification, and suppression status for that specific message stream. - Tradeoff: The result explains an event after sending. It does not replace pre-send validation for new or imported addresses. This option has a different trust boundary from a verifier. It records what happened when your configured sender, content, recipient, and receiving provider interacted. It is stronger evidence for that send than a public lookup, but it still does not prove why a receiver made every private filtering decision. Keep recipient verification and bounce handling separate. A verification result can inform whether to send. A bounce or suppression event should govern what happens after the send under your ESP's documented rules. ## How to choose Choose form validation when you need to stop obvious errors at capture. Choose DNS and MX checks when the problem is a recipient domain. Choose a mailbox-validation service when an older list needs triage and you can safely handle uncertain results. Choose ESP event data when a production message has already bounced. Use this scorecard for each candidate. Record only observed evidence and leave undocumented behavior open. ```yaml option: form and syntax validation checked_on: 2026-08-11 best_fit: stop malformed addresses at capture verified_evidence: - checks address structure against the implementation's rules - can prevent obvious entry errors before list storage open_question: whether the address domain routes mail and the mailbox exists option: DNS and MX lookup checked_on: 2026-08-11 best_fit: investigate recipient-domain mail routing verified_evidence: - checks publicly resolvable DNS and MX data - RFC 5321 defines MX-based SMTP routing open_question: whether a specific mailbox will accept the next message option: mailbox-validation service checked_on: 2026-08-11 best_fit: triage an imported or aged list verified_evidence: - returns a service-specific result for the submitted address - SMTP servers may limit or disable VRFY open_question: how the service classifies catch-all and deferred-delivery cases option: ESP suppression and bounce data checked_on: 2026-08-11 best_fit: act on a real production sending outcome verified_evidence: - records the ESP's observed event for the configured send path open_question: the receiving provider's unpublished filtering rationale ``` The sender-side check is separate. After choosing a recipient-validation workflow, inspect the domain that sends the campaign with Palisade's [free tools](/tools). A public check can reveal published email-authentication controls, but it cannot prove that every production sender uses them correctly. ## Check the sending domain behind your validated list Once you have removed clearly bad addresses or isolated uncertain ones, check the sending domain before the campaign. Recipient validation does not show whether the production sender authenticates mail or whether its sources align with the DMARC policy. Start with Palisade's [DMARC monitoring tools comparison](/compare/best-free-dmarc-monitoring-tools) if you are selecting an ongoing DMARC workflow. For a broader evaluation of email-protection products, see [how to compare anti-phishing software](/learning/anti-phishing-software). Palisade is agentic DMARC software for teams that need to move from public DNS checks to ongoing DMARC work. It analyzes DMARC aggregate-report data, identifies sending sources and authentication or alignment issues, and creates prioritized remediation tickets. It can propose the next policy step when the evidence supports it, while a human reviews the evidence and applies the change. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=deliverability&utm_content=what-are-the-best-email-verification-tools) A DNS or DMARC check does not verify a recipient mailbox, repair an ESP suppression state, prove every future message will authenticate, or guarantee inbox placement. ## Sources and further reading - [RFC 5322: Internet Message Format](https://www.rfc-editor.org/rfc/rfc5322) - [RFC 5321: Simple Mail Transfer Protocol](https://www.rfc-editor.org/rfc/rfc5321) - [RFC 5321 section 7.3: VRFY and EXPN security considerations](https://www.rfc-editor.org/rfc/rfc5321#section-7.3) - [RFC 9989: Domain-based Message Authentication, Reporting, and Conformance](https://www.rfc-editor.org/rfc/rfc9989.html) ## Frequently asked questions ### Do email verification tools guarantee delivery? No. They can provide evidence about address format, domain routing, a service's mailbox-validation result, or a prior sending event. Inbox placement and future delivery also depend on the sender, message, receiver policy, and conditions at the time of sending. ### Is an MX record enough to verify an email address? No. An MX record can show that a domain publishes mail-routing information. It cannot confirm that a particular local part, such as `person`, identifies a working mailbox at that domain. ### Can SMTP verify whether a mailbox exists? Only sometimes. SMTP defines verification commands, but receiving servers may restrict or disable them, and a server can accept a message before issuing a later delivery failure. Treat SMTP-based validation as a time-bound signal with uncertainty. ### Should catch-all addresses be treated as valid? Not automatically. A catch-all domain may accept mail for many or all local parts, so the server response may not confirm that the intended mailbox exists. Keep catch-all results separate from confirmed list segments. ### Does list verification replace SPF, DKIM, and DMARC? No. List verification evaluates recipients. SPF, DKIM, and DMARC help receivers assess whether the sending domain is authorized and authenticated. Both jobs can affect campaign outcomes, but they use different evidence. --- # How long does DNS propagation take for email records? Canonical: https://www.palisade.email/learning/how-long-does-dns-propagation-take-for-email-records > DNS changes take effect as cached copies expire, not on a fixed timer. What TTL controls for MX, SPF, DKIM and DMARC, and how to verify a change landed. DNS changes for SPF, DKIM, DMARC, and MX records take effect when DNS resolvers stop using their cached answer and query again. For an ordinary record edit, that is normally bounded by the TTL that was published when the resolver cached the old value. It can be minutes or hours, not a fixed global "propagation" period. A new record can also be delayed by cached negative responses. ## Quick takeaways - DNS "propagation" usually means different resolvers have different cached answers. - The old record's TTL controls how long an already cached answer may remain usable. - SPF, DKIM, DMARC, and MX records follow the same DNS caching rules. - Lowering a TTL helps a future planned change, not a record that resolvers already cached. - A missing new record may be a negative-cache result rather than a failed publication. - A public DNS lookup confirms a published answer, not that a production message used it. ## How DNS cache timing works for email records A DNS authoritative server publishes the current record. Recursive resolvers, including the resolvers used by mailbox providers, can cache that answer for its TTL. [RFC 2181 defines TTL handling for DNS resource records](https://datatracker.ietf.org/doc/html/rfc2181), including the rule that a cached record's remaining TTL decreases over time until the resolver must obtain fresh data. This applies to common email records: - SPF is published as a DNS TXT record. - DKIM commonly uses a TXT or CNAME record at a selector name. - DMARC uses a TXT record at `_dmarc.<domain>`. - MX records identify the hosts that accept inbound mail, and an [MX record check](/tools/mx) returns the published set with its preference order. If a resolver cached an old DMARC TXT record with one hour remaining, it can continue returning that old answer for up to that remaining hour. Changing the TTL at the authoritative DNS provider does not shorten the lifetime of copies already cached elsewhere. The same cache behavior can make a new record appear absent. [RFC 2308 specifies negative caching for DNS](https://datatracker.ietf.org/doc/html/rfc2308): a resolver can cache a negative response such as NXDOMAIN or no-data, using the applicable SOA-based negative TTL. That matters when you create a new DKIM selector or first publish a DMARC record. For broader context on the records involved, see the [email authentication learning hub](/learning). ## When the timing changes The useful decision rule is to compare the old TTL, the change type, and the evidence you have. - If you edited an existing TXT or MX record, expect resolvers that cached the old answer to keep it until its remaining old TTL expires. - If you published a record at a name that did not previously exist, allow for negative caching before treating a missing public answer as a DNS-host failure. - If the authoritative nameserver still returns the old value, the problem is publication or the queried name, not downstream cache expiry. - If authoritative DNS returns the new value but public resolvers disagree, the difference is consistent with independent caches expiring at different times. - If the record is visible publicly but mail still fails, inspect a real message and the sending service's status. DNS visibility alone does not show that the application signs with the intended DKIM selector or uses an aligned SPF identity. Before a planned change, reduce the TTL far enough in advance for the *current* TTL to expire. For example, changing a record from a 3600-second TTL to 300 seconds only helps after resolvers that cached the 3600-second version have refreshed. Do not keep changing the record while checking it. Each changed answer can produce a different cache state across resolvers. > Keep the old MX destination available through the planned cache-expiry window during a mail-host migration. Removing it too early can cause mail to reach a server that no longer accepts it. ## A worked DNS timing example Assume a domain changes its DMARC record at 14:00. A resolver queried the old record at 13:45, when the TTL was 3600 seconds. That resolver may continue returning the old record until about 14:45, even though authoritative DNS returned the new value immediately after the edit. ```text Illustrative only. Query the exact record name and type. # DMARC policy record dig TXT _dmarc.yourdomain.com # DKIM selector record dig TXT selector1._domainkey.yourdomain.com # MX records dig MX yourdomain.com ``` A query response includes a TTL value beside the returned record. Compare that value and content across an authoritative server and more than one public resolver. The authoritative result establishes what your DNS provider is publishing. Public resolver results show what those particular caches currently return. ![Decision flow for checking whether an email DNS change is unpublished, cached, or requires message-level validation](/images/editorial/how-long-does-dns-propagation-take-for-email-records/how-long-does-dns-propagation-take-for-email-records-dns-cache-decision.webp "1200x829") *Source: Palisade.* A long TXT value may be split into multiple quoted character-strings in DNS presentation, while still forming one TXT record value. Review the DNS record length limit for email records before treating that formatting as a propagation problem. ## Check the change with the evidence you have Start with the evidence closest to the change: - If you have DNS access, query the authoritative nameserver for the exact hostname and record type. Confirm the new value is present there before waiting on caches. - If authoritative DNS is correct, use a [DNS lookup](/tools/dns-lookup) to inspect the public result for the same hostname and record type. Repeat after the old TTL window, rather than using one lookup as proof of global state. - If the record is a DKIM, SPF, or DMARC change, send a real message through the exact production service. Inspect its `Authentication-Results` header. [RFC 8601 defines the Authentication-Results header field](https://www.rfc-editor.org/rfc/rfc8601.html), which records authentication assessment results from the evaluating system. - After DMARC reports accumulate, use them to identify sending sources and authentication or alignment failures. A delivered-message check and DMARC report data answer different questions from a DNS query. If an email domain is being prepared for a wider authentication rollout, [the business email DNS record guide](/learning/dns-records-for-business-email) covers the record set and the separate role of each record. ## Check the published email DNS record Run the domain through Palisade's DNS lookup to inspect the currently public DNS answer after you confirm the exact hostname and record type. [Check the published DNS record](/tools/dns-lookup) A public lookup does not prove which production service sent a message, whether a message passed SPF, DKIM, or DMARC, or what a receiving mailbox provider will do with future mail. For ongoing DMARC work, Palisade can analyze aggregate-report data, identify sending sources and alignment issues, and propose a next policy step for human review. It does not apply the DMARC policy change for you. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=email_authentication&utm_content=how-long-does-dns-propagation-take-for-email-records) ## Sources and further reading - [RFC 2181: Clarifications to the DNS Specification](https://datatracker.ietf.org/doc/html/rfc2181) - [RFC 2308: Negative Caching of DNS Queries](https://datatracker.ietf.org/doc/html/rfc2308) - [RFC 8601: Message Header Field for Indicating Message Authentication Status](https://www.rfc-editor.org/rfc/rfc8601.html) - [Palisade DNS lookup](/tools/dns-lookup) ## Frequently asked questions ### Does DNS propagation always take 24 to 48 hours? No. An ordinary email DNS record change is governed by cached TTLs, so the relevant wait is the remaining TTL on cached old answers. A fixed 24 to 48 hour expectation does not describe every SPF, DKIM, DMARC, or MX edit. ### Will lowering the TTL after a DNS change make it appear faster? No. Resolvers that already cached the record can use the TTL that applied when they received that answer. Lower the TTL before the next planned change, then wait through the prior TTL before making that change. ### Why does a new DKIM or DMARC record still appear missing? It may be a cached negative DNS response. RFC 2308 allows resolvers to cache negative answers, so a resolver that checked the name before publication can continue reporting no record until that negative cache expires. ### Does clearing my computer's DNS cache update Gmail or another mailbox provider? No. Clearing a local cache changes only what your own device queries next. A mailbox provider evaluates mail using its own infrastructure and DNS resolver state. ### Can a DNS lookup prove my email authentication is working? No. A DNS lookup can show the published record returned by the resolver you queried. Validate the real sending path with a delivered message's authentication results, then use DMARC aggregate reports as they accumulate. --- # How do lookalike domains bypass DMARC? Canonical: https://www.palisade.email/learning/how-do-lookalike-domains-bypass-dmarc > Lookalike domains bypass DMARC because DMARC applies only to the exact From domain, not a separately registered similar domain. Authentication can pass. Lookalike domains bypass DMARC because DMARC evaluates the domain in a message's visible From address, then applies any policy published for that domain. A separately registered name such as `examp1e.com` is outside `example.com`'s DMARC scope, even if it resembles the real brand. An attacker can authenticate mail from the lookalike domain and pass DMARC for that attacker-controlled domain. ## Quick takeaways - DMARC protects the exact visible From domain and its applicable policy domain. - A lookalike domain is a separate registration, so your DMARC record is not consulted for it. - An attacker can publish SPF, DKIM, and DMARC records for a lookalike they control. - A DMARC pass verifies aligned authentication for the visible From domain. It does not verify that the domain belongs to the brand a recipient expected. - DMARC enforcement still blocks direct spoofing of domains you own. - Lookalike defense needs controls beyond DMARC, such as monitoring, recipient reporting, and takedown processes. ## How the DMARC scope creates the gap [DMARC](https://datatracker.ietf.org/doc/html/rfc9989) evaluates the domain in the RFC 5322 From field. For a DMARC pass, SPF or DKIM must pass with an identifier aligned to that visible From domain. The receiver discovers the relevant DMARC policy for the domain used in that From field. That scope is deliberate. If a message says it is from `billing@example.com`, the receiver evaluates `example.com` and the applicable DMARC policy for that domain. If it says it is from `billing@example-support.com`, the receiver evaluates `example-support.com` instead. A policy at `_dmarc.example.com` cannot impose a policy on a separate registration. A lookalike can use a typo, an added word, a different top-level domain, or visually similar characters. The technical result is the same: the sender uses a domain that is different from the protected domain. An attacker who controls that separate domain can configure their own sending service and publish authentication records for it. If the message has aligned SPF or DKIM, it can pass DMARC for the lookalike. That pass says the message authenticated as `example-support.com`. It does not say that `example-support.com` is the real `example.com`. For the policy side of this distinction, see [what a domain's DMARC policy is](/learning/domain-s-dmarc-policy). For the wider protocol context, visit the [DMARC learning hub](/learning/dmarc). ## When DMARC can and cannot help DMARC helps when the attacker places a domain you own in the visible From address. A policy such as `p=reject` asks receiving systems to reject messages that fail DMARC for that protected domain. The receiver still makes the final delivery decision under its local policy, as [RFC 9989's DMARC policy model](https://datatracker.ietf.org/doc/html/rfc9989) describes. DMARC does not help when the sender changes the visible From domain to an attacker-owned lookalike. The following decision rule keeps the distinction clear: - If the malicious message uses `billing@example.com`, inspect DMARC enforcement and the message's authentication evidence for `example.com`. - If the message uses `billing@example-support.com`, your `example.com` policy does not govern it. Preserve the evidence for reporting and use your organization's lookalike-domain response process. - If the displayed sender name looks legitimate but the address differs, inspect the complete From address. Display names are not the domain DMARC evaluates. The `Authentication-Results` header can help identify what a receiver evaluated. [RFC 8601 defines this header field](https://www.rfc-editor.org/rfc/rfc8601.html), including authentication method results and properties such as `smtp.mailfrom`. It records an authentication service's assessment. It is not a statement that a sender is safe, legitimate, or authorized to use a brand. > Do not move a domain to a stricter DMARC policy based only on a public DNS result. Validate legitimate production mail paths before changing policy, because an unaligned sender can fail after enforcement. ## A worked lookalike-domain example Assume that `example.com` publishes a DMARC policy and an attacker registers `example-support.com`. These records are illustrative only. Do not copy them into DNS. Each domain owner publishes and controls records only for its own domain. ```text From: Billing Team <notice@example-support.com> Authentication-Results: receiver.example; dkim=pass header.d=example-support.com; dmarc=pass header.from=example-support.com ``` The example message can pass DMARC because the DKIM signing domain and visible From domain are both `example-support.com`. The receiver does not test whether that domain resembles `example.com`, because visual similarity is not a DMARC alignment rule. ![Decision flow showing that DMARC evaluates the exact visible From domain, which leaves separately registered lookalike domains outside the real domain's policy](/images/editorial/how-do-lookalike-domains-bypass-dmarc/how-do-lookalike-domains-bypass-dmarc-decision-rules.webp "1200x676") *Source: Palisade.* A similar header result for `example.com` would answer a different question: whether the message authenticated as `example.com` under that domain's DMARC policy. It would not establish why a recipient trusted a display name or whether a separate lookalike domain was malicious. ## What to do with the evidence you have If you only have a suspicious address, copy the full visible From domain and compare it with the domain your organization owns. Do not rely on the display name or a cropped screenshot. If you have the original message, preserve the raw headers and inspect the receiver's `Authentication-Results` fields. Compare `header.from` with the passing SPF or DKIM identifier. This separates direct spoofing from authenticated mail sent through a lookalike domain. If the message uses your real domain, check the published policy with the [Palisade DMARC checker](/tools/dmarc). Compare the DNS result with the real message header and with the sending systems your team has approved. A public DNS lookup confirms the current published record. It cannot prove that the suspicious message followed your production path, explain a receiver's private decision, or show every sender that may later fail alignment. If the message uses a lookalike, preserve the domain, message headers, URLs, timestamps, and any recipient reports for your security team and the relevant abuse-reporting or takedown process. DMARC aggregate reports can help identify mail using your own domain, but they do not inventory every independently registered lookalike domain. An unauthorized aggregate-report destination can also complicate DMARC reporting. See [why DMARC says an rua or ruf domain is not authorized](/learning/dmarc-rua-ruf-domain-authorization) if the reporting address itself is the problem. ## Check the DMARC policy on the real domain When a suspicious message appears to use your exact domain, inspect the real domain's published DMARC record before deciding whether a policy gap exists. Then compare it with raw message headers from the affected path. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=existing_content_migration&utm_content=how-do-lookalike-domains-bypass-dmarc) Palisade autonomously analyzes DMARC aggregate-report data, identifies sending sources and alignment issues, and proposes a next policy step for human review. It does not control an attacker-owned lookalike domain, perform a takedown, or guarantee that every future message will authenticate. ## Sources and further reading - [RFC 9989: Domain-based Message Authentication, Reporting, and Conformance](https://datatracker.ietf.org/doc/html/rfc9989) - [RFC 8601: Message Header Field for Indicating Message Authentication Status](https://www.rfc-editor.org/rfc/rfc8601.html) - [Palisade DMARC checker](/tools/dmarc) ## Frequently asked questions ### Can a lookalike domain pass DMARC? Yes. An attacker who controls a lookalike domain can publish SPF, DKIM, and DMARC records for that domain. A passing result authenticates that lookalike domain, not the brand it resembles. ### Does `p=reject` block lookalike domains? No. `p=reject` applies when messages claiming to use your protected domain fail DMARC. It does not apply to a separately registered domain, even when its name looks similar. ### Can DMARC identify every impersonation attempt? No. DMARC evaluates messages that use the domain being assessed. It does not discover every domain that resembles your brand or determine whether a separately registered sender is deceptive. ### Does a DMARC pass mean the sender is trustworthy? No. A DMARC pass means aligned SPF or DKIM authenticated the visible From domain under the receiver's evaluation. It does not establish the sender's business identity, intent, or reputation. ### Should I still enforce DMARC on domains I own? Yes. DMARC enforcement protects against direct use of your owned domains in the visible From address. Validate legitimate senders and alignment before moving to a stronger policy. --- # What is an email blocklist and how do you check one? Canonical: https://www.palisade.email/learning/blocklist-email > A blocklist flags an IP a DNS-based list has linked to spam. Learn how blocklisting works and how to check if your mail server is blocklisted. Blocklisting means a DNS-based blacklist, often called a DNSBL or RBL, has flagged a sending IP address as associated with spam or abuse. Mail systems can consult that list before accepting a message, so a listed IP risks rejection, quarantine, or spam-folder placement. Blocklisting is separate from an SPF, DKIM, or DMARC failure because those checks read different DNS records. A blacklist lookup tool can tell you whether a mail server's IP address currently appears on one of these lists. ## Quick takeaways - A blocklist, also called a DNSBL or RBL, is a list an outside operator maintains that flags IP addresses associated with spam or abuse. Mail systems can check it before accepting a message. - Lookup tools such as [MXToolbox](https://mxtoolbox.com) check a domain's mail server IP addresses against a set of DNS-based blacklists, 105 lists in MXToolbox's own published count, in one pass. - Blocklisting is a reputation check on an IP address. It is not the same as an SPF, DKIM, or DMARC failure, which involve separate DNS records that [DNSChecker](https://dnschecker.org) describes as commonly holding authentication configuration. - Some lookup tools bundle a blacklist check with a reverse-DNS verification and a basic open-relay test in the same diagnostic pass. - Each blocklist operator sets its own listing criteria and delisting process. A lookup tool reports whether an IP is listed, not why, and not how to get it removed. - Blocking a sender inside your own inbox in Gmail or Outlook is a mail-client feature. It is a different action from your domain or IP being blocklisted by an outside operator. ## How a blocklist check works A DNS-based blacklist is maintained by an operator outside your organization, not by your mail server or your domain's DNS zone. MXToolbox's own description of its MX Lookup tool states that it checks each mail server IP address resolved from a domain's MX record against a set of these lists, which it refers to as "commonly called RBLs, DNSBLs." As of this writing, MXToolbox states it checks each IP against 105 such lists in one pass. That figure is a vendor-reported count and can change over time. A blocklist check answers one narrow question: does at least one operator currently associate this IP address with spam or abuse. It does not test your domain's authentication setup. DNSChecker describes the TXT DNS record type as commonly used for SPF, DKIM, or DMARC configuration, which are separate mechanisms that validate whether a message is authorized to use your domain, not whether the sending IP has a poor reputation. A domain can pass DMARC and still send from an IP that a blocklist has flagged, and a domain can fail DMARC from an IP with a clean reputation. For the wider set of factors that affect inbox placement, see [what affects email deliverability](/email-deliverability). ![Steps a DNSBL lookup tool follows when checking a mail server's blacklist status](/images/editorial/blocklist-email/blocklist-email-lookup-steps.webp "1200x813") *Source: Palisade.* MXToolbox's Diagnostics feature, reached from the MX Lookup results, extends the check beyond the blacklist lookup itself. It connects to the mail server, verifies its reverse DNS record, runs a basic open-relay check, and measures response-time performance. Reverse DNS and open-relay status both feed into a mail server's reputation, even though the blacklist databases evaluate them separately from the lookup. ## When this does not apply Whether an IP or domain is currently blocklisted depends on which list you check, when you check it, and which mail server actually sent the message. A domain can send from several IP addresses. A marketing platform, a transactional email service, and an internal mail server can all send mail using the same domain. This article's lookup flow is IP-specific: check every outbound sending IP tied to the affected path instead of treating one result as evidence for every source. A listing on one of those IPs does not by itself establish the status of the others. A listing status also changes between checks. A DNS-based blacklist result reflects the operator's records at the moment the query runs. DNSChecker notes that complete DNS resolution across its checked server network can take up to 48 hours, a propagation window that applies to DNS record changes in general, not to how quickly a blocklist operator adds or removes a listing. Treat any single lookup as a point-in-time result. Blocklisting is also not the only reason a message gets stopped. A message can get blocked because the sending domain is not authenticated at all, which [Gmail treats differently from a reputation-based blacklist listing](/email-deliverability/gmail-blocked-sender-is-unauthenticated). A message can also land in the spam folder without being blocked outright, which has a separate set of causes in Outlook. Confirm which of these you are looking at before you chase a blocklist that may not be the actual cause. The phrase "blocklist email" also covers a second, unrelated question: how to block unwanted senders inside your own inbox. That is a mail-client feature in Gmail, Outlook, and similar apps, controlled from your own account settings, not a DNS-based list an outside operator maintains. The rest of this article covers the DNSBL sense; the FAQ below addresses the inbox-blocking sense separately. ## A worked example A blacklist lookup tool typically reports a result shaped like this for a checked domain: ```text Domain checked: yourdomain.com (illustrative only) Mail server IPs found: 203.0.113.10, 203.0.113.11 Blacklists checked: 105 (vendor-published count, checked 2026-08-11) Currently listed on: 0 of 105 Reverse DNS: resolves correctly Open relay: not detected ``` Reading that result: "Blacklists checked" reflects the tool's own list count at the time of the query. "Currently listed on" shows how many of those lists flagged the IP right now. The reverse-DNS and open-relay lines come from the same diagnostic pass in tools that bundle them, such as MXToolbox's Diagnostics feature. A result of zero listings reports the state of that query at that moment. It does not certify the IP will stay clean afterward. ## What to check next Start with the specific evidence you already have. If a bounce message or a rejection reason names a blacklist or a reputation problem, look up the exact IP address the bounce identifies, not just the domain's primary sending IP. If you have no bounce message and want a general reputation check before something breaks, look up the mail server IP directly rather than waiting for a complaint. ## Check your sending IP's reputation, then find what else is sending A single reputation lookup answers one question about one IP address at one moment. Run the mail server IP tied to the bounce or complaint through Palisade's checker to see whether it currently appears on reputation databases. [Check IP reputation](/tools/ip-reputation) To ask the narrower question, whether a specific domain or IP is currently listed on the major blocklists, use [Palisade's blocklist checker](/tools/blocklist-checker) instead. That check does not tell you whether another server, sending on your domain's behalf without your knowledge, is the one causing the problem. Palisade's agent investigates sources observed in aggregate DMARC reports, drafts fixes, and proposes each policy step. You approve before anything ships. When a DNS change is approved, [Smart DNS Deployment](/features/dns-deployment) can write the record into your own zone at your own provider. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=email_deliverability&utm_content=blocklist-email) Palisade's one-time blocklist and reputation checks can inspect current public evidence, but Palisade cannot change a blocklist operator's listing or delisting decision. Its DMARC workflow helps identify the sending source that needs investigation. It does not control a receiver's private reputation system or guarantee delivery. ## Sources and further reading - [MXToolbox: MX Lookup and Diagnostics](https://mxtoolbox.com) - [DNSChecker: DNS record lookup tool](https://dnschecker.org) ## Frequently asked questions ### How do I find my blocked email list? Only a current blacklist lookup can show whether a public list flags your mail server IP addresses. MXToolbox's MX Lookup resolves a domain's MX record, then checks each resulting IP address against its set of DNS-based blacklists in one pass, so you see which lists, if any, currently flag that IP. ### How can I see if my email is blacklisted? Only a current DNSBL or blacklist check can answer this reliably. A tool such as MXToolbox's MX Lookup and Diagnostics resolves your domain's mail server IP addresses, checks each one against its blacklist set, and in the same pass verifies reverse DNS and checks for an open relay, two other signals tied to mail server reputation. ### How do I block a list of emails? Not through a DNSBL: this is a different action from your domain being blocklisted. Blocking or muting multiple senders happens inside your own mail client, such as Gmail or Outlook, using that provider's own sender-blocking or filter settings. The exact menu path depends on the client and changes over time, so check that provider's current help documentation for the steps. ### How do I permanently block an email sender? Only an inbox-side block-sender or filter setting can block that sender for your account; DNSBL blocklisting is a different system. Since interfaces change, confirm the current steps in your mail client's own help center rather than relying on a fixed set of clicks. ### Is being blocklisted the same as blocking a sender in my inbox? No. Being blocklisted means an outside DNSBL operator has flagged your sending IP address as associated with spam or abuse, and mail systems can act on that listing before accepting your mail. Blocking a sender in your inbox is a setting you control in your own mail client that filters messages from a specific address for you alone. The two features do not affect each other. --- # Can an email have multiple DKIM signatures? Canonical: https://www.palisade.email/learning/multiple-dkim-signatures > Can an email have multiple DKIM signatures? Yes. Learn how receivers verify each signature and which passing signature can satisfy DMARC in practice. Yes. An email can contain multiple `DKIM-Signature` header fields, signed by the same organization or by different organizations that handled the message. [RFC 6376](https://www.rfc-editor.org/rfc/rfc6376.html), the DKIM Standards Track specification, says verifiers SHOULD evaluate each signature independently. For DMARC, a passing DKIM signature matters only when its signing domain aligns with the visible `From` domain, unless aligned SPF supplies the DMARC pass. ## Quick takeaways - Multiple DKIM signatures on one email are valid protocol behavior. - Each DKIM signature has its own `d=` signing domain, `s=` selector, covered headers, and verification result. - A failed DKIM signature does not invalidate another signature that passes. - A passing provider-owned DKIM signature may not satisfy DMARC alignment for your visible `From` domain. - RFC 9989, the current DMARC specification, evaluates a passing DKIM authenticated identifier for alignment with the RFC 5322 `From` domain. - A delivered message header is the evidence that a production system actually signed a message. ## Who is affected? This applies to any domain that sends mail through more than one service, uses an outbound gateway, participates in mailing lists, or is changing DKIM keys or signing infrastructure. It also applies when an operator opens a message source and sees several `DKIM-Signature` fields or several `dkim=` results in an `Authentication-Results` field. Multiple DKIM signatures are different from multiple DKIM DNS records. A DNS record publishes one public key for a selector. A `DKIM-Signature` field in a delivered message shows that a system used a particular selector and signing domain for that message. The [email authentication hub](/learning) explains where DKIM fits with SPF and DMARC. RFC 6376 permits signatures from the same organization or different organizations involved in handling the message. Common protocol-valid cases include an author domain adding a signature, then a mailing list or intermediary adding another signature. A second signature can also appear while a sender moves traffic to a new signing system. The standard does not require every message to have more than one signature. It describes how verifiers handle them when they are present. ## What are the requirements? ### Each DKIM signature is evaluated on its own merits RFC 6376 states that a message can contain signatures from the same or different organizations and that verifiers SHOULD evaluate signatures independently. Each signature refers to its own signing domain through `d=`, DNS selector through `s=`, signing algorithm, body hash, and header list. ```text DKIM-Signature: v=1; a=rsa-sha256; d=yourdomain.com; s=selector1; h=from:to:subject:date; bh=example-body-hash; b=example-signature DKIM-Signature: v=1; a=rsa-sha256; d=mail.example.net; s=provider1; h=from:to:subject:date; bh=example-body-hash; b=example-signature ``` The values above are illustrative only. Do not publish another organization's selector, DNS target, token, or signature value as your configuration. A verifier retrieves the public key associated with each `s=` and `d=` pair, then evaluates that signature's signed headers and body hash. One signature can fail because a later system changed a signed part of the message while another signature still passes. ![Two DKIM signatures independently mapped to their own signing domain, selector, and verification result](/images/editorial/multiple-dkim-signatures/multiple-dkim-signatures-signature-check.webp "1200x676") *Source: Palisade.* ### A passing DKIM signature must align to satisfy the DKIM side of DMARC [RFC 9989](https://www.rfc-editor.org/rfc/rfc9989.html) is the current DMARC Proposed Standard and obsoletes RFC 7489. For DKIM evaluation, DMARC compares a passing DKIM authenticated identifier with the RFC 5322 `From` Author Domain using the domain-alignment rules in the DMARC policy. This means a message can have several DKIM results with different DMARC value. For example: - A signature with `d=yourdomain.com` can satisfy the DKIM side of DMARC when it passes and aligns with `From: alerts@yourdomain.com`. - A signature with `d=mail.example.net` can pass DKIM but may not align with `yourdomain.com`. - A failed aligned signature does not become valid because an unrelated signature passes. DMARC needs either aligned DKIM or aligned SPF to authenticate the message. It does not combine an unaligned DKIM pass with an unaligned SPF pass into a DMARC pass. ### The signature should survive the message path that matters DKIM verification checks the message as received, not the message as it looked when the first sender submitted it. A later system that changes a signed header, message body, footer, or link can cause one signature to fail. An extra signature is therefore not automatically a fault. The operational question is whether the intended signature remains valid at the recipient and, when DKIM supports DMARC, whether that signature aligns with the visible `From` domain. For a wider security consideration, see DKIM replay attacks: what they are and what controls help. A valid DKIM signature proves that the signed content validated against the published key. It does not, by itself, establish that a later use of a message is authorized. ## When does the requirement take effect? There is no new mailbox-provider deadline for multiple DKIM signatures. The behavior is defined by RFC 6376 and applies whenever a message contains more than one `DKIM-Signature` field. RFC 6376 was published as a Standards Track RFC in September 2011. Its rule that verifiers SHOULD evaluate multiple signatures independently is protocol behavior, not a temporary migration rule. RFC 9989 was published in May 2026 as a Proposed Standard and superseded RFC 7489 for DMARC. It defines the current DMARC interpretation of aligned DKIM identifiers. A provider can make local filtering decisions beyond the protocol minimum. A DKIM pass in a header does not disclose every factor a receiver uses to accept, filter, or place a message. ## How do I implement the requirement? ### 1. Identify the signature that should align with the visible From domain Choose the system that can sign the final production message using the domain shown in the recipient-facing `From` header. This can be the sending platform or a final outbound gateway, depending on where intentional message changes occur. Record the expected `d=` domain and selector for each production sending path. Do not assume that a platform's generic DKIM status means the delivered message carries an aligned signature. ### 2. Give independent signing systems separate selectors Publish a distinct selector and key for each service or signing role. Separate selectors make it possible to identify which system signed a delivered message and to rotate or retire a key without affecting unrelated senders. The public-key record has this general shape: ```text selector1._domainkey.yourdomain.com TXT "v=DKIM1; k=rsa; p=example-public-key" ``` This is illustrative only. Generate the actual selector and key in the sending service that owns the private key. Do not reuse another tenant's record value. ### 3. Place the required signature after planned message modifications If an outbound gateway adds a footer, rewrites links, or changes covered headers, the aligned signature that must survive delivery should be applied after those deliberate changes. A message can retain earlier signatures, but an earlier signature may fail if its signed content changes later. > Do not remove an existing DKIM signature solely because another one appears. First verify the delivered production message and confirm which signature supplies aligned DMARC authentication. ### 4. Retire transition signatures after production evidence is available During a signing migration, keep the old public key available while mail signed with it can still be delivered or verified. Stop adding the old signature only after the new signature appears on the actual sending path and passes verification. A DNS record can be correctly published while the application still signs with an old selector. Treat DNS publication and delivered-message behavior as separate checks. ## How do I validate compliance? Start with a message delivered through the exact production path. Open its raw source and list every `DKIM-Signature` field. For each signature, record the `d=` domain and `s=` selector, then compare it with the corresponding `dkim=` result in the message's `Authentication-Results` field. Check four layers separately: - DNS: confirm the expected selector record resolves through the authoritative DNS service and a public resolver. - Vendor: inspect the sending service's current DKIM or domain-authentication status. - Message: verify that the delivered message contains the intended signature and that it passes. - DMARC: once aggregate reports accumulate, confirm that the aligned domain is appearing as expected in DMARC reporting. Use the [DKIM checker](/tools/dkim) to inspect a public selector record when you know the domain and selector. A public DNS check does not prove that a production application signed a particular message, that the signature survived every intermediary, or that a receiver accepted the message. For message-level testing, follow the process in [How do you test and verify DKIM on a real email?](/tools/dkim). Compare the delivered message's `d=` value with the visible `From` domain and evaluate whether the domains align under the DMARC policy. ## Check the DKIM selector behind the delivered signature After you have identified the `d=` domain and `s=` selector in a delivered message, inspect that selector's public DNS record before changing a signing configuration. [Check the DKIM selector](/tools/dkim) A selector check can show the published public key. It cannot prove that the production sender used the key, repair a broken signature, monitor later message changes, or guarantee a receiver's placement decision. If several systems sign your domains, the ongoing gap is broader than one selector lookup. Palisade is DMARC software that analyzes DMARC aggregate-report data, identifies sending sources and authentication or alignment issues, and creates prioritized remediation tickets. It can propose the next DMARC policy step after a human reviews the evidence and applies the change. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=email_authentication&utm_content=multiple-dkim-signatures) Palisade does not autonomously change your DMARC policy, prove every future message will authenticate, or control a receiver's private delivery decision. ## Sources and further reading - [RFC 6376: DomainKeys Identified Mail (DKIM) Signatures](https://www.rfc-editor.org/rfc/rfc6376.html) - [RFC 9989: Domain-based Message Authentication, Reporting, and Conformance (DMARC)](https://www.rfc-editor.org/rfc/rfc9989.html) - [Palisade DKIM testing guide](/tools/dkim) - [Palisade DKIM checker](/tools/dkim) ## Frequently asked questions ### Can an email have two DKIM signatures? Yes. RFC 6376 permits multiple `DKIM-Signature` fields on one message. They can come from the same organization or from different organizations that handled the email. ### What happens when one DKIM signature passes and another fails? Each signature is evaluated independently. A failed signature does not invalidate a separate signature that passes, although a receiver can apply its own local filtering policies to the complete message. ### Which DKIM signature does DMARC use? DMARC can use any passing DKIM signature whose signing domain aligns with the visible RFC 5322 `From` domain. A passing signature from an unrelated provider domain does not satisfy DKIM alignment for your domain. ### Can two email services use the same DKIM selector? Yes, they can technically publish and use the same selector, but separate selectors are safer operationally. Separate selectors make ownership, investigation, rotation, and retirement easier to manage. ### Does a passing DKIM signature guarantee inbox placement? No. A passing DKIM signature validates the signed message content against the published key. It does not guarantee inbox placement, future authentication, or a receiver's private filtering decision. --- # How do you manage multiple DKIM records for one domain? Canonical: https://www.palisade.email/learning/how-can-you-effectively-manage-multiple-dkim-records > How to manage multiple DKIM records: use unique selectors, publish each key safely, rotate without breaking mail, and validate delivered messages. You can publish multiple DKIM records for one domain by giving each sending system its own DKIM selector. DKIM looks up the public key at `<selector>._domainkey.<signing-domain>`, so separate selectors keep Google Workspace, Microsoft 365, marketing platforms, and transactional senders from overwriting one another. The operative requirement is to publish the public key that matches the selector used in each sender's delivered messages. ## Quick takeaways - A DKIM selector identifies which public key a receiver retrieves for a signed message. - One domain can publish multiple DKIM public keys because each selector has a separate DNS name. - Each sending platform should use the selector and signing domain that its configuration generates. - Publish a replacement selector before changing a sender to use it. - A public DNS lookup confirms a record is visible, but it does not prove that a production sender is signing with that record. - DMARC needs a passing, aligned DKIM signature or a passing, aligned SPF result. ## Who is affected? Multiple DKIM records affect any organization that sends mail through more than one system while using the same organizational domain. Common examples include employee mail, marketing mail, customer notifications, support platforms, and billing systems. The controlling protocol is [RFC 6376, DomainKeys Identified Mail Signatures](https://www.rfc-editor.org/rfc/rfc6376.html), a Standards Track RFC that obsoletes RFC 4871. RFC 6376 defines the selector as part of the DKIM signature's `s=` tag. The receiver combines that selector with the signing domain in the `d=` tag to find the public key in DNS. A domain does not need a DKIM record for a system that never sends mail. A system that sends with a different signing domain also does not use a selector under your primary domain. Check the delivered message before adding DNS records, because the message's `d=` and `s=` values identify the lookup name that matters. For a broader explanation of signing domains, selectors, and verification, see the [email authentication learning hub](/learning). Multiple records are normal. Multiple records at the same selector name are not a safe way to publish unrelated keys. ## What are the requirements? ### Each DKIM key is identified by a selector RFC 6376 requires a signer to include the signing domain with `d=` and the selector with `s=` in its DKIM-Signature header. A verifier queries the DNS name formed from those values. ```text DKIM-Signature: v=1; d=yourdomain.com; s=marketing2026; ... DNS lookup name: marketing2026._domainkey.yourdomain.com ``` The selector is not a display name. It is a DNS label that points a receiver to the correct public key. If the marketing platform signs with `s=marketing2026`, publishing a key only at `default._domainkey.yourdomain.com` does not help that message. Use a distinct selector for each independently managed sending service. That makes ownership clear and allows one service to rotate keys without changing the DNS record used by another. The selector itself can be provider-generated, so do not substitute a convenient label unless the sending platform supports that change. ![DKIM selector map showing separate DNS lookup names for employee mail, marketing mail, and transactional mail](/images/editorial/how-can-you-effectively-manage-multiple-dkim-records/how-can-you-effectively-manage-multiple-dkim-records-selector-map.webp "1200x533") *Source: Palisade.* ### The public key record must match the sender's configuration RFC 6376 defines the DKIM key record as a DNS TXT record at the selector name. The record contains DKIM tags, including `v=DKIM1` and the public-key value in `p=`. ```text Illustrative only. Do not publish this example as a production key. marketing2026._domainkey.yourdomain.com. IN TXT "v=DKIM1; k=rsa; p=PUBLIC_KEY_MATERIAL" ``` The sender's platform generates the real selector and public-key material. Copy the provider's exact hostname and value into the authoritative DNS zone. Do not combine two providers' keys into one made-up record, and do not copy a key from another tenant. Some providers instruct customers to publish CNAME records rather than a raw TXT record. Follow that provider's documented hostname and target exactly. The purpose is still the same: the selector used by the message must resolve to the public key the receiver verifies. ### DKIM key sizes have current protocol limits [RFC 8301](https://datatracker.ietf.org/doc/html/rfc8301) updates DKIM's cryptographic requirements. It says signers MUST use RSA keys of at least 1024 bits and SHOULD use keys of at least 2048 bits. Verifiers MUST be able to validate RSA keys from 1024 through 4096 bits and MUST treat keys under 1024 bits as invalid. Use the key type and length your sender supports, then confirm that the public key in DNS is complete. Long RSA keys can be split into quoted DNS character strings by a DNS provider. That can be valid DNS presentation when the resulting TXT value is preserved. A missing character in `p=` is not valid and will prevent verification. ### DMARC evaluates domain alignment separately A valid DKIM signature does not by itself satisfy the DMARC policy. [RFC 9989](https://www.rfc-editor.org/rfc/rfc9989.html) says DKIM passes DMARC only when the signature is valid and the signing domain aligns with the domain in the visible `From:` header. This is why selector inventory should record both the selector and the DKIM `d=` domain. A message may have a public key that resolves and a DKIM signature that passes, yet fail DMARC when the signing domain is not aligned. ## When does the requirement take effect? There is no single mailbox-provider date on which a domain becomes required to publish multiple DKIM records. RFC 6376 was published in September 2011 as the current Standards Track specification for DKIM signatures and key retrieval. RFC 8301, published in January 2018, updates its cryptographic requirements. The requirement takes effect for each sending path when that path starts signing with a selector. Before that sender delivers mail, its generated DNS record must be published and available through the authoritative DNS service. Mailbox-provider sender rules can add separate requirements, but those rules do not change the basic selector lookup defined by RFC 6376. ## How do I implement the requirement? ### 1. List every production sending path Identify every system that sends mail using your domain in the visible `From:` header. Include employee mail, campaigns, receipts, support notifications, and any platform that sends on your behalf. For each system, obtain its documented DKIM setup values from that provider, such as [Google Workspace's DKIM instructions](https://support.google.com/a/answer/174124) or [Microsoft's DKIM configuration guide](https://learn.microsoft.com/en-us/defender-office-365/email-authentication-dkim-configure). Record the sender name, the DKIM `d=` domain, selector, DNS record type, record value or CNAME target, owner, and change date. ![DKIM selector management checklist covering sender paths, DNS records, message headers, and rotation status](/images/editorial/how-can-you-effectively-manage-multiple-dkim-records/how-can-you-effectively-manage-multiple-dkim-records-selector-management-checklist.webp "1200x582") *Source: Palisade.* ### 2. Publish the provider-generated record Create the TXT or CNAME record at the exact hostname the sender provides. Publish it in the authoritative DNS zone for the signing domain. > Do not remove an old selector during this step. Messages already sent with that selector can remain in transit, and an active sender may still be configured to use it. Query the published hostname after DNS propagation. A [DKIM lookup](/tools/dkim) is useful when you know the selector and signing domain. It checks the public DNS evidence before you switch or troubleshoot a sender. ### 3. Enable or confirm DKIM signing in the sending platform Use the provider's current configuration process to enable signing or confirm its verification state. A provider dashboard can confirm that it recognizes the DNS record, but that status does not prove a message was signed on the production route. Send a controlled message through the exact sending path. Inspect the delivered raw headers for a `DKIM-Signature` with the expected `d=` and `s=` values, then inspect the receiver's authentication result. ### 4. Rotate one selector at a time Create and publish the replacement selector first. Change only the sender being rotated after its replacement record is visible. Then send and inspect a real message signed with the replacement selector. Keep the older selector published until evidence shows that the sender has stopped using it and normal delivery has cleared. This sequence avoids a lookup failure caused by deleting a key that active messages still reference. ### 5. Keep the selector inventory current Update the inventory after every sender onboarding, DNS change, ownership change, or key rotation. Include the actual delivered-message evidence used to validate the change. This record helps distinguish a DNS issue from a sender configuration issue. It also prevents two teams from attempting to use the same selector for unrelated services. ## How do I validate compliance? Validate multiple DKIM records at four layers. First, query the selector record from the authoritative DNS service and at least one public resolver. Confirm that the TXT or CNAME record is present at the exact hostname derived from the sender's `d=` and `s=` values. Second, check the sending provider's current verification or authentication status. This confirms whether the provider recognizes the intended DNS configuration. Third, send a real message from each production path and inspect its raw headers. Confirm the message contains the expected selector and signing domain. Confirm the receiver reports a passing DKIM result. [RFC 8601's Authentication-Results header field](https://www.rfc-editor.org/rfc/rfc8601.html) records the authentication assessment made by the receiving system, so it is message evidence, not a general statement about every receiver. Fourth, review DMARC aggregate reports after they accumulate. They show which sending sources authenticate and whether the DKIM domain aligned with the visible `From:` domain. If you also need to rule out a policy-record problem, compare the result with the separate guidance on [whether a domain can have multiple DMARC records](/learning/multiple-dmarc-records). A DNS lookup does not prove the sender holds the matching private key, that every production path uses the selector, or that a receiver will make a particular delivery decision. A passing delivered-message result is stronger evidence for that one path and message, but it does not guarantee future mail will authenticate. ## Inspect the DKIM records before you manage them at scale Start by looking up each selector and signing domain that appears in your sender inventory. This establishes which public keys are visible before you make a provider-side or DNS change. [Check a DKIM selector](/tools/dkim) A public DKIM lookup cannot identify every system that sends for your domain, prove the production private key matches, or monitor later sender changes. For the ongoing operational gap, Palisade is agentic DMARC software that analyzes DMARC aggregate-report data, identifies sending sources and authentication or alignment issues, and creates prioritized remediation tickets. It proposes the next policy step for human review. It does not change your DMARC policy or guarantee delivery. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=email_authentication&utm_content=how-can-you-effectively-manage-multiple-dkim-records) ## Sources and further reading - [RFC 6376: DomainKeys Identified Mail Signatures](https://www.rfc-editor.org/rfc/rfc6376.html) - [RFC 8301: Cryptographic Algorithm and Key Usage Update to DKIM](https://datatracker.ietf.org/doc/html/rfc8301) - [RFC 9989: Domain-based Message Authentication, Reporting, and Conformance](https://www.rfc-editor.org/rfc/rfc9989.html) - [RFC 8601: Message Header Field for Indicating Message Authentication Status](https://www.rfc-editor.org/rfc/rfc8601.html) - [Google Workspace: Turn on DKIM for your domain](https://support.google.com/a/answer/174124) - the selector and key Google Workspace generates - [Microsoft: Use DKIM to validate outbound email](https://learn.microsoft.com/en-us/defender-office-365/email-authentication-dkim-configure) - the CNAME selectors Microsoft 365 publishes - [How to add a DKIM record in GoDaddy DNS](/learning/add-dkim-record-godaddy) ## Frequently asked questions ### Can a domain have multiple DKIM records? Yes. A domain can have multiple DKIM records when each key uses a different selector. Each selector creates a separate DNS lookup name under `_domainkey`. ### Can two sending services use the same DKIM selector? Only if both services are intentionally configured to use the same key material and signing setup. In normal operations, give independently managed services different selectors so their records and rotations remain separate. ### Does a DKIM lookup prove that mail is signing correctly? No. A DKIM lookup proves that the public DNS record is visible for the selector and domain supplied. Inspect a real delivered message to confirm that the sender used that selector and that a receiver verified the signature. ### Should I delete an old DKIM selector after rotating a key? Not immediately. Publish and validate the replacement selector first, switch the sender, then keep the old record until the sender no longer uses it and in-flight messages have cleared. ### Can DKIM pass while DMARC fails? Yes. DKIM can pass cryptographically while DMARC fails if the DKIM signing domain does not align with the domain in the visible `From:` header. RFC 9989 requires both DKIM validation and alignment for DKIM to satisfy DMARC. --- # How often should you rotate DKIM keys? Canonical: https://www.palisade.email/learning/dkim-key-rotation > How often should you rotate DKIM keys? DKIM sets no universal interval. Use a documented risk-based schedule and rotate immediately after exposure. DKIM does not require one universal key-rotation interval. Set a documented schedule that fits your risk, key custody, provider capabilities, and change process, then rotate immediately if a private key may be exposed. Use a new selector for each replacement, publish its public key before switching production signing, retain the old public key during the transition, and remove it only after the old signatures no longer need verification. ## Quick takeaways - [RFC 6376](https://www.rfc-editor.org/rfc/rfc6376.html#section-3.1) does not prescribe a fixed number of days or months for DKIM key rotation. - A new DKIM key should use a new selector rather than replacing key material behind an existing selector. - Old and new public keys can coexist in DNS while mail systems move to the new signing key. - [RFC 8301](https://www.rfc-editor.org/rfc/rfc8301.html) requires DKIM RSA keys to be at least 1024 bits and recommends at least 2048 bits. - Suspected private-key exposure calls for an incident response, not waiting for the normal rotation date. - A DNS lookup confirms publication, but a delivered message confirms that the intended production path is signing successfully. ## How DKIM key rotation works A DKIM signature includes a selector in its `s=` tag. A receiving system combines that selector with the signing domain in the `d=` tag to find the public key in DNS. For example, a signature with `d=yourdomain.com` and `s=selector2` directs the receiver to `selector2._domainkey.yourdomain.com`. [RFC 6376 explains the selector transition model](https://www.rfc-editor.org/rfc/rfc6376.html#section-3.1): publish the replacement public key under a new selector, switch the signer to that selector, then remove the old public key after messages signed with it have had a reasonable opportunity to be verified. The RFC advises against reusing a selector with new key material. After replacement, a verifier could otherwise have difficulty distinguishing a valid old signature from a forged one using the replaced key. DKIM key strength and rotation timing are separate decisions. [RFC 8301's DKIM key requirements](https://www.rfc-editor.org/rfc/rfc8301.html) set a minimum RSA key length of 1024 bits and recommend 2048 bits or more. They do not establish a key lifetime. Your organization must set that lifetime through its own security policy and operational limits. For the protocol context behind selectors and signatures, see the [Palisade learning center](/learning). ## When the rotation answer changes A routine schedule is appropriate when you know which system controls the private key, who can change DNS, and which applications use the signing domain. The schedule should be short enough to limit the lifetime of a key and long enough that your team can perform a complete, verified transition without breaking mail. The answer changes immediately when the private key may be compromised. Treat suspected exposure, unauthorized access to the signing system, or an unapproved transfer of key material as a reason to stop using the affected key and begin a controlled replacement. The protocol does not define an incident timetable, but waiting for a scheduled date leaves the potentially exposed key usable for longer. Provider-managed DKIM can change the work you perform. Some providers ask you to publish account-generated TXT or CNAME records and control the private key themselves. Others require you to generate, activate, or rotate keys in their interface. Follow the provider's current documentation for that platform, and do not replace a provider-managed record with a value copied from another account. Use this decision rule: - If the current key is trusted and ownership is known, rotate on your documented schedule with a new selector. - If the private key may be exposed, rotate immediately under an incident process. - If the sending provider manages the key, confirm its documented rotation model before changing DNS. - If you cannot identify the sender or selector owner, inventory the path before removing any key. > Do not delete an old selector as soon as the new record appears in DNS. Messages already signed with the old selector can still need the old public key for verification. ## A worked DKIM selector transition This illustrative DNS shape shows two public keys during a planned transition. The actual selector names and public-key values must come from your signing platform or controlled key-generation process. Do not publish example values as production records. ```text selector1._domainkey.yourdomain.com TXT "v=DKIM1; k=rsa; p=<current-public-key>" selector2._domainkey.yourdomain.com TXT "v=DKIM1; k=rsa; p=<replacement-public-key>" ``` The first record remains available while existing production traffic may still carry `s=selector1`. After the outbound signer uses `s=selector2`, inspect real delivered messages from each sending path. When the old selector no longer appears in the agreed observation window and your rollback window has ended, remove or revoke the old public key according to the platform's procedure. ![Checklist showing a DKIM key rotation from selector inventory through DNS publication, production message verification, and old-selector retirement](/images/editorial/dkim-key-rotation/dkim-key-rotation-checklist.webp "1200x639") *Source: Palisade.* This sequence separates four kinds of evidence: - DNS: Query the exact new selector through authoritative DNS and at least one public resolver. - Vendor: Confirm the sending platform reports the new DKIM configuration as active, if it provides that status. - Message: Send a real message through each production path and inspect its `Authentication-Results` header. [RFC 8601 defines the Authentication-Results field](https://www.rfc-editor.org/rfc/rfc8601.html). - DMARC: Review aggregate-report data after it accumulates to see whether the expected sending paths authenticate and align. A green provider status or a public DNS result is useful, but neither proves that the application used the new selector on a delivered message. ## Check the evidence you have If you have a selector and domain, use the [DKIM checker](/tools/dkim) to inspect the public DKIM record. Compare the returned record with the selector your platform says it is using. This check can reveal a missing or malformed public record, but it cannot show whether a particular application is currently signing with that key. If you have access to the sending platform, verify its current DKIM status and send a test message through the exact production route. Inspect the delivered message headers for the signing domain and selector. A passing DKIM result does not by itself prove DMARC alignment, because DMARC compares the DKIM signing domain with the visible From domain. If you manage a provider-specific configuration, retain the provider's generated values and change history. For example, the [Salesforce DKIM key setup guide](/learning/dkim-keys-salesforce) covers the provider-specific DNS pattern used for Salesforce-managed keys. For teams responsible for several domains or sending platforms, the ongoing gap is source inventory. A public check can show the record published today, but it cannot identify every production sender that still uses an old selector or show later authentication failures. Palisade analyzes DMARC aggregate-report data to identify sending sources and authentication or alignment issues, then proposes prioritized remediation work for human review. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=email_authentication&utm_content=dkim-key-rotation) Palisade does not change the DKIM key, alter your DNS, or prove every future message will authenticate. Review the evidence and apply any change through your approved process. ## Sources and further reading - [RFC 6376: DomainKeys Identified Mail Signatures](https://www.rfc-editor.org/rfc/rfc6376.html#section-3.1) - [RFC 8301: Cryptographic Algorithm and Key Size Update to DKIM](https://www.rfc-editor.org/rfc/rfc8301.html) - [RFC 8601: Authentication-Results message header field](https://www.rfc-editor.org/rfc/rfc8601.html) - [Palisade DKIM checker](/tools/dkim) ## Frequently asked questions ### Is rotating DKIM keys every 90 days required? No. The DKIM RFCs do not require a universal 90-day interval. An organization may choose that interval in its own policy if its providers, DNS process, and verification workflow can support safe rotation. ### Can I replace a DKIM key while keeping the same selector? No. RFC 6376 advises against using the same selector with replacement key material. Publish the replacement key under a new selector so receivers can verify both old and new signatures during the transition. ### How long should an old DKIM key remain published? Only until messages signed with the old selector have had a reasonable opportunity to be verified, plus your approved rollback window. DKIM does not specify one duration that applies to every sender or receiver. ### Does a DKIM DNS record prove that mail is signing correctly? No. A DNS record proves only that a public key is available at that selector. Confirm correct signing by inspecting a real delivered message from the exact production route and checking its authentication results. ### Should I remove a DKIM key after suspected exposure? Yes. Replace the key under a new selector, switch signing away from the affected private key, and remove or revoke the old public key after the transition evidence supports retirement. Investigate how the private key may have been exposed. --- # What is DMARC in cyber security? Canonical: https://www.palisade.email/learning/dmarc-cyber-security > DMARC in cyber security is a DNS-published protocol that authenticates a domain's email, sets a policy for failures, and reports abuse back to the owner. DMARC (Domain-based Message Authentication, Reporting Conformance) is an email authentication, policy, and reporting protocol that a domain owner publishes in DNS. It builds on SPF and DKIM, ties their results to the visible From: domain, tells receiving mail systems how to handle messages that fail that check, and sends reports back to the domain owner. In cyber security terms, DMARC is the control that stops attackers from sending mail that appears to come from a domain they don't own. ## Quick takeaways - DMARC stands for Domain-based Message Authentication, Reporting Conformance, per [dmarc.org's own definition](https://dmarc.org/). - It doesn't replace SPF or DKIM. It adds a policy layer and a reporting layer on top of them. - The policy is published as a DNS TXT record, so any domain owner can implement it at no licensing cost. - DMARC became an IETF Standards Track protocol in May 2026, formalized across three RFCs that obsolete the original 2015 specification. - A domain's DMARC record tells receivers what to do with a message that fails authentication and alignment: nothing, quarantine, or reject. - DMARC is a domain-level control. It authenticates the sending domain, not the message content or the sender's intent. ## How DMARC works as a cyber security control Email spoofing works because SMTP was never designed to verify who actually sent a message. The From: address a recipient sees can be set to anything, and until authentication protocols existed, a receiving mail server had no reliable way to check it. SPF and DKIM each solve part of that problem separately: SPF checks whether the sending server is authorized for the domain, and DKIM checks whether the message carries a valid cryptographic signature from the domain. Neither one, on its own, requires that the domain it validates match the domain the recipient actually sees in their inbox. That's the gap DMARC closes. Per dmarc.org's definition, DMARC "builds on the widely deployed SPF and DKIM protocols, adding linkage to the author (From:) domain name, published policies for recipient handling of authentication failures, and reporting from receivers to senders, to improve and monitor protection of the domain from fraudulent email." A message only passes DMARC when SPF or DKIM passes **and** the domain that passed is aligned with the visible From: domain. A message can pass SPF and still fail DMARC if the SPF-authenticated domain doesn't match what the recipient sees. That alignment check is why DMARC sits in the cyber security conversation rather than just the deliverability one. It closes the specific spoofing path that phishing and business email compromise campaigns rely on: sending mail that looks like it came from a trusted domain because the visible From: address says so, even though nothing about the message was actually verified against that domain. The full mechanics of what counts as a DMARC pass and how alignment is evaluated are set out in [what DMARC is](/learning/dmarc), which covers the protocol in more depth than the definition alone. ## When DMARC's protection changes: the policy tag DMARC's practical effect depends entirely on the policy a domain owner chooses to publish, expressed with the `p` tag in the DNS record, as defined in [RFC 9989](https://datatracker.ietf.org/doc/html/rfc9989), the current IETF Standards Track document for DMARC: - `p=none` requests no handling change from receivers. The domain can still collect aggregate reports and use them to inventory legitimate senders before requesting stronger action. - `p=quarantine` asks receivers to treat DMARC failures as suspicious, commonly by routing them to spam or a review queue. - `p=reject` asks receivers not to accept messages that fail DMARC under the domain's published policy. A receiver can weigh that request against its own local policy, so a published `p=reject` record is a strong signal, not a guarantee that every receiver rejects every failing message. Monitoring under `p=none` is what gives a domain owner the evidence to move toward `p=reject` without breaking mail that legitimate services still send on the domain's behalf, a tradeoff covered in [how DMARC affects cyber insurance underwriting](/learning/how-does-dmarc-affect-cyber-insurance) for teams evaluating DMARC as part of a broader risk posture, not just a technical control. ## A worked DMARC record The record below is illustrative only, built to show the tag structure RFC 9989 defines. It is not a value to publish as-is; the reporting address and domain must be your own. ```text v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@yourdomain.com; adkim=r; aspf=r ``` Reading it tag by tag: - `v=DMARC1` identifies the record as a DMARC policy. - `p=quarantine` requests suspicious handling for messages that fail DMARC. - `rua` names where aggregate reports should be sent, giving the domain owner visibility into which sources are sending mail as the domain and whether they're authenticating correctly. - `adkim` and `aspf` set DKIM and SPF alignment mode. `r` (relaxed) allows a subdomain match; `s` (strict) requires an exact match. The record answers a narrow set of questions: what policy is requested, where reports go, and how strict alignment must be. It doesn't identify which specific messages passed or failed, and it doesn't prove a receiver actually applied the requested handling. That evidence comes from the aggregate reports the `rua` address collects, not from the record itself. ![Flow diagram showing how DMARC evaluates a message: authentication and alignment check, then the policy action a domain's DMARC record requests](/images/editorial/dmarc-cyber-security/dmarc-cyber-security-flow.webp "1200x920") *Source: Palisade.* ## The practical next step: check what your domain publishes Because DMARC is a free, DNS-published standard with no licensing restriction, any domain owner can check what their organization currently has published, and any domain owner can implement it, per [dmarc.org's overview of who can use DMARC](https://dmarc.org/). The first diagnostic step is a lookup: does the domain have a DMARC record at all, and if it does, what policy does it request. [Check the DMARC record](/tools/dmarc) for your sending domain to see the currently published policy, its reporting addresses, and its alignment settings. If no record exists, DMARC is providing no protection for that domain regardless of what SPF or DKIM alone are doing. If a record exists at `p=none`, the domain is likely still in the reporting and inventory phase rather than actively blocking spoofed mail. A single lookup shows what's published in DNS at the moment you check it. It doesn't show which senders are currently failing alignment, whether legitimate mail would break under a stricter policy, or how the record has changed over time. Reading and acting on aggregate reports, covered in [are DMARC failure reports worth the trouble](/learning/what-exactly-is-a-dmarc-failure-report-and-why-should-you-care), is the layer that turns a published policy into an actively managed control. ## Move from a published record to a managed one Publishing `p=none` and collecting reports is the easy part. Reading those reports well enough to know which sources are legitimate, which need fixing, and when it's safe to move to `p=quarantine` or `p=reject` is the ongoing work that a one-time record check can't do for you. Palisade's DMARC Agent analyzes aggregate report data, identifies sending sources with authentication or alignment problems, creates prioritized remediation tickets, and flags when a domain looks ready for the next policy stage, with a human reviewing the evidence before any change is applied. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=dmarc_troubleshooting&utm_content=dmarc-cyber-security) A record check confirms what's published today. It doesn't identify every source sending as your domain, and moving to a stricter policy without that inventory can block legitimate mail rather than just spoofed mail. ## Sources and further reading - [dmarc.org: What is DMARC?](https://dmarc.org/) - [dmarc.org: Status of DMARC](https://dmarc.org/) - [RFC 9989: Domain-based Message Authentication, Reporting, and Conformance](https://datatracker.ietf.org/doc/html/rfc9989) - [What is DMARC](/learning/dmarc) - [How DMARC affects cyber insurance](/learning/how-does-dmarc-affect-cyber-insurance) ## Frequently asked questions ### What is the difference between DMARC and DKIM? DMARC is not a replacement for DKIM. It's built on top of it. DKIM is a cryptographic signature check that confirms a message wasn't altered in transit and came from an authorized domain. DMARC takes that result (along with SPF's result), checks whether the authenticated domain lines up with the domain the recipient sees in the From: field, and applies a published policy and reporting layer on top. Per dmarc.org, DMARC "builds on the widely deployed SPF and DKIM protocols, adding linkage to the author (From:) domain name, published policies for recipient handling of authentication failures, and reporting." DKIM alone can pass without the signing domain matching the visible From: domain; DMARC is the layer that closes that gap. ### What is an example of a DMARC? A DMARC record is a DNS TXT record published at `_dmarc.yourdomain.com`, structured with tags defined in RFC 9989. An illustrative example is `v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@yourdomain.com; adkim=r; aspf=r`, which requests quarantine handling for failing messages, sends aggregate reports to the listed address, and sets relaxed alignment for both DKIM and SPF. This is a structural example, not a value to publish directly; the domain and reporting address must be your own. ### Is DMARC really necessary? Yes, for any domain that sends or could be spoofed for email. DMARC's stated purpose, per dmarc.org, is "to improve and monitor protection of the domain from fraudulent email," and it's free to implement with no licensing restriction. A domain with no DMARC record has no policy telling receivers what to do with mail that fails SPF or DKIM alignment, which leaves attackers free to send convincing spoofed mail using that domain's name with no mechanism in place to request that receivers reject or flag it. ### What is DMARC for dummies? DMARC is a free email standard that checks whether a message actually came from the domain it claims to be from, and tells receiving mail servers what to do if it didn't: let it through, treat it as suspicious, or reject it. The domain owner publishes this as a DNS record, and receiving mail servers send reports back showing which senders are using the domain and whether they're passing or failing the check. It's the mechanism that lets a domain owner ask mailbox providers not to deliver mail that's pretending to be from them. --- # What is the DMARC np tag and how do you use it? Canonical: https://www.palisade.email/learning/dmarc-np-tag > The np tag applies a policy to subdomains that do not exist, closing the gap attackers use to spoof made-up subdomains. When to add np=reject, and when not to. The DMARC `np` tag sets the policy for a non-existent subdomain, such as `billing.yourdomain.com` when that name does not exist in DNS. Under [RFC 9989](https://www.rfc-editor.org/rfc/rfc9989.html), a domain owner can publish `np=none`, `np=quarantine`, or `np=reject` in the organizational domain's DMARC record. Use it when you want an explicit policy for invented subdomains while keeping `p` and `sp` policies for other cases. ## Quick takeaways - The `np` tag is defined by RFC 9989, the current DMARC standard that obsoletes RFC 7489. - `np` applies only when the RFC 5322.From domain is a non-existent subdomain of the organizational domain. - Valid `np` values are `none`, `quarantine`, and `reject`. - The `np` tag belongs in the organizational domain's DMARC TXT record, not on an invented subdomain. - A receiver that does not implement RFC 9989 may not apply `np`, so `p` and `sp` still matter. - A published DMARC record does not prove that a production sender authenticates or aligns correctly. ## Who is affected? The `np` tag affects domain owners that publish DMARC for an organizational domain and want to define the requested disposition for mail that uses a child domain that does not exist. For example, `example.com` can publish an `np` policy that a receiver evaluates when mail claims to be from `notice.example.com` and that subdomain does not exist. RFC 9989 defines DMARC discovery and policy evaluation for participating receivers. It does not require every receiving system to implement every optional feature immediately, and it does not make `np` mandatory for domain owners. The standard says a domain owner **MAY** publish an `np` tag. See [RFC 9989 section 6.3](https://www.rfc-editor.org/rfc/rfc9989.html#section-6.3) for the DMARC record tags and their meanings. `np` does not apply to the organizational domain itself. It also does not replace a DMARC record published directly at an existing subdomain. If `marketing.example.com` exists and has `_dmarc.marketing.example.com`, that subdomain's own DMARC record is the relevant policy record. For the wider policy model, see Palisade's [DMARC learning hub](/learning/dmarc) and the related explanation of [what the DMARC `np` tag means](/learning/glossary/dmarc-np). ## What are the requirements? ### The `np` tag uses a DMARC disposition value RFC 9989 defines `np` as the requested policy for non-existent subdomains. Its permitted values match the policy values used by `p` and `sp`: `none`, `quarantine`, and `reject`. The value expresses the domain owner's requested handling when DMARC evaluation fails. It does not instruct a receiver to override its local policy or guarantee a particular mailbox outcome. ```text v=DMARC1; p=reject; sp=quarantine; np=reject ``` > Do not publish this example unchanged. Add `np` to the one existing DMARC TXT record for your organizational domain, preserving the reporting and policy tags your domain already needs. ![Example DMARC record showing p, sp, and np policies for yourdomain.com](/images/editorial/dmarc-np-tag/dmarc-np-tag-policy-record.webp "1200x600") *Source: Palisade.* In this illustrative record, [`p=reject`](/learning/glossary/dmarc-p-reject) is the requested policy for `yourdomain.com`, `sp=quarantine` is the requested subdomain policy, and `np=reject` is the requested policy when the evaluated child domain does not exist. The [RFC 9989 DMARC record syntax](https://www.rfc-editor.org/rfc/rfc9989.html#section-6.3) requires `v=DMARC1` to be the first tag. ### A non-existent subdomain has a specific policy path RFC 9989 distinguishes a non-existent domain from an existing subdomain that lacks its own DMARC record. During DMARC policy discovery, the receiver determines the organizational domain and evaluates the relevant record. When the RFC 5322.From domain is a non-existent subdomain, the `np` tag provides the requested policy if it is present. If it is absent, the applicable policy falls back to the organizational domain's `p` value. The `sp` tag applies to subdomains in the ordinary subdomain policy case described by the standard. [RFC 9989 section 6.6.3](https://www.rfc-editor.org/rfc/rfc9989.html#section-6.6.3) defines this policy discovery behavior. This makes `np` a narrow control. Do not assume it protects every message using a subdomain-like name. The receiver must first treat that name as a non-existent subdomain under its DMARC evaluation process, then DMARC must fail before the requested disposition becomes relevant. ### The `np` tag belongs in the organizational DMARC record Publish `np` in the DMARC record at `_dmarc.yourdomain.com`, where `yourdomain.com` is the organizational domain. Do not create a TXT record at `_dmarc.billing.yourdomain.com` for a non-existent name. Creating DNS records for that label can change whether the label is non-existent, which changes the policy path that RFC 9989 describes. DMARC permits one valid record at a given policy-discovery name. Multiple records at `_dmarc.yourdomain.com` can cause receivers to treat the DMARC record as invalid. RFC 9989 specifies that multiple records found during lookup are a permanent error. [RFC 9989 section 6.6.3](https://www.rfc-editor.org/rfc/rfc9989.html#section-6.6.3) covers the lookup result. ## When does the requirement take effect? RFC 9989 was published in May 2026 as a Proposed Standard and obsoletes RFC 7489. It defines `np`, but it does not set a future enforcement date for all senders or receivers. The `np` tag is optional for a domain owner because the standard uses **MAY** for publishing it. [RFC 9989 publication metadata](https://www.rfc-editor.org/rfc/rfc9989.html) is the controlling source for its status and obsolescence relationship. There is no universal date after which every mailbox provider must honor `np`. A receiver's current implementation is separate from the protocol definition. Keep `p` and, where appropriate, `sp` aligned with the policy you want receivers that do not apply `np` to evaluate. ## How do I implement the requirement? ### 1. Find the organizational domain's existing DMARC record Query `_dmarc.yourdomain.com` at the authoritative DNS provider and inspect the TXT record before changing it. Confirm that you are editing the organizational domain, not a sending subdomain with its own DMARC policy. Use Palisade's [DMARC checker](/tools/dmarc) to inspect the public record after you identify the domain. A public lookup shows the record currently returned by DNS. It cannot show whether every production sender uses that domain correctly. ### 2. Decide the requested policy for invented subdomains Choose the `np` value that matches the policy you want a participating receiver to evaluate after a DMARC failure. `np=none` requests no specific disposition, `np=quarantine` requests [the quarantine disposition](/learning/glossary/dmarc-p-quarantine), and `np=reject` requests rejection. This is implementation guidance, not a requirement to use `reject`. Before selecting an enforcement value, account for any legitimate mail that uses a child domain which might be treated as non-existent. Give real sending domains deliberate DNS and DMARC configuration instead of relying on an implicit fallback. ### 3. Add one `np` tag to the existing record Append the tag to the existing DMARC record. Keep `v=DMARC1` first and retain the tags required for your reporting and rollout process. ```text v=DMARC1; p=quarantine; sp=quarantine; np=reject; rua=mailto:dmarc-reports@yourdomain.com ``` The address and policies above are illustrative only. Use a reporting address and policy values approved for your domain. Do not create a second DMARC TXT record to add `np`. ### 4. Publish the DNS change and allow caches to expire Save the change at the authoritative DNS provider. DNS responses can remain cached according to the record's TTL, so compare the authoritative value with a public resolver response after publication. If the record contains other policy controls, review them separately. For example, the [DMARC `adkim` tag](/learning/dmarc-adkim-tag) changes DKIM alignment strictness. It does not control how `np` applies to a non-existent subdomain. ## How do I validate compliance? Validate the record at four layers. - DNS: query the authoritative DNS service and at least one public resolver for `_dmarc.yourdomain.com`. Confirm one parseable DMARC record contains the intended `np` value. - Vendor: if your DNS provider has a publication status, use it to confirm the provider accepted the TXT value. That status is not proof of receiver behavior. - Message: send a controlled message through each real production path and inspect its `Authentication-Results` header. This confirms authentication and alignment for that message, not the handling of a hypothetical non-existent subdomain. - DMARC: review aggregate reports after data accumulates to identify sources and failures. A report period can reveal traffic that a single DNS lookup cannot. For a controlled `np` test, use a domain and receiver path your organization is authorized to test. Do not add records to the test child domain after defining it as non-existent, because that changes the condition under evaluation. Compare the delivered-message headers and receiver result with the public DMARC record, while recognizing that a receiver's local handling remains its own decision. ## Inspect the DMARC record before changing policy Check the organizational domain's current DMARC record before adding `np`, then compare it with the DNS value after publication. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=email_authentication&utm_content=dmarc-np-tag) Palisade is DMARC software that analyzes DMARC aggregate-report data, identifies sending sources and authentication or alignment issues, and creates prioritized remediation tickets. It can propose the next DMARC policy step for human review, but it does not autonomously change the policy or guarantee a receiver's delivery decision. A public DMARC check cannot prove which production sources will fail alignment later or how every receiver will apply `np`. ## Sources and further reading - [RFC 9989: Domain-based Message Authentication, Reporting, and Conformance](https://www.rfc-editor.org/rfc/rfc9989.html) - [RFC 9989 section 6.3: DMARC tag definitions](https://www.rfc-editor.org/rfc/rfc9989.html#section-6.3) - [RFC 9989 section 6.6.3: DMARC record discovery](https://www.rfc-editor.org/rfc/rfc9989.html#section-6.6.3) ## Frequently asked questions ### Is the DMARC `np` tag required? No. RFC 9989 says a domain owner MAY publish an `np` tag. A valid DMARC record can omit it, in which case the receiver follows the applicable policy behavior defined by the standard. ### Does `np=reject` reject every spoofed message? No. The `np` tag is relevant only when the RFC 5322.From domain is a non-existent subdomain and DMARC evaluation fails. A receiver also retains its own local policy and delivery decision. ### Does `np` replace the `sp` tag? No. The tags cover different policy cases. `np` addresses non-existent subdomains, while `sp` is the subdomain policy tag. Keep the organizational policy design explicit instead of assuming one tag replaces all subdomain handling. ### Where do I publish the `np` tag? Publish `np` in the organizational domain's DMARC TXT record, such as `_dmarc.yourdomain.com`. Do not publish it on a child domain that is meant to remain non-existent. ### Can a DMARC checker prove that `np` works at every mailbox provider? No. A checker can show whether the public record contains a valid `np` tag. It cannot prove a receiver's implementation, its private disposition decision, or the authentication outcome of future production messages. --- # DNS TXT SPF record: what it is and how it works Canonical: https://www.palisade.email/learning/dns-txt-spf > An SPF policy is published in DNS as a TXT record starting with v=spf1. Learn the record format, size limits, and how to check if your domain has one. An SPF policy is published in DNS as a TXT record, not as its own DNS record type. RFC 7208 requires that SPF data appear only in a TXT (type 16) resource record whose text begins with the tag `v=spf1`. A dedicated SPF record type existed under an earlier RFC, but current implementations don't use it. To find out whether a domain has SPF, a receiver queries DNS for TXT records at that domain and looks for one that matches the tag. ## Quick takeaways - SPF policy content MUST be published in a DNS TXT (type 16) record; a separate SPF record type exists in DNS history but isn't used by current implementations. - Every valid SPF record starts with the version tag `v=spf1`, immediately followed by a space or the end of the record. - A domain must not have more than one TXT record matching that tag. If a receiver finds more than one, the check returns `permerror` instead of picking one. - If no TXT record at the domain begins with `v=spf1`, the standards-defined result is `none`, the formal meaning of "this domain has no SPF record." - A TXT record's value can span several internal strings of up to 255 octets each; SPF treats those strings as one record concatenated together. - SPF records should stay small enough that the full DNS answer fits inside a 512-octet response. ## How an SPF policy lives inside a DNS TXT record A TXT record is a general-purpose DNS record. [RFC 1035 defines its RDATA](https://www.rfc-editor.org/rfc/rfc1035) as "one or more `<character-string>`s," and its meaning depends entirely on which domain the record is attached to. Nothing about the TXT record type itself relates to email; a domain can carry TXT records for many unrelated purposes. For the general record shape, see [what a TXT record is](/learning/what-is-a-txt-record). SPF narrows that general container to one specific use. [RFC 7208](https://www.rfc-editor.org/rfc/rfc7208) states that SPF records "MUST be published as a DNS TXT (type 16) Resource Record (RR) only," with the record's content encoded as US-ASCII. An earlier RFC had defined a dedicated DNS record type for SPF, code 99. RFC 7208 reports that this type "saw no substantial use, and interoperability issues in a common DNS server made its future application questionable at best," and current implementations are not to use it. That history is why every current SPF policy is a TXT record and nothing else. SPF sits alongside other authentication mechanisms, including DKIM and DMARC, inside the broader [email authentication](/learning/dmarc) picture. The full grammar an SPF record uses to authorize senders lives on the SPF hub. ## When the record's exact content changes the result A record only counts as SPF if its text begins with the exact tag `v=spf1`, immediately followed by a space or the end of the record. RFC 7208 states the version section "ends at the space character... or the end of the record," so a record starting with something like `v=spf10` does not match and is discarded. When a receiver checks a domain, it queries DNS for TXT records only. Two outcomes follow directly from what DNS returns: - If no TXT record at the domain begins with `v=spf1`, the result is `none`. That is the standards-level meaning of "this domain has no SPF record." - If more than one TXT record at the domain matches, the domain is out of compliance. RFC 7208 requires that a domain "MUST NOT have multiple records that would cause an authorization check to select more than one record." When a receiver still finds several matching records, the check returns `permerror` rather than guessing which one is authoritative. ![SPF DNS TXT lookup decision rule showing when a domain check returns none, proceeds, or permerror](/images/editorial/dns-txt-spf/dns-txt-spf-decision-rule.webp "1200x676") *Source: Palisade.* Size matters too, though less strictly. A TXT record's RDATA can hold more than one internal character-string, each capped at 255 octets by the DNS wire format in RFC 1035. RFC 7208 says a record with multiple strings "MUST be treated as if those strings are concatenated together without adding spaces," which is how a policy longer than 255 octets fits inside one TXT record. RFC 7208 also recommends the record stay small enough that the full DNS answer fits inside a 512-octet response, using a combined name-and-record length under 450 octets as the practical guideline for UDP. If a check keeps returning `permerror` for a different reason, specifically too many nested DNS lookups rather than duplicate records, that failure mode has its own fix; see [how to fix SPF PermError: too many DNS lookups](/learning/how-do-i-fix-spf-permerror-too-many-dns-lookups). ## A worked SPF TXT record RFC 7208 gives this as an example of a correctly formed SPF record: ```text v=spf1 +mx a:colo.example.com/28 -all ``` This is the standards body's own illustrative example, not a live production value, and it should not be copied onto a real domain. Two things about its shape apply to any SPF TXT record, regardless of which mechanisms it uses: - The record starts with `v=spf1`, and nothing precedes it. - Everything after the version tag is one continuous string, even when the underlying TXT record stores it as several concatenated character-strings on the wire. The specific mechanisms in the example, and how a domain chooses which senders to authorize, are covered in full on the SPF hub. ## What to check before you publish or troubleshoot a record If a domain doesn't yet have a matching record, three requirements come directly from the RFCs above, independent of which DNS provider hosts the zone: - Publish the value as a TXT (type 16) record, not any other record type. - Make sure the record's text begins with `v=spf1`, with nothing before it. - Confirm the domain ends up with exactly one TXT record matching that tag. A second matching record, even one added by a different team or a forgotten legacy entry, produces `permerror` rather than a working policy. Exact steps for adding or editing a TXT record differ by DNS host, and the interface itself sits outside the scope of the record format. After making a change, query the domain from more than one resolver, since DNS providers and public resolvers can serve a stale answer for a short period after an edit. ## Check whether your domain publishes an SPF record Run the domain through Palisade's SPF checker to see the same DNS TXT lookup described above applied to your own domain, instead of working it out by hand against a DNS provider's interface. [Check the SPF record](/tools/spf) A DNS TXT lookup only confirms what's published. It doesn't confirm that a specific sending source is included in the record, that DKIM or DMARC are configured correctly alongside it, or that a receiving mail server will treat a given message as authenticated. ## Sources and further reading - [RFC 7208: Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1](https://www.rfc-editor.org/rfc/rfc7208) - [RFC 1035: Domain names, implementation and specification](https://www.rfc-editor.org/rfc/rfc1035) - [Palisade SPF checker](/tools/spf) ## Frequently asked questions ### What is the difference between DNS SPF and TXT? TXT is a general-purpose DNS record type; SPF is one specific kind of policy text published inside a TXT record. RFC 1035 defines a TXT record's data as one or more character-strings whose meaning depends on the domain where they're found, with no inherent tie to email. RFC 7208 narrows that container for email authentication: SPF data must be published only in a TXT (type 16) record, and only counts as SPF once its text begins with `v=spf1`. An earlier dedicated SPF record type existed under a separate DNS type code, but current implementations don't use it, so DNS TXT is now the only record type SPF uses. ### Do I have SPF on my domain? Not by default. A domain has no SPF policy unless someone has published a matching TXT record for it. To check, a lookup queries DNS for TXT records at the domain and looks for one whose text begins with `v=spf1`; if none matches, the standards-defined result is `none`. Palisade's SPF checker runs that same TXT lookup against a domain you enter, so you can see the result without querying DNS by hand. ### How to enter SPF record in DNS? The exact interface depends on which DNS provider hosts the domain, but the record's requirements don't change between providers. It must be added as a TXT record, its value must begin with `v=spf1`, and the domain must not end up with more than one TXT record matching that tag, since a second matching record causes the check to return `permerror` instead of a working policy. Check your DNS provider's own documentation for the specific steps to add or edit a TXT record in their interface. ### What is SPF for SMTP? RFC 7208 is formally titled "Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1," and it defines how a domain's SPF policy is published in DNS and read by a receiving mail system. This article covers that publication step: SPF policy data lives in a DNS TXT record. The mechanisms that determine which sending sources a record actually authorizes are a separate topic covered on the SPF hub. --- # EasyDMARC SPF checker: what it shows and how to read the result Canonical: https://www.palisade.email/learning/easydmarc-spf-checker > EasyDMARC SPF checker folds SPF into a combined domain score. See what Low, Medium, and High mean and how to verify SPF yourself against RFC 7208. EasyDMARC's public SPF checker is not a separate SPF-only tool. Entering a domain on EasyDMARC's homepage runs a combined scan that returns a Risk Assessment Level of Low, Medium, or High and a DMARC Policy score out of 10, folding SPF together with DKIM and DMARC. To know whether SPF itself is valid, read the raw record against RFC 7208's rules directly, or run a dedicated SPF-only lookup. ## Quick takeaways - EasyDMARC's homepage scanner combines SPF, DKIM, and DMARC into one Risk Assessment Level and a DMARC Policy score out of 10; it does not publish a standalone SPF-only result page. - EasyDMARC also sells EasySPF, a paid product that flattens an SPF record to work around the 10 DNS-lookup limit. - The 10-lookup ceiling and the one-record-per-domain rule both come from RFC 7208, not from any vendor's checker. - A record can look fine in a combined score and still fail a live message if a sending service was added after the record was last updated. - A dedicated SPF-only checker confirms the isolated record state without averaging it against DKIM and DMARC. ## What this tool checks Enter a domain at [EasyDMARC's homepage](https://easydmarc.com) and its scanner returns two headline numbers: a "Risk Assessment Level: Low / Medium / High" and a "DMARC Policy: Score 0 of 10," evaluating SPF, DKIM, and DMARC together. This is the tool most people find when searching for an EasyDMARC SPF check, but its published output describes a whole-domain assessment, not an isolated SPF report. EasyDMARC also sells EasySPF, described on the same page as performing "a one-time DNS configuration" that lets a user "manage your SPF record from a centralized platform" and "eliminates issues like the 10 DNS lookup limit by dynamically flattening the record, converting domain includes into IP addresses." That is a paid remediation product, separate from the free scan. Both tools only see what is published in public DNS. Neither confirms that the server actually sending your mail uses the domain the record was written for, or that a specific message authenticated on delivery. For a side-by-side look at how free SPF and DMARC checkers compare, see Palisade's [comparison hub](/compare). ## How to run the check ### 1. Pull the current SPF record yourself Before trusting any score, query the domain's own TXT record so you have independent evidence: ```bash dig +short TXT yourdomain.com ``` Look for the line beginning with `v=spf1`. [RFC 7208](https://datatracker.ietf.org/doc/html/rfc7208) permits exactly one SPF record per domain; a second one is a permanent error, not a second layer of protection. ### 2. Run the domain through EasyDMARC's scanner Go to easydmarc.com and enter the domain. Note the Risk Assessment Level and the DMARC Policy score. Because the score blends three protocols, a Low risk rating does not by itself mean the SPF record has no problems: a strong DKIM and DMARC setup can offset a weaker SPF record in a combined score. ![EasyDMARC product graphic used on its marketing pages to illustrate combined SPF, DKIM, and DMARC reporting](/images/editorial/easydmarc-spf-checker/easydmarc-spf-checker-easydmarc-spf-checker-homepage-scan-widget.webp "1600x900") *Source: [EasyDMARC](https://easydmarc.com), general product graphic, checked 2026-08-11.* ### 3. Count the record's own DNS lookups Read back through the record you pulled in step 1 and count every mechanism that triggers its own DNS lookup: `include`, `a`, `mx`, `ptr`, `exists`, and `redirect`. RFC 7208 caps SPF evaluation at 10 of these per check. Going over that ceiling produces a permanent error regardless of what any combined score reports. ## How to interpret the results ### Risk assessment level: Low EasyDMARC's own page publishes the label names, Low, Medium, and High, without publishing the scoring formula behind them. Treat a Low rating as a starting point, not a substitute for reading the record. A domain can carry a technically valid SPF record and still land in this tier partly because of DKIM or DMARC factors, since a combined score does not isolate any single protocol. ### Risk assessment level: Medium or High A Medium or High rating tells you at least one of SPF, DKIM, or DMARC needs attention, but not which one on its own. Pull the record yourself (step 1) and compare it against RFC 7208's requirements: one record, prefixed with `v=spf1`, ending in an explicit qualifier such as `-all` or `~all`, and under the 10-lookup ceiling. ### DMARC policy score out of 10 The DMARC Policy score is a separate number from the risk level and reflects the DMARC record's policy strength directly. A domain publishing `p=none` scores lower than one publishing `p=reject`, independent of whether its SPF record is otherwise correct. Palisade's [DMARC checker](/tools/dmarc) reads the same `p=` tag directly if you want to confirm the enforcement level without the combined score attached. ## An independent SPF result matrix Because a combined score does not isolate SPF, the table below separates the raw SPF states defined by RFC 7208 from what each one means and what to do next. This is an original reference built from the RFC, not a reproduction of any vendor's output. ![Table mapping SPF checker result states to their RFC 7208 meaning and the recommended fix](/images/editorial/easydmarc-spf-checker/spf-result-states.webp "1200x666") *Source: Palisade.* ## How to act on the result For a missing or malformed record, republish it from the sending service's current documentation rather than copying an old one from another domain. For a lookup count near or over 10, either remove unused includes or evaluate a flattening product like EasyDMARC's EasySPF, which converts includes into static IP addresses; that is a tradeoff worth weighing, since a flattened record needs regenerating whenever an underlying service's IP ranges change. For a record that reads as valid on both the combined score and the RFC checklist, the remaining question is whether the server that sent your last message actually matches the record and whether the return path aligns with the visible From domain. Palisade's [SPF checker](/tools/spf) inspects the record directly rather than folding it into a combined score, which makes it a faster way to confirm the isolated SPF state at any point in a repair. ![Generic Palisade product graphic illustrating DMARC agent reporting, not a specific SPF checker results screen](/images/editorial/easydmarc-spf-checker/easydmarc-spf-checker-easydmarc-spf-checker-interpretation-matrix.png "1600x900") *Source: Palisade, general product graphic, checked 2026-08-11.* ## Investigate this with your coding agent Use this when a record already has five or six mechanisms and you cannot tell by eye whether it is near the 10-lookup ceiling. Export the record from your DNS provider or version-controlled zone file, and redact the domain name before handing it to the agent. ```agent Problem: A domain's SPF TXT record may exceed RFC 7208's 10 DNS-lookup limit or contain a syntax error, and it is unclear which included domain accounts for the most lookups. Evidence: The current SPF TXT record for the domain (redact the domain name and any internal hostnames), taken from `dig +short TXT yourdomain.com` or the DNS provider's export, plus the zone file or IaC source if one exists. Repository scope: The DNS zone file, the Terraform or other IaC module defining the TXT record, and any script that generates it. No application code. Constraints: Inspect before editing. Do not apply changes until I approve the proposed diff. Do not query external resolvers with the real production domain name if that is a concern; work from the redacted record text instead. Requested output: A count of DNS-querying mechanisms (include, a, mx, ptr, exists, redirect) against the 10-lookup ceiling, a list of any syntax issues (missing v=spf1, missing or ambiguous terminating mechanism, more than one SPF record), and a minimal proposed rewrite naming the removed or merged mechanisms. Verification: Re-run the same redacted record through Palisade's SPF checker or a fresh dig +short TXT query after a human applies the DNS change, and confirm the lookup count and syntax state both changed as expected. Stop if: The task requires DNS provider credentials, API tokens, or write access to production DNS. Report findings only. ``` ## How to retest After you change the record, propagation means the new value will not appear everywhere at once. Query the authoritative name server directly first: ```bash dig +short TXT yourdomain.com @<authoritative-ns> ``` Then check a public resolver such as 8.8.8.8 or 1.1.1.1 to confirm the change has spread. Only after both agree should you re-run EasyDMARC's scanner or Palisade's [SPF checker](/tools/spf) and expect the new record to show. Neither check confirms your outbound server is actually using the new record until a live message goes out and its `Authentication-Results` header shows an SPF pass; that step needs a delivered message, not a DNS lookup alone. ## Check the SPF record, then keep it accurate as senders change A one-time scan, from EasyDMARC or from Palisade's own checker, confirms today's record. It does not catch the day a team adds a new marketing platform or help desk tool that sends mail from the domain without anyone updating the SPF `include`, which is a common way a previously valid record starts failing alignment months later. Palisade's DMARC Agent reads incoming aggregate reports, identifies which sending sources are failing SPF or DKIM alignment, and creates a prioritized ticket when a new or misaligned source shows up, while a human reviews the evidence and applies the DNS change. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=vendor_comparisons&utm_content=easydmarc-spf-checker) ## Sources and further reading - [EasyDMARC](https://easydmarc.com) - [RFC 7208: Sender Policy Framework (SPF)](https://datatracker.ietf.org/doc/html/rfc7208) - [RFC 9989: Domain-based Message Authentication, Reporting, and Conformance (DMARC)](https://www.rfc-editor.org/rfc/rfc9989.html) - [Palisade SPF checker](/tools/spf) - [Palisade DMARC checker](/tools/dmarc) ## Frequently asked questions ### How do I check if an SPF record is valid? Query the domain's TXT records and confirm exactly one starts with `v=spf1`, per [RFC 7208](https://datatracker.ietf.org/doc/html/rfc7208). Count every mechanism that triggers a DNS lookup (`include`, `a`, `mx`, `ptr`, `exists`, `redirect`) and confirm the total stays at or under 10. The record must also end in an explicit qualifier, most commonly `-all` or `~all`. A dedicated checker such as [Palisade's SPF checker](/tools/spf), or a plain `dig +short TXT` query against your own domain, confirms this directly without folding SPF into a wider score. ### Does DMARC override SPF? No, DMARC does not replace or override SPF. It reads the SPF (and DKIM) result and adds an identifier alignment check on top, per [RFC 9989](https://www.rfc-editor.org/rfc/rfc9989.html). A message can pass SPF on its own and still fail DMARC if the domain SPF authenticated does not align with the visible From header domain. DMARC's policy tag then decides what a receiver does with that outcome, not SPF's pass or fail result by itself. ### Why did SPF cause my mail to be rejected? SPF failure by itself does not usually reject a message; most mailbox providers act on a domain's own DMARC policy after an SPF or DKIM failure, not on SPF alone. Two SPF-specific causes are common: the lookup count exceeded the RFC 7208 ceiling of 10, which returns a PermError treated as a fail, or a sending service was added without updating the record's `include` mechanism, so its sending IP is no longer listed. Reading the exact message from your own mail logs alongside the record narrows down which one applies. ### How does EasyDMARC work? EasyDMARC scans a domain's SPF, DKIM, and DMARC records from its homepage and returns a Risk Assessment Level of Low, Medium, or High plus a DMARC Policy score out of 10. From there it sells remediation products for what the scan finds, including EasySPF for flattening an SPF record past the lookup limit, managed DKIM, and reputation monitoring, according to [EasyDMARC's own product pages](https://easydmarc.com). ### Does EasySPF fix a record that is already over the lookup limit? Yes. EasyDMARC describes EasySPF as performing "a one-time DNS configuration" that "dynamically flattening the record, converting domain includes into IP addresses," according to [its product page](https://easydmarc.com). That approach removes the includes causing the extra lookups, though a flattened record needs to be regenerated later if one of the underlying services changes its sending IP ranges, since the record no longer references the include dynamically. --- # What is two-factor authentication for email? Canonical: https://www.palisade.email/learning/email-2-factor-authentication > Email two-factor authentication pairs your password with a second proof, like an authenticator app code, before sign-in succeeds. Here's how it works. Email two-factor authentication (2FA) requires a second proof of identity, beyond a password, before someone can sign in to a mailbox. The National Institute of Standards and Technology defines three factor types: something you know, something you have, and something you are. Email 2FA combines two of them, usually a password with a possession-based code from an authenticator app, a hardware key, or a phone. It protects account login. It is a separate control from SPF, DKIM, and DMARC, which authenticate outbound mail rather than mailbox access. ## Quick takeaways - [NIST SP 800-63-3](https://pages.nist.gov/800-63-3/sp800-63-3.html) defines three authentication factors: something you know, something you have, and something you are. Multi-factor authentication combines more than one. - [NIST SP 800-63B's](https://pages.nist.gov/800-63-3/sp800-63b.html) AAL2 rule requires either one multi-factor authenticator or a Memorized Secret (password) paired with a separate possession-based authenticator, such as an authenticator app. - NIST states that email "SHALL NOT be used for out-of-band authentication," yet Microsoft still lists an email address as a valid security-info method for its own two-step verification. - CISA calls [FIDO/WebAuthn](https://www.cisa.gov/MFA) passkeys and hardware security keys the only widely available phishing-resistant multi-factor option; SMS and email codes rank weaker. - Email account 2FA protects mailbox login. It does not authenticate outbound mail the way SPF, DKIM, and DMARC do. - Google and Microsoft both let account owners turn on two-step verification from account security settings, using an authenticator app, a passkey, or a text or voice code as the second step. ## How email account 2FA works NIST's authentication guidance describes three kinds of factor: - "Something you know (e.g., a password)" - "Something you have (e.g., an ID badge or a cryptographic key)" - "Something you are (e.g., a fingerprint or other biometric data)" "MFA refers to the use of more than one of the above factors," according to [NIST SP 800-63-3, Section 4.3.1](https://pages.nist.gov/800-63-3/sp800-63-3.html). Email 2FA is a two-factor case of that broader definition: a password (something you know) combined with a second, different factor. That definition has no upper bound, which is why 2FA and MFA are not competing settings. Two factors is the ordinary case for a mailbox, but a password plus an authenticator app code plus a fingerprint is the same control at greater depth, and adding a third factor does not move an account into a different category. What counts is how many of the three factor types are involved, not how many screens a sign-in shows. A password followed by a security question is two steps drawn from the same type, so it is not multi-factor under NIST's definition. Provider labels vary for the same setting. Microsoft calls it two-step verification, Google calls it 2-Step Verification, and CISA notes the option "may be called two-factor authentication, two-step authentication or similar" depending on the service. Read the factor types a provider actually offers rather than the name on the menu, and work from that provider's current documentation, because the enrollment path, the available methods, and the account-recovery process are all provider-specific. ![The three authentication factor categories defined by NIST SP 800-63-3: something you know, something you have, and something you are](/images/editorial/email-2-factor-authentication/email-2-factor-authentication-factors.webp "1200x533") *Source: Palisade.* [NIST SP 800-63B, Section 4.2.1](https://pages.nist.gov/800-63-3/sp800-63b.html) sets the pairing rule at Authenticator Assurance Level 2 (AAL2), the level most personal and business email accounts target: authentication "SHALL use either one multi-factor authenticator or a combination of two single-factor authenticators." When two single-factor authenticators are combined, one "SHALL be a Memorized Secret authenticator" (the password) and the other "SHALL be a possession-based authenticator." Authenticator apps satisfy the possession requirement directly. NIST describes them as "software-based OTP generators installed on devices such as mobile phones," where typing the displayed code proves "possession and control of the device" ([SP 800-63B, Section 5.1.4](https://pages.nist.gov/800-63-3/sp800-63b.html)). A hardware security key or a passkey works the same way, through a cryptographic proof instead of a typed code. ## When the second factor matters more than others Not every second factor carries equal security. NIST's guidance ranks channels by how well they prove someone actually possesses a specific device, and it treats phone-network and email delivery differently: > [NIST SP 800-63B, Section 5.1.3.3](https://pages.nist.gov/800-63-3/sp800-63b.html): "Methods that do not prove possession of a specific device, such as voice-over-IP (VOIP) or email, SHALL NOT be used for out-of-band authentication." SMS and voice codes get a lighter restriction, not a ban: "Use of the PSTN for out-of-band verification is RESTRICTED," and verifiers "SHOULD consider risk indicators such as device swap, SIM change, number porting, or other abnormal behavior." Under NIST's terminology, RESTRICTED means the method carries extra conditions, not that it is prohibited. That distinction matters because provider practice does not always match the guidance. Microsoft's own two-step verification setup lists an email address as a valid security-info method for personal Microsoft accounts, even though NIST advises against email for out-of-band authentication. The decision rule for a reader choosing a second factor: prefer an authenticator app, passkey, or hardware security key over SMS, voice, or email whenever the provider offers one, because those are the factors NIST and CISA both treat as stronger. CISA's own framing supports that ordering: "Users who enable MFA are significantly less likely to get hacked," and "phishing-resistant MFA is the standard all industry leaders should strive for, but any MFA is better than no MFA." CISA adds that "the only widely available phishing-resistant authentication is FIDO/WebAuthn authentication," which covers passkeys and hardware security keys ([CISA, Multi-factor Authentication](https://www.cisa.gov/MFA)). ## Comparing second-factor options The AAL2 pairing rule is the quotable version of the mechanism above: ```text NIST SP 800-63B, Section 4.2.1 (AAL2 pairing rule) Authentication SHALL use either: - one multi-factor authenticator, or - a combination of two single-factor authenticators When two single-factor authenticators are combined, one SHALL be a Memorized Secret (password), and the other SHALL be a possession-based authenticator (for example, an authenticator app or a hardware security key). ``` ![Second-factor options for email account sign-in, ranked from weakest to strongest by NIST's own restrictions and CISA's phishing-resistance guidance](/images/editorial/email-2-factor-authentication/email-2-factor-authentication-records.webp "1200x600") *Source: Palisade.* The ranking follows directly from the sources above: an emailed code is the option NIST says SHALL NOT be used for out-of-band authentication; an SMS or voice code is RESTRICTED and needs extra fraud monitoring; an authenticator app code is a recognized possession-based factor; and a passkey or hardware security key is CISA's only widely available phishing-resistant choice. A provider offering an option does not mean it meets NIST's or CISA's stronger recommendation, and readers choosing between the options Google or Microsoft present should default to the strongest one available on their account. ## Where to turn on 2FA for your email account The exact menu label and path vary by provider, so check the account's own security settings rather than a generic menu name. ### Google accounts In a Google Account, open Security & sign-in, then under "How you sign in to Google" select "Turn on 2-Step Verification" and follow the on-screen steps. Google's second-step options include Google prompts, passkeys, hardware security keys, Google Authenticator or another code app, text or voice call codes, and 8-digit backup codes. After setup, sign-in uses a password plus a second step, or a passkey alone. A phone number added for 2-Step Verification "may take up to 7 days" for Google to trust it fully ([Google Account Help](https://support.google.com/accounts/answer/185839)). ### Microsoft accounts For a personal Microsoft account, go to account.microsoft.com/security, select "Manage how I sign in," then under "Additional security" turn on "Two-step verification." Microsoft describes the control as using "two different forms of identity: your password, and a contact method," so that even if someone finds the password "they'll be stopped if they don't have access to your security info." Microsoft's documentation also lists two real costs: apps and devices that cannot process a security code, such as some mail apps and older consoles, need a generated app password, and resetting a lost password requires two working contact methods on file ([Microsoft Support](https://support.microsoft.com/en-us/account-billing/how-to-use-two-step-verification-with-your-microsoft-account-c7910146-672f-01e9-50a0-93b4585e7eb4)). This guidance covers personal Microsoft accounts, not Microsoft 365 work or school tenants managed by an organization's IT department. ### Any other provider CISA's generic path applies when a provider is not covered above: open the account's settings, then its security settings, then turn on the option, which "may be called two-factor authentication, two-step authentication or similar." CISA recommends turning it on for every account that offers it, and lists email accounts specifically among the accounts worth protecting this way ([CISA, Turn on MFA](https://www.cisa.gov/secure-our-world/turn-mfa)). For a closer look at one provider's specific settings, see [2-factor authentication on Yahoo email](/learning/2-factor-authentication-yahoo-email). Whichever provider runs the mailbox, follow its own current guidance rather than a workflow written for another service or an older screenshot, because a generic answer can send you to a retired setting or an unsupported recovery path. ## Check the email authentication controls a password can't fix Account 2FA stops someone from signing in to a mailbox without the second factor. It does nothing for the messages that mailbox sends. Whether a message from that domain is authenticated in transit is a separate question, answered by SPF, DKIM, and DMARC, not by the account's sign-in settings. [DKIM](/learning/dkim) is one of those controls: it lets a receiving mail system check that a message was authorized by the sending domain and unaltered in transit, which is a domain-level property, not a mailbox-login property. Readers who came here looking for that domain-level protection, rather than account sign-in security, want [email authentication](/learning/dmarc) instead. To check a domain's own authentication posture, run it through the [email security score checker](/tools/email-security-score). That check inspects published DNS records for the domain; it does not check whether any mailbox on that domain has 2FA turned on, which is an account setting, not a DNS record. ## Sources and further reading - [NIST SP 800-63-3: Digital Identity Guidelines](https://pages.nist.gov/800-63-3/sp800-63-3.html) - [NIST SP 800-63B: Authentication and Lifecycle Management](https://pages.nist.gov/800-63-3/sp800-63b.html) - [Google Account Help: Use 2-Step Verification](https://support.google.com/accounts/answer/185839) - [Microsoft Support: Use two-step verification with your Microsoft account](https://support.microsoft.com/en-us/account-billing/how-to-use-two-step-verification-with-your-microsoft-account-c7910146-672f-01e9-50a0-93b4585e7eb4) - [CISA: Turn on multi-factor authentication](https://www.cisa.gov/secure-our-world/turn-mfa) - [CISA: Multi-factor Authentication (MFA)](https://www.cisa.gov/MFA) ## Frequently asked questions ### How do I activate 2FA on my email? Open the account's own settings, then its security settings, and turn on the option, which CISA notes "may be called two-factor authentication, two-step authentication or similar." For Google, go to Security & sign-in and select "Turn on 2-Step Verification." For a personal Microsoft account, go to account.microsoft.com/security, choose "Manage how I sign in," and turn on "Two-step verification" under Additional security. Other providers use the same general path even when the exact menu wording differs. ### Can I use an email for two-factor authentication? No. NIST's guidance states that "methods that do not prove possession of a specific device, such as voice-over-IP (VOIP) or email, SHALL NOT be used for out-of-band authentication." In practice, some providers offer it anyway: Microsoft's own two-step verification lists an email address as a valid security-info method for personal accounts. When a provider offers a choice, an authenticator app, passkey, or hardware security key meets NIST's and CISA's stronger recommendation better than an emailed code does. ### What's the main disadvantage of two-factor authentication? Losing access to every enrolled second factor is the disadvantage most provider documentation calls out directly. Microsoft's own support page notes that resetting a lost password requires two working contact methods on file, and that some apps and older devices cannot process a security code at all, so they need a separately generated app password instead. Not every second factor carries the same resistance to attack either: CISA notes that SMS and email-based codes are weaker than an authenticator app, and that phishing-resistant FIDO/WebAuthn passkeys or hardware keys are the strongest widely available option. ### Where is 2 factor authentication in settings? The exact label and location depend on the provider, but the general path is the account's settings, then its security settings. CISA describes it this way because the option "may be called two-factor authentication, two-step authentication or similar" depending on the service. For Google, it sits under Security & sign-in. For a personal Microsoft account, it sits under Manage how I sign in, in the Additional security section, labeled "Two-step verification". ### Does turning on email account 2FA also fix SPF, DKIM, or DMARC problems? No. Account 2FA protects who can sign in to a mailbox. SPF, DKIM, and DMARC are domain-level controls that let receiving mail systems verify whether an outbound message was actually authorized and unaltered. A domain can have strong account 2FA on every mailbox and still have no DMARC record, or the reverse. Checking one does not check the other. --- # Email authentication for Gmail: SPF, DKIM, and DMARC requirements Canonical: https://www.palisade.email/learning/email-authentication-for-gmail > Email authentication for Gmail requires SPF or DKIM for every sender, and SPF, DKIM, and DMARC together once volume reaches 5,000 messages a day. Email authentication for Gmail means publishing SPF or DKIM for the sending domain, plus DMARC once daily volume to Gmail addresses reaches 5,000 messages. Google made these baseline requirements for every sender starting February 1, 2024. A sender also needs valid forward and reverse DNS, a TLS connection, and correctly formatted messages. Mail that fails can be marked as spam or rejected outright with a 5.7.26 error at the SMTP level. ## Quick takeaways - Every sender to Gmail needs SPF or DKIM (at least one), valid forward and reverse DNS records, a TLS connection, and RFC 5322 message formatting. - Senders of 5,000 or more messages a day to Gmail addresses need SPF and DKIM together, plus a DMARC record with From-header alignment. - A DMARC record published at `p=none` still satisfies Gmail's bulk-sender requirement; enforcement is not mandatory to comply. - Unauthenticated mail can be marked as spam or rejected with a documented 5.7.26 error. - Gmail's Postmaster Tools guidance asks senders to keep spam rate under 0.10 percent and never reach 0.30 percent or higher. - Bulk and marketing mail needs one-click unsubscribe headers, not just a visible unsubscribe link. ## How Gmail checks sender authentication Google's sender requirements page sets a floor that applies to every domain sending to a Gmail or Google Workspace address, [regardless of volume](https://support.google.com/a/answer/81126). At minimum, the sending domain must publish SPF or DKIM, the sending IP or domain must resolve with valid forward and reverse DNS (PTR) records, the connection must use TLS, and messages must follow RFC 5322 formatting. Senders also may not impersonate a Gmail From: header. SPF and DKIM are checked independently during the SMTP transaction and at message evaluation. SPF verifies that the sending IP is authorized for the domain in the return path. DKIM verifies a cryptographic signature tied to the message body and key headers. DMARC then compares the visible From: header domain against the domain that passed SPF or DKIM, a check Google calls alignment, and applies the policy the domain publishes at `_dmarc.<domain>` when [DMARC is configured](https://support.google.com/a/answer/2466580). None of these checks require [DKIM signing](/learning/dkim) alone to satisfy Gmail's baseline; SPF alone is enough at low volume, though pairing both is what bulk sending requires. ## When the requirements change The rules differ by how much mail a domain sends to Gmail addresses in a day, and the difference is not cosmetic: - Below 5,000 messages a day: SPF or DKIM (one is enough), valid PTR records, TLS, and RFC 5322 formatting. - At or above 5,000 messages a day: SPF and DKIM together, a DMARC record at any policy level including `p=none`, and From: header alignment with the SPF or DKIM domain. - Bulk senders sending marketing or subscribed mail also need one-click unsubscribe support via the `List-Unsubscribe` and `List-Unsubscribe-Post: List-Unsubscribe=One-Click` headers, plus a visible unsubscribe link in the body. - Bulk senders are expected to keep spam complaint rate under 0.10 percent in Postmaster Tools and avoid reaching 0.30 percent or higher. The 5,000-message threshold is measured per sending domain across a day, so a domain that occasionally spikes past it should meet the bulk requirements rather than assume it stays under the floor. ![Gmail authentication requirements compared for low-volume and bulk senders](/images/editorial/email-authentication-for-gmail/email-authentication-for-gmail-compare.webp "1200x533") *Source: Palisade.* ## Worked example: what to publish These are illustrative record shapes only. The DKIM public key and DMARC report address are placeholders; a sender publishes its own values from the Google Workspace Admin console and its own reporting mailbox, never a value copied from an example. ```text ; SPF, published as a TXT record at the domain apex yourdomain.com. TXT "v=spf1 include:_spf.google.com ~all" ; DKIM, published at the selector Google Workspace generates selector._domainkey.yourdomain.com. TXT "v=DKIM1; k=rsa; p=<public-key>" ; DMARC, published at the fixed _dmarc host _dmarc.yourdomain.com. TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com" ``` Do not publish this exact text. Google generates the SPF include mechanism, DKIM selector, and public key per domain, and [SPF records support at most 10 include mechanisms and can take up to 48 hours to start working](https://support.google.com/a/answer/33786). Google [recommends 2048-bit DKIM keys](https://support.google.com/a/answer/174124), generated by a super administrator in the Admin console, with new sending domains waiting 24 to 72 hours after Gmail is enabled and up to 48 hours for the DNS record to propagate before signing is verified. DKIM cannot be self-tested; verification requires sending to an external Gmail or Workspace mailbox and inspecting that message's headers. For DMARC, Google advises waiting 48 hours after SPF and DKIM are working before publishing the record, then moving from `p=none` toward `p=quarantine` and `p=reject` as [aggregate reports confirm every legitimate source is aligned](https://support.google.com/a/answer/2466580). Alignment can be strict or relaxed, set with the `aspf` and `adkim` tags, and staged rollout is handled by escalating the policy from `none` to `quarantine` to `reject`, since [RFC 9989 retired the `pct` tag](/learning/what-is-dmarcbis-rfc-9989-dmarc-standard). ## Diagnose an authentication failure Work from what you already have rather than guessing at the cause: - Start with a delivered message's raw headers. The `Authentication-Results` header shows the actual SPF, DKIM, and DMARC result Gmail applied to that specific message, which a DNS lookup alone cannot show. - Check the current published records for the sending domain. A record that looks correct in documentation can differ from what DNS is actually serving right now. - If the bounce includes a 5.7.26 error, that is Google's [documented response for messages that fail the required authentication](https://support.google.com/a/answer/81126), not a generic block. - If DKIM was just enabled, confirm the propagation window has passed (24 to 72 hours for new Workspace tenants, up to 48 hours for the DNS record itself) before troubleshooting further. - If the domain is near or over 5,000 messages a day to Gmail addresses, confirm DMARC is published; a domain running only SPF or DKIM at that volume does not meet the bulk requirement even if individual messages pass. Two related issues are common enough to check directly: a [Gmail block that specifically cites an unauthenticated sender](/email-deliverability/gmail-blocked-sender-is-unauthenticated), and [legitimate mail from a new domain landing in spam](/email-deliverability/why-does-gmail-mark-new-domain-emails-as-spam) even when authentication passes, which points to reputation rather than a missing record. ## Check the current state of your records Run the sending domain through Palisade's email security score to see whether SPF, DKIM, and DMARC are currently published and what they evaluate to right now. [Check your email security score](/tools/email-security-score) A DNS-based check confirms what is published today. It cannot confirm that a specific application is signing outgoing mail with the configured key, that every sending source for the domain is inventoried, or that Gmail's spam-rate or reputation signals are currently favorable. Those require message-header evidence and Postmaster Tools data respectively. ## Sources and further reading - [Google: Email sender guidelines](https://support.google.com/a/answer/81126) - [Google: Set up SPF for Google Workspace](https://support.google.com/a/answer/33786) - [Google: Turn on DKIM for outbound mail](https://support.google.com/a/answer/174124) - [Google: Prevent spoofing with DMARC](https://support.google.com/a/answer/2466580) - [Foundational email authentication concepts](/learning/dmarc) ## Frequently asked questions ### How do I authenticate my email on Gmail? You do not authenticate mail inside Gmail itself; you publish records at the sending domain's DNS. Set up SPF or DKIM at minimum, per [Google's sender guidelines](https://support.google.com/a/answer/81126), and add DKIM plus a DMARC record if the domain sends 5,000 or more messages a day to Gmail addresses. If the domain sends through Google Workspace, the SPF include and DKIM key are configured in the Admin console before the DNS record is published. ### Is there an authenticator for Gmail? Not in the sender-authentication sense this article covers. SPF, DKIM, and DMARC authenticate a domain's outgoing mail, not a person signing in. If the question is about securing a Gmail account at login, that is Google Account 2-Step Verification, a separate account-security feature from the DNS-based sender authentication described here. ### How to fix email authentication failed Gmail? Start with the delivered message's raw headers and read the `Authentication-Results` line to see which check, SPF, DKIM, or DMARC, actually failed and why. A bounce citing a 5.7.26 error means the message did not meet [Gmail's minimum authentication requirement](https://support.google.com/a/answer/81126). Confirm the domain publishes at least SPF or DKIM, and both plus DMARC if it sends in bulk, then recheck after any DNS propagation window has passed. ### How do I turn on authentication in Gmail? For sending mail, authentication is enabled by publishing SPF, DKIM, and DMARC records at the domain's DNS, not through a Gmail setting. DKIM specifically is turned on in the Google Workspace Admin console: a super administrator generates the key, publishes the resulting TXT record, then enables signing, waiting up to 48 hours for DNS and up to 72 hours for a new tenant before it takes effect. ### What spam rate does Gmail expect from bulk senders? Gmail's Postmaster Tools guidance asks senders to keep their spam complaint rate under 0.10 percent and treat 0.30 percent or higher as a threshold that risks delivery problems, according to [Google's sender guidelines](https://support.google.com/a/answer/81126). This applies alongside the SPF, DKIM, and DMARC requirements, not instead of them. ### Do I need DMARC if I send fewer than 5,000 messages a day to Gmail? No, not to meet Google's minimum requirement. Below the 5,000-message-a-day threshold, SPF or DKIM alone satisfies Gmail's baseline. DMARC becomes mandatory only once a domain reaches that bulk-sender volume, though publishing it at `p=none` earlier is a low-risk way to start collecting aggregate reports. --- # What is a DNS changer? Speed, privacy and security Canonical: https://www.palisade.email/learning/how-does-a-dns-changer-affect-your-internet > What is a DNS changer? It switches the DNS resolver your device uses, which can affect lookup speed, query privacy, and DNS filtering in practice. A DNS changer is a setting or app that changes the DNS resolver your device asks to translate domain names into IP addresses. It can affect DNS lookup speed, who receives your DNS queries, and whether the resolver applies domain filtering. It does not increase internet bandwidth, encrypt all internet traffic, or change your public IP address. Those are separate network functions. ## Quick takeaways - A DNS changer switches the resolver used for domain-name lookups. - Faster DNS can shorten some initial lookups, but it cannot increase download bandwidth. - Changing resolvers moves DNS-query handling from the default resolver to the chosen provider. - DNS-over-TLS and DNS-over-HTTPS can encrypt DNS traffic between a device and its resolver. - Router-level DNS settings can affect many devices, while device-level settings affect only that device. - A DNS change needs a same-device test and a documented rollback path. ## How a DNS changer works DNS is the protocol that maps computer names to IP addresses, so a device can find the server behind a name such as `www.example.com`. [Microsoft's DNS overview](https://learn.microsoft.com/en-us/windows-server/networking/dns/dns-overview) describes DNS as the name-resolution service that maps computer names to IP addresses. A device normally has one or more DNS resolvers configured through its network connection. A DNS changer replaces those configured resolver addresses or configures an encrypted DNS endpoint. The next time the device needs an answer that is not already cached, its DNS client sends the query to the new resolver. The resolver's answer can affect what happens before a connection begins: - A nearby or well-performing resolver may return an answer faster than the current resolver for a particular query. - A resolver with a filtering policy may return a blocked response for domains in that policy. - A resolver with a different privacy policy receives the query instead of the default resolver. - An encrypted DNS connection can protect the query between the device and the selected resolver. The change does not alter the website's server, the internet connection's raw capacity, or the destination connection after the name has been resolved. DNS is an early part of reaching a service, not the whole service path. ![DNS changer flow showing a device sending a DNS query to its selected resolver, then using the returned IP address to connect to a website](/images/editorial/how-does-a-dns-changer-affect-your-internet/how-does-a-dns-changer-affect-your-internet-dns-resolution-flow.webp "1200x676") *Source: Palisade.* ## When a DNS change affects speed, privacy, or security A DNS changer may improve perceived speed when DNS lookup delay is part of the delay a person notices. That result varies by network, resolver location, caching, the domain queried, and the application's connection behavior. A cached DNS answer may mean there is no new resolver query to compare. A faster resolver answer also cannot make a slow web server, congested Wi-Fi connection, or large download faster. Privacy changes because the chosen resolver processes DNS queries. [Cloudflare's public-resolver documentation](https://developers.cloudflare.com/1.1.1.1/privacy/public-dns-resolver/) notes that most devices use an ISP-provided resolver by default and that some ISPs and third-party DNS providers log queries, sell activity data, or use it for advertising. That is a provider-specific policy question, so review the selected resolver's current privacy documentation before deployment. A DNS change can protect queries in transit only if the device and resolver use an encrypted DNS protocol. [Cloudflare's DNS-over-TLS documentation](https://developers.cloudflare.com/1.1.1.1/encryption/dns-over-tls/) explains that DNS-over-TLS wraps DNS traffic in a TLS-encrypted TCP connection, which prevents parties between the device and resolver from reading or modifying those DNS queries. Encryption of DNS queries does not encrypt the rest of the web connection or conceal the destination from every other party involved in the connection. Security changes only when the selected resolver offers and applies a relevant control. For example, Cloudflare documents that its standard 1.1.1.1 resolver does not filter content, while its 1.1.1.1 for Families service blocks malware and adult content according to the selected service policy. A filtered DNS response can stop a device from resolving a listed domain, but it cannot clean an infected endpoint, inspect every threat, or replace endpoint security controls. Use this decision rule: - Choose a device-level DNS change when testing one device or when only that device needs a different resolver. - Choose a router-level DNS change only when the network owner intends the resolver choice to apply to connected devices and has tested a rollback. - Use encrypted DNS when the operating system, browser, or managed-device policy supports it and the chosen resolver documents the endpoint. - Do not treat a DNS change as a substitute for a VPN when the requirement is encrypted traffic routing or a different public IP address. For broader controls that protect email domains, see the [email security learning center](/learning). DNS is also central to email authentication, but a consumer DNS-resolver change does not alter a domain's published DMARC, SPF, or DKIM records. ## Worked example: verify what changed The useful evidence is the resolver answer from the same device after the change. On systems with `nslookup`, query a known domain against the intended resolver address. ```text nslookup example.com 1.1.1.1 ``` This is an illustrative query. Replace `1.1.1.1` only with the resolver address published by the provider you have approved. A successful response shows that the command received an answer from the resolver address specified in the command. It does not prove that every application on the device uses that resolver. Browsers, operating systems, VPN clients, security software, and managed-device profiles can have separate DNS settings. Check these details after changing DNS: - Confirm the configured resolver address in the device or router settings. - Run a lookup from the device that will use the setting. - Test the business applications and internal names that matter on that network. - Record the old setting before rollout, then keep a tested rollback procedure. - If the resolver blocks a domain unexpectedly, confirm the provider's filtering policy before bypassing or removing the control. > A router DNS change can break internal-name resolution, captive portals, or services that depend on a managed resolver. Test a single device first when the network also uses private DNS zones. A public lookup can also help inspect the DNS record a domain publishes. Use the [Palisade DNS lookup tool](/tools/dns-lookup) when you have a domain name and need to inspect its public DNS response. That result is useful for a public record check, but it does not prove which resolver a device actually used, whether a private DNS zone overrides the answer, or whether an application received the same response. ## What to do next with the evidence you have If you have only a domain name, inspect its public DNS response and compare it with the expected record. If you are changing a local resolver, first test the new setting on one device, then retest the exact applications and internal hostnames used on that network. If your concern is suspicious email that appears to use your domain, a device's DNS changer is not the control to investigate. Start with [whether DMARC is an email security game-changer](/learning/is-dmarc-the-email-game-changer) and examine the domain's published authentication records and message evidence separately. ## Check the public DNS response for a domain Use a DNS lookup when you need to inspect the public record that a domain publishes before comparing it with the expected DNS change. [Inspect a public DNS record](/tools/dns-lookup) A public DNS lookup cannot prove which resolver a specific device used, reveal private split-horizon DNS, or show the security and privacy policy applied by that resolver. ## Sources and further reading - [Microsoft: What is Domain Name System (DNS)?](https://learn.microsoft.com/en-us/windows-server/networking/dns/dns-overview) - [Cloudflare: 1.1.1.1 public DNS resolver privacy documentation](https://developers.cloudflare.com/1.1.1.1/privacy/public-dns-resolver/) - [Cloudflare: DNS over TLS](https://developers.cloudflare.com/1.1.1.1/encryption/dns-over-tls/) - [Palisade DNS lookup tool](/tools/dns-lookup) ## Frequently asked questions ### Does changing DNS make the internet faster? Yes, sometimes. A different resolver may answer uncached DNS queries faster, which can reduce the delay before a connection starts. It does not increase the internet connection's bandwidth or make every website respond faster. ### Does a DNS changer hide my IP address? No. A DNS changer changes the resolver used for name lookups. It does not route all traffic through another network or replace the public IP address visible to a destination service. ### Does encrypted DNS encrypt website traffic? No. DNS-over-TLS or DNS-over-HTTPS encrypts DNS queries between the device and the resolver. Website traffic needs its own transport protection, such as HTTPS, and other network metadata can still remain visible to relevant parties. ### Can changing router DNS affect every device? Yes. Devices that receive DNS settings from that router may use the configured resolver. A device can still use a separate DNS configuration, encrypted-DNS setting, VPN client, or managed profile, so test representative devices. ### Can a DNS filter stop malware? Only partly. A DNS filter can block resolution of domains included in its policy. It cannot remove malware already on a device, detect every threat, or replace endpoint security and incident-response work. --- # How does Palisade handle DMARC for inbound emails? Canonical: https://www.palisade.email/learning/how-does-palisade-handle-dmarc-for-inbound-emails > Palisade supports domain monitoring and email authentication management, but its public docs do not document inbound DMARC filtering or enforcement. Palisade's public documentation covers domain monitoring, DMARC, SPF, and DKIM management, plus Hosted MTA-STS for inbound TLS. It does not publicly document an inbound-DMARC filtering or enforcement feature, including default delivery actions, exception lists, gateway controls, or message-level anti-spoofing decisions. DMARC can guide a receiving system's handling of a failed message, but that receiver-side function is separate from the documented Palisade scope. ## Quick takeaways - Palisade publicly documents monitoring and management for DMARC, SPF, and DKIM. - Palisade also documents Hosted MTA-STS, which concerns TLS protection for inbound SMTP connections. - RFC 9989 defines DMARC as a way for a domain owner to publish requested handling for messages that fail DMARC evaluation. - The receiving mail system makes the final disposition decision for a failed message. - Public DNS can show a domain's DMARC record, but it cannot show a receiver's private filtering decision. - Palisade's published documentation does not establish that it filters inbound messages or enforces another sender's DMARC policy. ## How inbound DMARC works at a receiving mail system [DMARC](https://www.rfc-editor.org/rfc/rfc9989.html) evaluates whether SPF or DKIM passes with an identifier aligned to the domain in the visible `From` field. If DMARC fails, the sender domain's published policy can request `none`, `quarantine`, or `reject`. That request is not a universal delivery command. RFC 9989 leaves the final handling decision with the receiving system, which can apply its own local policies and mail-flow context. A domain publishing `p=reject` therefore does not prove that every receiver will reject every failed message. Palisade's [DMARC learning hub](/learning/dmarc) explains the domain-owner side of this process: publishing a policy, discovering legitimate sending sources, and validating authentication alignment. Palisade's public documentation describes domain monitoring and management of DMARC, SPF, and DKIM. It also documents Hosted MTA-STS for inbound TLS, which helps a sending system validate the receiving domain's TLS requirements during SMTP delivery. Those documented functions do not establish an inbound mailbox filtering or DMARC-enforcement function. ![Boundary diagram separating sender-domain DMARC monitoring and management from receiver-side message evaluation and final delivery handling](/images/editorial/how-does-palisade-handle-dmarc-for-inbound-emails/how-does-palisade-handle-dmarc-for-inbound-emails-inbound-dmarc-boundary.webp "1200x906") *Source: Palisade.* ## When the answer changes The answer changes only when a current public product source documents a specific inbound-mail capability. Without that evidence, do not assume that a product which monitors your domains also receives messages for your users, applies another domain's DMARC policy, quarantines messages, or maintains inbound exceptions. Use this decision rule: - If you need to know what your own domain publishes, inspect its DNS DMARC record. - If you need to know whether your production mail passes DMARC, inspect a delivered message from the exact sending path and review DMARC aggregate reports after they accumulate. - If you need to know why a received message was accepted, rejected, quarantined, or routed, use evidence from the receiving mail system or security gateway that made that decision. - If you need to manage your outbound domain posture over time, Palisade's documented monitoring and remediation workflow is the relevant product scope. This distinction matters when investigating a suspected spoof. A public DMARC lookup can reveal the sender domain's policy request. It cannot reveal whether the recipient's mailbox provider treated one message as suspicious, whether a gateway made an exception, or whether a user received the message in a particular folder. For more detail on the feedback data that supports a domain-owner investigation, see [whether DMARC failure reports are worth the trouble](/learning/what-exactly-is-a-dmarc-failure-report-and-why-should-you-care). ## A worked inbound-DMARC evidence boundary Consider a message that claims to be from `billing@yourdomain.com`. A receiving system evaluates the message's authentication and alignment, then decides what to do with the result. The domain's DNS policy is only one input to that receiver-side decision. ```text Visible From domain: yourdomain.com SPF result: fail DKIM result: fail DMARC result: fail Published DMARC policy: p=reject Receiver-side result: determined by the receiving mail system ``` This is an illustrative evidence object, not a record from a live domain. The first five lines describe evidence that DMARC evaluation can use. The final line cannot be filled in from public DNS alone. Under [RFC 9989's DMARC policy model](https://www.rfc-editor.org/rfc/rfc9989.html), `p=reject` is the domain owner's requested handling for DMARC failures. It does not disclose a particular receiver's final action. Hosted MTA-STS addresses a different inbound-email question. It lets a receiving domain publish TLS requirements for SMTP delivery to its mail exchangers. It does not evaluate the visible `From` domain, determine DMARC alignment, or decide whether an inbound message is spoofed. Keep transport protection and message authentication separate when reviewing email security controls. ## What to check next Start with the evidence you actually have. - If you have a domain name and need to inspect its published DMARC policy, use the [Palisade DMARC checker](/tools/dmarc). Compare the result with the intended DNS change record. - If you have a suspicious received message, obtain its raw headers and use the mailbox provider or gateway that received it to determine the actual disposition. A public record lookup is not a substitute for that receiver-side evidence. - If you operate the sending domain, validate DNS through the authoritative server and a public resolver, then send a real message through the production path. Check its authentication results and review aggregate reports after data accumulates. - If you are assessing inbound TLS, confirm the receiving domain's MTA-STS policy and test the SMTP path separately from DMARC. For an ongoing view of your own sending domains, [Palisade's DMARC monitoring approach](/learning/howcanpalisadedmarcmonitoringprotectemaildeliverability) focuses on aggregate-report data, identified sending sources, and authentication or alignment issues. That evidence helps a team decide when a domain is ready for a stronger published policy. ## Investigate the documented domain-monitoring gap A DMARC record lookup can show what a domain publishes today, but it cannot inventory every production sender that uses the domain or show which sources still fail alignment. Palisade is agentic DMARC software that analyzes aggregate-report data, identifies sending sources and authentication or alignment issues, and proposes remediation work for human review. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=existing_content_migration&utm_content=how-does-palisade-handle-dmarc-for-inbound-emails) Palisade does not, based on its published documentation, act as an inbound DMARC filter, control a receiving system's private disposition decision, or guarantee that future messages will authenticate. ## Sources and further reading - [Palisade documentation](https://docs.palisade.email/) - [RFC 9989: Domain-based Message Authentication, Reporting, and Conformance](https://www.rfc-editor.org/rfc/rfc9989.html) - [Palisade DMARC checker](/tools/dmarc) ## Frequently asked questions ### Does Palisade publicly document inbound DMARC enforcement? No. Palisade's public documentation covers domain monitoring, email-authentication management, and Hosted MTA-STS for inbound TLS. It does not publicly document inbound-DMARC enforcement, message filtering, or default delivery actions. ### Does `p=reject` guarantee that a spoofed email is rejected? No. `p=reject` requests rejection after DMARC failure. The receiving mail system makes the final disposition decision and can apply local policy. ### Can a DMARC checker explain why a received email reached an inbox? No. A checker can inspect the sender domain's public DNS record. It cannot see the raw message, the recipient's gateway configuration, or the receiving system's private filtering decision. ### Is Hosted MTA-STS the same as inbound DMARC filtering? No. Hosted MTA-STS concerns TLS requirements for SMTP delivery to a receiving domain's mail exchangers. DMARC evaluates authorization and alignment for the visible `From` domain. ### What evidence proves a production sending path passes DMARC? Only a real delivered message from that exact production path can show its message-level authentication results. DNS confirmation and a vendor status indicator are useful separate checks, while aggregate reports provide broader DMARC evidence after data accumulates. --- # Mimecast email security: what it does and what it cannot prove Canonical: https://www.palisade.email/learning/mimecast-email-security > Mimecast email security is a vendor email-security offering, but its name alone cannot prove a specific email is safe, encrypted, or legitimate. Mimecast email security is Mimecast's email-security product area. Mimecast describes email security as where it started and identifies "Email Threat Protection" as a capability area. That does not mean an email associated with Mimecast is automatically safe, legitimate, or encrypted. Those questions require evidence from the specific message, its sender context, and the receiving organization's security records. ## Quick takeaways - Mimecast describes email security as a core part of its platform. - Mimecast labels an email-related capability area "Email Threat Protection." - A sender name, logo, or claimed association with Mimecast is not message-level safety evidence. - An individual email needs its own headers, sender context, and recipient-side security evidence. - The available Mimecast material does not establish whether a particular message is encrypted. - An organization-level security score cannot verify one received email. ## How Mimecast email security fits into an email-security program [Mimecast's homepage](https://mimecast.com) describes email security as a long-running part of its platform and states: "Email security is where we started. It's still where we lead, backed by decades of threat intelligence and trusted by 42,000+ organizations." The same site labels an email-related solution area "Email Threat Protection." That establishes Mimecast as a vendor with an email-security offering. It does not establish the precise behavior of a particular control, the policy configured in a customer's tenant, or the result for one message. Those details depend on the relevant product documentation and the organization's own configuration. Mimecast's [Support Center](https://mimecastsupport.zendesk.com) presents its Knowledge Hub as an administrator resource with technical articles and how-to videos. Its current update categories include "Email Security - API-Based Protection," "URL Protection - Real-Time Scan Details Verdict Reporting," "Advanced BEC," and "Email Security MX." These category names show that the vendor maintains multiple email-security product areas. They do not, by themselves, document how each control evaluates mail or which controls protect a given recipient. Email security also extends beyond one vendor product. An email-security program may include domain authentication, recipient-side controls, user reporting procedures, and incident investigation. For that broader context, see Palisade's [email security guide](/learning/threats) and the [email threats hub](/learning/threats). ![Decision flow showing that a Mimecast association alone cannot establish an individual email's safety, and that message-specific evidence is required](/images/editorial/mimecast-email-security/mimecast-email-security-message-evidence-flow.webp "1200x676") *Source: Palisade.* ## When a Mimecast association changes the answer The useful decision rule is narrow: an email can be assessed only from evidence about that email and its delivery path. A claim that the email is "from Mimecast," a Mimecast-branded footer, or a sender's statement does not provide that evidence on its own. The answer changes when you can examine message-specific records, such as: - The full message headers from the received message. - The exact sender domain and the reason the sender contacted the recipient. - Recipient-side security logs or a documented verdict for that message. - Official Mimecast documentation that applies to the observed product feature or status. This distinction matters because email-security systems are configured and operated per organization. A vendor's public description can explain its product area, but it cannot reveal what a recipient's tenant did with a particular message. > Do not treat a familiar vendor name as approval to open links, share credentials, or bypass your organization's reporting process. Preserve the message and use the recipient-side investigation process when it appears suspicious. If the question is about a business's overall controls rather than a single received email, use practical measures such as the ones in [email security best practices for businesses](/learning/what-are-the-top-email-security-tips-for-small-businesses). If the question is about another vendor's product category, [Abnormal email security](/learning/abnormal-email-security) provides a separate vendor-context explanation. ## Worked decision rule for a received email Use the following evidence object before deciding what an apparent Mimecast email means: ```text Claim: "This email is safe because it is from Mimecast." Available evidence: - Sender display name: insufficient - Mimecast branding or footer: insufficient - Vendor public product page: insufficient for this message - Full received headers: message-specific evidence - Recipient-side security logs: message-specific evidence - Documented verdict for the exact message: message-specific evidence Decision: Do not classify the email as safe, malicious, legitimate, or encrypted until message-specific evidence supports that conclusion. ``` The same rule applies to encryption. The available public material for this article does not state whether a particular Mimecast email is encrypted in transit, at rest, or through a secure-message workflow. It also does not establish which conditions or product options would apply. Treat encryption as unverified until the message evidence and the applicable official documentation support a conclusion. Likewise, do not try to rank a "most hacked email provider" from a vague phrase. That phrase has no defined measurement in the available primary material. A useful security review starts with the organization's actual exposure, controls, and observed incidents instead of an unsupported provider ranking. ## Check the evidence you actually have Start with the type of evidence in hand. If you have a suspicious received message, preserve it and review the full headers and recipient-side security records through your organization's established process. Do not rely on public vendor descriptions to classify the message. If you administer the domain or email environment, use Palisade's [Email Security Score](/tools/email-security-score) to inspect the organization's public-facing email-security posture. It is an organization-level check, not an individual-message verdict. Compare its result with your DNS configuration, then validate the real sending path with delivered-message evidence and any relevant administrative records. If the question is which Mimecast control handled a message, consult the applicable Mimecast Knowledge Hub article or administrator records for that tenant. The public update categories are not a substitute for the product-specific documentation and logs needed to explain one result. ## Review your broader email-security posture A vendor association cannot establish whether one email is safe. If your task is to assess the domain's broader public email-security posture, start with the evidence a public check can inspect. [Check your email security posture](/tools/email-security-score) A public posture check cannot prove that an individual email was legitimate, identify a recipient-side Mimecast verdict, confirm encryption, or predict future message placement. ## Sources and further reading - [Mimecast homepage](https://mimecast.com) - [Mimecast Support Center](https://mimecastsupport.zendesk.com) - [Palisade email security guide](/learning/threats) - [Palisade Email Security Score](/tools/email-security-score) ## Frequently asked questions ### Is an email from Mimecast safe? Not necessarily. Mimecast's public material establishes that it provides email-security products, but it does not establish the safety of an individual email. Review the specific message's headers, sender context, and recipient-side security evidence before classifying it. ### What is Mimecast for email security? Mimecast describes email security as a core part of its platform and identifies "Email Threat Protection" as an email-related capability area on its [homepage](https://mimecast.com). Its [Support Center](https://mimecastsupport.zendesk.com) also lists maintained email-security product areas, but the precise behavior of each control requires the applicable product documentation. ### What is the most hacked email provider? Not verified. No authoritative measurement or definition in the available primary material identifies a provider as the "most hacked." Assess the controls and evidence relevant to your own email environment instead. ### Are Mimecast emails encrypted? Not verified. The available Mimecast material does not establish whether a specific email is encrypted, what type of encryption applies, or under which conditions. Confirm that question with message-specific evidence and the applicable official Mimecast encryption or secure-messaging documentation. ### Can an Email Security Score check a received Mimecast message? No. An [Email Security Score](/tools/email-security-score) assesses an organization's public-facing email-security posture. It cannot verify an individual message's sender, Mimecast verdict, encryption state, or recipient-side handling. --- # Phishing attack protection: the controls that actually work Canonical: https://www.palisade.email/learning/phishing-attack-protection > Phishing attack protection combines phishing-resistant MFA, DMARC enforcement, user training, and reporting; no single control stops every attempt. Phishing attack protection is layered: no single control stops every attempt. The Cybersecurity and Infrastructure Security Agency (CISA), the NSA, the FBI, and MS-ISAC recommend phishing-resistant multi-factor authentication, DMARC enforcement on outbound mail, user training to recognize the message indicators below, and a defined reporting path. Individually each control has known gaps; together they cut off the credential theft and malware delivery that phishing exists to enable. ## Quick takeaways - Phishing splits into two attacker goals: stealing credentials for network access, and delivering malware for follow-on activity, according to the joint CISA, NSA, FBI, and MS-ISAC phishing guide. - Phishing-resistant MFA (FIDO or PKI-based) is the strongest single control; SMS, voice, and push notifications without number matching remain phishable. - DMARC set to reject blocks exact-domain spoofing before delivery, but RFC 9989 states it does not stop visually similar lookalike domains or display-name spoofing. - Spam filters catch many phishing emails but not all of them, according to the FTC, so filtering alone is not sufficient protection. - CISA lists five common indicators of a phishing attempt: a mismatched sender address, a generic greeting, a spoofed hyperlink, spelling or layout errors, and an unexpected attachment. - Individuals and organizations report phishing through different channels: individuals forward messages to reportphishing@apwg.org, while organizations use report@cisa.gov or the FBI's Internet Crime Complaint Center. ## How a phishing attack works CISA defines phishing as a form of social engineering in which attacks "use email or malicious websites to solicit personal information by posing as a trustworthy organization," such as a fake message from a credit card company claiming there is a problem with an account, per [CISA's guidance on avoiding social engineering and phishing attacks](https://www.cisa.gov/news-events/news/avoiding-social-engineering-and-phishing-attacks). The message borrows a trusted identity to get the recipient to act before checking. Behind that identity theft, attackers work toward one of two goals. The joint phishing guidance published by CISA with the NSA, FBI, and MS-ISAC splits phishing into credential theft, used to gain initial access to a network, and malware delivery, used for follow-on activity once a device is compromised, per the [CISA phishing guidance on stopping the attack cycle](https://www.cisa.gov/resources-tools/resources/phishing-guidance-stopping-attack-cycle-phase-one). Which goal a message is working toward changes which control actually stops it. Phishing sits alongside a wider set of manipulation techniques covered on the [email threats and impersonation hub](/learning/threats), and it shares tactics with the broader category described in [the most common social engineering attacks](/learning/phishing-attack-protection). ## When the recommended control changes The right control depends on which part of the phishing attack you are positioned to stop: the message itself, the sign-in it targets, the domain it spoofs, or the file it delivers. ![Decision flow showing which phishing control applies depending on whether the reader is an individual recipient, an account administrator, a domain owner, or an endpoint administrator](/images/editorial/phishing-attack-protection/phishing-attack-protection-decision-flow.webp "1200x829") *Source: Palisade.* For individuals, CISA's small-business guidance states that activating strong MFA "is the best way that small businesses can protect their internet facing business accounts from phishing related threats," paired with annual phishing awareness training, DNS filtering, anti-virus software, and automatic software updates. Not all MFA is equal, though. The same guide calls FIDO and PKI-based MFA "phishing resistant," while flagging SMS or voice codes, which can be intercepted or phished through a fake login portal, and push notifications without number matching, which users sometimes approve out of fatigue. For domain owners, the guide's credential-protection mitigations include enabling DMARC on received email, monitoring internal mail against a traffic baseline, and hardening credentials, alongside setting DMARC to reject on the mail the organization sends. On the reject setting, spoofed messages using that domain are "rejected at the mail server prior to delivery," and DMARC reports notify the domain owner when someone is forging it. Section 2.2 of the DMARC specification is explicit about the boundary of that protection: DMARC "is designed to prevent the unauthorized use of the Author Domain of an email message, a technique known as 'spoofing'," but it "can only be used to combat specific forms of exact-domain spoofing directly" and "does not address the use of visually similar domain names or abuse of the RFC5322.From human-readable display name," per [RFC 9989 Section 2.2 on DMARC's anti-phishing scope](https://www.rfc-editor.org/rfc/rfc9989.html#section-2.2). A domain publishing DMARC enforcement has closed one phishing avenue, not the whole category. For endpoint and mail-gateway administrators, the malware-delivery side of the same guide recommends denylists at the email gateway, blocking file extensions such as .scr, .exe, .pif, and .cpl, restricting administrator rights, using application allowlists, and blocking macros by default. ## Worked example: what to check in a suspicious message CISA's five indicators of a phishing attempt give a fast, repeatable check before opening anything: CISA's phishing-attempt indicators; any one is reason to slow down: - Sender's address does not match the claimed organization. - Generic greeting with no specific signature. - Hyperlink text does not match its actual destination. - Spelling or layout errors in the message. - An attachment you were not expecting. > Do not click an "unsubscribe" link in a message you suspect is phishing. CISA's Recognize, Resist, Delete guidance treats that link as part of the same attack, not a way to opt out of it, and notes that AI-written phishing can now read with correct grammar and spelling, so a clean-looking message is not proof of legitimacy, per [CISA's Recognize, Resist, Delete guidance](https://www.cisa.gov/secure-our-world/recognize-and-report-phishing). A domain owner's enforcement side of the same problem is a DNS record, not a checklist: ```text v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourdomain.com ``` This is an illustrative shape, not a record to publish as-is; the `p=reject` tag is what triggers the mail-server rejection behavior described above, and `rua` is where aggregate reports about attempted spoofing are delivered. ## What to do next, based on where you are ### If you have not clicked anything yet Forward the suspicious email to reportphishing@apwg.org, or forward a phishing text to SPAM (7726). File a report at ReportFraud.ftc.gov, per the [FTC's guidance on how to recognize and avoid phishing scams](https://consumer.ftc.gov/articles/how-recognize-and-avoid-phishing-scams). Organizations should report to CISA at report@cisa.gov or the 24/7 line at (888) 282-0870, or file with the FBI's Internet Crime Complaint Center, per the CISA phishing guidance cited above. Then delete the message without clicking any link inside it. ### If you already entered credentials or opened a file Change the password on that account immediately and check for sign-ins you do not recognize. If you gave a scammer personal information such as a Social Security number or financial details, the FTC directs recovery through IdentityTheft.gov. Report the message through the same channels listed above either way, since the report also helps the platform or domain owner respond. Filtering will not catch everything before it reaches this point. The FTC is explicit that spam filters keep out many phishing emails, "But scammers are always trying to outsmart spam filters, so extra layers of protection can help." That is the case for training, phishing-resistant MFA, and DMARC enforcement together, rather than any one of them alone. Microsoft 365 mailboxes get a related layer by default: spoof intelligence and anti-phishing policies, an option to honor a sender's own DMARC policy, and implicit authentication that adds sender reputation and behavioral signals to SPF, DKIM, and DMARC, per [Microsoft's anti-phishing protection documentation for Microsoft 365](https://learn.microsoft.com/en-us/defender-office-365/anti-phishing-protection-about). Defender for Office 365 adds impersonation protection, Campaign Views, and attack simulation training on top of that baseline. ## Check what your domain currently exposes DMARC enforcement stops spoofed messages that use your exact sending domain, but it says nothing about your broader authentication posture, such as whether legitimate senders are aligned or whether your MX and DNS configuration have other gaps a phishing-style spoofing attempt could exploit. Run the domain through Palisade's email security score to see the current authentication and DNS posture before deciding what to fix first. [Check your domain's email security score](/tools/email-security-score) A domain score does not train a user to recognize the indicators above, catch a lookalike domain your organization does not own, or stop a message after someone has already clicked it. Those depend on the training, reporting, and endpoint controls covered above, tied together as an ongoing program rather than a one-time check, as covered in [building an email security program](/learning/threats). For a wider comparison of vendor tools that filter or flag phishing before it reaches a mailbox, see [how to compare anti-phishing software](/learning/anti-phishing-software). ## Sources and further reading - [CISA: Avoiding social engineering and phishing attacks](https://www.cisa.gov/news-events/news/avoiding-social-engineering-and-phishing-attacks) - [CISA, NSA, FBI, MS-ISAC: Phishing guidance, stopping the attack cycle](https://www.cisa.gov/resources-tools/resources/phishing-guidance-stopping-attack-cycle-phase-one) - [CISA: Recognize, Resist, Delete (Secure Our World)](https://www.cisa.gov/secure-our-world/recognize-and-report-phishing) - [FTC: How to recognize and avoid phishing scams](https://consumer.ftc.gov/articles/how-recognize-and-avoid-phishing-scams) - [Microsoft: Anti-phishing protection in Microsoft 365](https://learn.microsoft.com/en-us/defender-office-365/anti-phishing-protection-about) - [RFC 9989: Domain-based Message Authentication, Reporting, and Conformance (DMARC)](https://www.rfc-editor.org/rfc/rfc9989.html) ## Frequently asked questions ### What is the best way to protect against a phishing attack? For individuals and small businesses, CISA's joint guidance with the NSA, FBI, and MS-ISAC states that activating strong MFA "is the best way that small businesses can protect their internet facing business accounts from phishing related threats," combined with annual training, DNS filtering, endpoint protection, and automatic software updates. For organizations that own a sending domain, add DMARC set to reject on outbound mail, since that stops spoofed messages using the exact domain before they are delivered. ### What should you never open in spam mail? CISA's Recognize, Resist, Delete guidance says not to click links or attachments in a message you suspect is phishing, including an "unsubscribe" link, and to delete it instead. The joint federal phishing guidance separately recommends blocking specific attachment file types at the mail gateway, including .scr, .exe, .pif, and .cpl, since attackers commonly use those extensions to deliver malware. ### How do I know if I got phished? There is no single confirmed sign; the clearest evidence is your own action on the message. If you entered credentials on a site linked from the email, opened an attachment you were not expecting, or handed over personal information, treat the account as compromised. The FTC directs anyone who gave a scammer personal information to IdentityTheft.gov, and CISA recommends reporting the message regardless, through report@cisa.gov for organizations or reportphishing@apwg.org for individuals. ### What are the 4 P's of phishing? No CISA, FTC, or Microsoft source defines a "4 P's of phishing" framework. If you have seen the term elsewhere, treat it as unverified shorthand rather than official guidance, and use CISA's five documented indicators of a phishing attempt instead: a mismatched sender address, a generic greeting, a spoofed hyperlink, spelling or layout errors, and an unexpected attachment. ### Is MFA enough to stop phishing on its own? No, not every form of MFA holds up against phishing. CISA's joint guidance with the NSA, FBI, and MS-ISAC calls FIDO and PKI-based MFA "phishing resistant," but flags SMS or voice codes, which can be intercepted or phished through a fake login portal, and push notifications without number matching, which users sometimes approve without checking. The type of MFA in use determines whether it actually blocks a credential-phishing attempt. --- # Phishing scam email example: how to assess one safely Canonical: https://www.palisade.email/learning/phishing-scam-email-example > Phishing scam email examples reveal sender, urgency, and link clues. Learn how to inspect a suspicious email and verify it safely for safer decisions. A phishing scam email often claims to be from a familiar organization, creates pressure to act, and directs you to a link, attachment, or reply path controlled by the attacker. No single clue proves an email is fraudulent or safe. Treat the claimed identity, actual sender address, requested action, and destination as separate evidence, then verify the claim through contact details you already know. This page works through one message in detail. To compare invoice, account-alert, executive, file-share, and support pretexts side by side, use the [phishing email examples library](/learning/phishing-email-examples). ## Quick takeaways - A phishing email can use a convincing display name while sending from an unrelated address. - Urgency, unexpected requests, and unusual payment or sign-in prompts are reasons to investigate. - Link text can differ from the destination that opens when you select it. - Do not use a phone number, reply address, link, or attachment supplied by a suspicious message to verify it. - An SPF, DKIM, or DMARC result does not establish that a message is legitimate or that its request is safe. - If you clicked a suspicious link, use your organization's incident process or follow a documented post-click response. ## How a phishing scam email works [The National Institute of Standards and Technology describes phishing](https://www.nist.gov/itl/smallbusinesscyber/guidance-topic/phishing) as an attempt to trick people into revealing sensitive information or taking an unsafe action. The email may impersonate a business, colleague, delivery service, or account provider. Its purpose is usually to get a recipient to disclose information, open an attachment, visit a website, send money, or approve a change. The message below is fictional. The domains, sender, attachment, and request are invented for this example. It does not depict a real company, account, or scam. ![Annotated fictional phishing email showing a claimed sender, mismatched sender address, urgent request, destination to inspect, and an independent verification route](/images/editorial/phishing-scam-email-example/phishing-scam-email-example-email-anatomy.webp "1200x980") *Source: Palisade.* Read the example in evidence order: ```text From: "Account Review Team" <notice@accounts-example-mail.com> Subject: Immediate action required: account review Your account will be suspended today unless you review the attached Account-Status-Update.html file. Or sign in now: https://example-account-check.invalid/signin Do not contact support. This review must be completed within one hour. ``` The display name, "Account Review Team," is a claim. The address after it is the sending identity shown to the recipient. The email's demand to act within one hour is pressure, not evidence that the account needs attention. The attachment and sign-in destination are separate risks to inspect without opening. [Google's phishing guidance](https://support.google.com/mail/answer/8253?hl=en) advises checking the sender address and avoiding suspicious links or attachments. [Microsoft's phishing guidance](https://support.microsoft.com/en-us/security/protect-yourself-from-phishing) also advises checking the full sender address and examining links before selecting them. Those checks can reveal inconsistencies, but an address that looks plausible is still not a verdict. For a broader explanation of attack methods, see [email-security guidance](/learning/threats). A request from a compromised real account can still be harmful, and a poorly formatted legitimate message can still be genuine. ## When the answer changes A suspicious message deserves a different response depending on what you have already done. - If you only received the email, preserve it and verify the claimed organization outside the message. - If the email claims to be from a colleague or supplier, use a known phone number, address book entry, or established ticketing channel. Do not reply to the email to ask whether it is real. - If the email requests a payment, bank-detail change, credential reset, or urgent approval, use the organization's established verification process before acting. - If you opened a link or attachment, stop interacting with it and follow your organization's incident process. The next steps can differ from the safe handling of an unopened message. - If the message appears to be from a business domain your team controls, public DNS configuration can provide context, but it cannot inspect the message itself. The [Federal Trade Commission advises contacting the company using a phone number or website you know is real](https://consumer.ftc.gov/articles/how-recognize-avoid-phishing-scams?os=firetv), rather than using contact details from the unexpected message. This is the usable decision rule: if the email asks you to use a path it supplied, verify through a path you supplied or already trust. A message can also be part of [business email compromise](/learning/business-email-compromise-vs-phishing), where the harmful request may come from a real or compromised mailbox. In that case, a familiar sender name or domain is not enough to approve a financial or account change. ## A worked phishing-email decision rule Use this short checklist before clicking, downloading, replying, or calling a number from a suspicious email. - **Claimed identity.** Does the display name or branding make a claim you can verify elsewhere? - **Actual sender.** What is the complete address, and does it match the claimed organization? - **Requested action.** Is the message asking for credentials, payment, an attachment download, a sign-in, or an urgent change? - **Destination.** What website, attachment, reply address, or phone number does the email supply? - **Independent route.** What known website, saved contact, or internal process can verify the claim without using the message? Several warning signs together increase the reason to investigate. They do not prove that the message is malicious. A sender could use a legitimate service, a real domain could be compromised, or a genuine organization could send an unexpected notice. Email authentication has a similar limit. SPF and DKIM examine parts of the sending path and message authentication, while DMARC evaluates aligned authentication for the visible From domain. A passing result does not establish the sender's intent, make a linked website safe, or prove that a payment request is authorized. For the domain-authentication boundary, see [anti-phishing software guidance](/learning/anti-phishing-software). > Do not open an HTML attachment or sign in through a link from a suspicious email to test whether it is real. Verify the claim through a known route first. ## What to do with a suspicious email Preserve the message. Your organization may need the original email, headers, sender address, destination, and attachment name for reporting or investigation. Then use an independently known website, phone number, saved contact, or internal security channel to verify the claim. If the email appears to use a domain your organization owns, inspect the public configuration separately. Palisade's [Email Security Score](/tools/email-security-score) can check public SPF, DKIM, and DMARC configuration for that domain. Keep that result separate from message evidence. It cannot identify the intent of the sender or inspect a private email, attachment, or destination. Report the message through your email provider's reporting process or your organization's security process. If you interacted with the message, report that fact promptly so the response can focus on the exact action taken. ## Check the claimed domain's public email security Use public sender-domain evidence only as context for a domain you control, then keep it separate from the private message. [Check the domain](/tools/email-security-score) A public record check cannot decide whether a private email is a phishing scam. ## Sources and further reading - [Federal Trade Commission: How To Recognize and Avoid Phishing Scams](https://consumer.ftc.gov/articles/how-recognize-avoid-phishing-scams?os=firetv) - [NIST: Phishing](https://www.nist.gov/itl/smallbusinesscyber/guidance-topic/phishing) - [Google: Avoid and report phishing emails](https://support.google.com/mail/answer/8253?hl=en) - [Microsoft: Protect yourself from phishing](https://support.microsoft.com/en-us/security/protect-yourself-from-phishing) - [Palisade Email Security Score](/tools/email-security-score) ## Frequently asked questions ### Can I get phished just by opening an email? Not usually by reading plain email content alone, but opening an email can expose you to a deceptive request. The greater risk is selecting a link, opening an attachment, replying with information, or following contact details supplied by the message. Preserve the email and verify its claim independently. ### What are four warning signs that an email is a phishing email? Four common warning signs are a sender address that does not match the claimed organization, pressure to act immediately, an unexpected request for credentials or payment, and a link or attachment that leads outside the expected service. Each sign is a reason to investigate, not proof on its own. ### How do I know if a phishing email is real? Do not try to prove it by replying, clicking, opening an attachment, or calling the number in the email. Contact the claimed organization through a known website, saved contact, or established internal process. That independent route is stronger evidence than the message's own claims. ### What are four types of phishing emails? Four common types are credential phishing that asks for sign-in details, attachment phishing that asks you to open a file, invoice or payment phishing that requests money or banking changes, and impersonation phishing that pretends to be a trusted person or organization. A single message can use more than one type. ### Does a passing DMARC check mean an email is safe? No. DMARC can show that a message passed aligned SPF or DKIM authentication for its visible From domain. It does not determine whether the sender's request is authorized, whether an account was compromised, or whether a linked site or attachment is safe. --- # What does a DKIM record look like? Canonical: https://www.palisade.email/learning/what-does-a-dkim-record-look-like > A DKIM record is a DNS TXT entry at selector._domainkey.yourdomain.com with a v=DKIM1; k=rsa; p=... tag list. See a worked example and how to check yours. A DKIM record is a DNS TXT resource record published at a selector-based hostname, typically `selector._domainkey.yourdomain.com`. Its value is a short tag=value list defined by RFC 6376: it starts with `v=DKIM1`, names a key type with `k=` (usually `rsa`), and carries a base64-encoded public key with `p=`. Microsoft 365 is the main documented exception: it publishes two rotating CNAME records instead of a TXT record holding the key directly. ## Quick takeaways - A DKIM record is a DNS TXT resource record (CNAME for Microsoft 365 custom domains) at a name built from a selector plus `_domainkey` plus the domain. - Its value is a tag=value list defined by RFC 6376, and it always starts with `v=DKIM1`. - `k=` names the key type, `rsa` by default, and `p=` carries the required base64-encoded public key. - The selector, the part of the name before `._domainkey`, lets one domain publish a separate key for every sending service it uses at the same time. - Microsoft 365 delegates key storage and rotation to its own DNS zone through CNAME records rather than publishing the key in a TXT record. - The selector name and public key are generated by whichever system signs your mail, never typed in by hand. ## How a DKIM record works [RFC 6376](https://datatracker.ietf.org/doc/html/rfc6376) defines DKIM as a signature-based email authentication method, and [DKIM](/learning/dkim) covers how the signing and verification process works end to end. A sending system signs outgoing mail with a private key and adds a `DKIM-Signature` header to the message. The receiving system recovers the matching public key from DNS and uses it to verify that signature. The record name and the record value answer two different questions. The name tells a verifier where to fetch a key. The value describes the key it finds there. ### The selector identifies a particular DKIM key That public key lives inside the `_domainkey` namespace RFC 6376 reserves for DKIM key records. The full record name follows this pattern: `<selector>._domainkey.<domain>`. The selector is the first label in that name, a short label chosen by whichever system signs the mail, and it also appears in the `s=` tag of the `DKIM-Signature` header on outgoing messages, so a verifier knows exactly which key record to fetch. [Google Workspace Admin Help](https://support.google.com/a/answer/174124) confirms this pattern for its own setup: the DNS record type is TXT, the host name is built from a prefix selector plus `._domainkey`, and the value starts with `v=DKIM1`. A signer using the selector `selector1` for `yourdomain.com` therefore sends every verifier to one exact DNS owner: ```text selector1._domainkey.yourdomain.com ``` The selector is not a fixed DKIM keyword. It is generated by the system that manages the signing key, which is why one provider's selector, CNAME target, or public-key value is never safe to reuse for another provider or domain. It is also what lets a single domain hold several live DKIM keys at once, one for each sending system and one for each key in a rotation. ### The record value carries the public-key information For most providers, that DNS record is a TXT resource record whose value is a tag=value list, the textual representation RFC 6376 specifies for the key record. Four tags do most of the work: - `v=` states the record version, normally `DKIM1`. - `k=` names the key type. RFC 6376 defaults this to `rsa` when the tag is absent. - `p=` carries the public key itself, base64-encoded. RFC 6376 requires this tag; an empty `p=` value signals a revoked key. - `s=` and `t=` are optional. `s=` restricts which service the key applies to, and `t=` can flag testing mode (`t=y`) or restrict the key to the exact signing domain (`t=s`). ![DKIM record anatomy diagram](/images/editorial/what-does-a-dkim-record-look-like/what-does-a-dkim-record-look-like-what-does-a-dkim-record-look-like-anatomy-diagram.png "1600x900") *Source: Palisade.* Only the public half of the key pair belongs in that value. The private key stays inside the sending system, so a `p=` value is public-key material rather than a password, an API token, or anything that needs protecting. [RFC 8301](https://www.rfc-editor.org/rfc/rfc8301.html) sets the current cryptographic floor for it: signers should use RSA keys of at least 1024 bits, and the same update permits `ed25519` keys as an alternative to RSA. Not every provider publishes the key in a TXT record directly. [Microsoft Learn's DKIM setup guide](https://learn.microsoft.com/en-us/defender-office-365/email-authentication-dkim-configure) documents that Microsoft 365 uses CNAME records instead: each DKIM selector points to a hostname inside Microsoft's own `dkim.mail.microsoft` zone, and Microsoft manages key rotation on its side. The same page shows what a TXT-based record looks like on other systems for comparison, `v=DKIM1; k=rsa; p=MIGfMA0GCS...`, and states that if a TXT record shows up where Microsoft 365 expects a CNAME, the domain's DKIM status stays `CnameMissing` until the TXT record is deleted and the correct CNAME is published. ## When the record format changes A domain rarely has just one DKIM record. Because the selector is part of the record name, one domain can publish a separate key for every sending service it uses at the same time, Google Workspace, a marketing platform, a support desk, each with its own selector and its own `_domainkey` record. Nothing about the DNS TXT record type limits a domain to a single key. Selectors also change over time through key rotation. [Microsoft's DKIM documentation](https://learn.microsoft.com/en-us/defender-office-365/email-authentication-dkim-configure) describes a two-selector rotation model: `selector1._domainkey` and `selector2._domainkey` both exist for a domain, but only one signs mail at a time. When Microsoft rotates the key, the inactive selector takes over and the previous one goes dark, a process the same documentation says takes about four days to complete. A DKIM lookup taken mid-rotation can show two valid-looking records for one domain, which is expected rather than a misconfiguration. Subdomains used for services outside your direct control, a bulk mailer sending as `marketing.yourdomain.com`, for example, get their own DKIM record at their own selector rather than inheriting the parent domain's record. If that record is missing entirely, [what to do when no DKIM record is found](/learning/no-dkim-record-found) covers the diagnostic path from there. ## Worked example of a DKIM record The illustrative record below shows the shape a TXT-based DKIM record takes once a provider has generated the key pair. It is a structural example only, built with the example domain `yourdomain.com`. ```text selector1._domainkey.yourdomain.com. IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC7...TRUNCATED...QIDAQAB" ``` > Do not publish this exact string. The selector name and the public key are generated per domain by whichever system signs your mail (Google Workspace, Microsoft 365, or your ESP). Get the real values from that provider's admin console, not from an example. Reading it left to right: `selector1._domainkey.yourdomain.com` is the full record name, built from the selector the sending system chose. `IN TXT` is the DNS record type. The quoted value is the tag=value list: `v=DKIM1` marks it as a DKIM key record, `k=rsa` states the key type, and `p=` holds the base64-encoded public key a verifier uses to check the signature on your outgoing mail. If your DNS host limits TXT record length, the key value may need to be split across multiple quoted strings; your provider's setup instructions should say when that applies. ## How to find and check the record for your domain Start with the selector, not the DNS lookup. If you already send mail through the domain, open a message you sent to an external recipient and view its full headers. The `s=` value in the `DKIM-Signature` header is the exact selector your system is using right now, a value both [Google's DKIM setup guidance](https://support.google.com/a/answer/174124) and Microsoft's DKIM setup guidance point to for the same reason. If you manage the sending system directly, the admin console usually shows the current selector and record value without needing to inspect headers at all: Google Workspace shows it under Admin console > Apps > Google Workspace > Gmail > Authenticate email, and Microsoft 365 shows it on the DKIM tab of the Defender portal's email authentication settings page. Once you have the selector, confirm what DNS actually publishes with a DKIM record checker. A lookup against `<selector>._domainkey.<domain>` shows whether a record resolves at all, and [interpreting the tag values a DKIM checker returns](/tools/dkim) walks through what a correctly formatted result looks like compared to a broken one. DKIM sits alongside SPF and DMARC as one of the three protocols behind [email authentication](/learning/dmarc); a published DKIM record confirms your public key is available, not that DMARC alignment or delivery is also working. ## Check the DKIM record your domain currently publishes The examples above use example values because a real selector and public key are specific to your domain and your sending provider. Before troubleshooting further, run your own domain through a checker to see the actual record DNS returns and compare its tags against what your provider's setup page expects. [Check the DKIM record](/tools/dkim) A DNS lookup confirms what is published, not whether your mail server is signing outgoing messages with that exact key or whether every service sending on your domain has its own correctly configured selector. ## Sources and further reading - [RFC 6376: DomainKeys Identified Mail (DKIM) Signatures](https://datatracker.ietf.org/doc/html/rfc6376) - [RFC 8301: Cryptographic Algorithm and Key Usage Update to DKIM](https://www.rfc-editor.org/rfc/rfc8301.html) - [Google Workspace Admin Help: Set up DKIM](https://support.google.com/a/answer/174124) - [Microsoft Learn: Set up DKIM to sign mail from your cloud domain](https://learn.microsoft.com/en-us/defender-office-365/email-authentication-dkim-configure) - [Palisade DKIM checker](/tools/dkim) ## Frequently asked questions ### Where do I find my DKIM record? A DKIM record lives in your domain's public DNS at `<selector>._domainkey.<domain>`, not in a single admin panel. Find your selector first, either in the `s=` tag of the `DKIM-Signature` header on a message you sent, or in your provider's admin console (Google Workspace shows it under Authenticate email; Microsoft 365 shows it on the DKIM tab of the Defender portal), then look up that exact name with a [DKIM record checker](/tools/dkim). ### What is an example of a DKIM format? A typical TXT-based DKIM record value looks like `v=DKIM1; k=rsa; p=` followed by a base64-encoded public key, the tag=value syntax [RFC 6376](https://datatracker.ietf.org/doc/html/rfc6376) defines. Microsoft 365 is a documented exception: instead of a TXT record holding the key, it publishes a CNAME record pointing to a hostname inside Microsoft's own DKIM zone, as shown in [Microsoft's DKIM setup guide](https://learn.microsoft.com/en-us/defender-office-365/email-authentication-dkim-configure). ### How do I write a DKIM record? You do not write the public key by hand. The system that signs your outgoing mail, whether that is Google Workspace, Microsoft 365, or another sending platform, generates the key pair and gives you the exact selector name and record value to publish at your DNS host. Your job is limited to creating the DNS record (TXT for most providers, CNAME for Microsoft 365 custom domains) with those exact values, as both [Google's](https://support.google.com/a/answer/174124) and [Microsoft's](https://learn.microsoft.com/en-us/defender-office-365/email-authentication-dkim-configure) setup documentation describe. ### What kind of record is a DKIM record? A DKIM record is normally a DNS TXT resource record, the format [RFC 6376](https://datatracker.ietf.org/doc/html/rfc6376) specifies for storing the public key. Microsoft 365 is a documented exception for custom domains, where the record type is CNAME instead, delegating key storage and rotation to Microsoft's own DNS zone rather than publishing the key directly. ### What is a valid DKIM record example? A valid TXT-based record pairs a selector-scoped hostname such as `selector1._domainkey.yourdomain.com` with a value that opens `v=DKIM1; k=rsa; p=` and continues with the sender's own base64 public key. Well formed is not the same as working, though. The record verifies signatures only when that published public key matches the private key the sending system signs with, so both the selector and the key have to come from that system rather than from any example. ### How do I set a DKIM record in DNS? Use the record type and the exact hostname your sending service supplies. Publish a TXT record when the service gives you a DKIM tag=value string, and publish a CNAME when it gives you a CNAME target, without converting either one into the other. Then confirm three things separately: that DNS resolves the record, that the sending service reports the domain as verified, and that a message sent through the production path carries the expected signature. --- # What does DMARC stand for and what does each part mean? Canonical: https://www.palisade.email/learning/what-does-dmarc-stand-for > DMARC stands for Domain-based Message Authentication, Reporting, and Conformance. Learn what each part means and how to validate it for email. DMARC stands for Domain-based Message Authentication, Reporting, and Conformance. It is an email authentication protocol for domain owners and mail receivers. The current core standard is [RFC 9989](https://www.rfc-editor.org/rfc/rfc9989.html), an IETF Proposed Standard published in May 2026. DMARC checks whether SPF or DKIM authenticates and aligns with the visible `From:` domain, communicates a requested handling policy for failures, and supports reporting about use of that domain. ## Quick takeaways - DMARC means Domain-based Message Authentication, Reporting, and Conformance. - The current core DMARC specification is [RFC 9989](https://www.rfc-editor.org/rfc/rfc9989.html), which obsoletes RFC 7489. - DMARC evaluates the domain in the visible `From:` header, called the Author Domain in RFC 9989. - A message passes DMARC when SPF or DKIM passes and produces an identifier aligned with the Author Domain. - A DMARC record can request `none`, `quarantine`, or `reject` handling for failing mail. - Aggregate reporting is specified separately in [RFC 9990](https://www.rfc-editor.org/rfc/rfc9990.html). ## Who is affected? DMARC affects a domain owner that wants mail receivers to validate use of its visible sending domain, publish a preference for mail that fails validation, or request reports about that domain's use. It also affects mail receivers that choose to evaluate the record and use its information when making handling decisions. The rule applies to the Author Domain, which RFC 9989 defines from the RFC 5322 `From:` field. That focus distinguishes DMARC from a standalone SPF check. SPF can authenticate a return-path domain, and DKIM can authenticate a signing domain, but DMARC evaluates whether either authenticated identity aligns with the domain people see in `From:`. DMARC does not require every mail receiver to enforce the domain owner's requested policy. RFC 9989 says receivers can use the information when evaluating handling choices. A `p=reject` record therefore expresses the domain owner's requested disposition for DMARC failures. It does not prove that every receiver will make the same delivery decision. For the wider protocol overview, see the [Palisade DMARC learning hub](/learning/dmarc). If alignment terminology is the missing piece, [DMARC `adkim` and `aspf` alignment](/learning/glossary/dmarc-adkim-aspf) explains the two alignment-mode tags. ## What are the requirements? ### The domain owner publishes a DMARC TXT record RFC 9989 defines a DMARC policy record as a DNS TXT record at `_dmarc.` followed by the domain name. The record begins with the [`v=DMARC1` version tag](/learning/glossary/dmarc-v-dmarc1) and includes a `p=` tag that states the requested policy. ```text _dmarc.yourdomain.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com" ``` > Use example values only. Do not copy another organization's report address or publish a report destination that you do not control. The `p=` value can be `none`, `quarantine`, or `reject`. `none` asks the receiver to take no specific action based on DMARC failure, while `quarantine` and `reject` express progressively stronger requested handling. The standard does not say that a domain owner must begin at one policy or move through them on a fixed schedule. ![DMARC DNS record anatomy showing the protocol version, requested policy, and aggregate report destination](/images/editorial/what-does-dmarc-stand-for/what-does-dmarc-stand-for-record-anatomy.webp "1200x533") *Source: Palisade.* ### Message authentication must align with the visible domain DMARC uses SPF and DKIM results. Under [RFC 9989's DMARC evaluation rules](https://www.rfc-editor.org/rfc/rfc9989.html), a message passes if either SPF or DKIM produces a passing result with an identifier aligned with the Author Domain. Alignment means the authenticated identity is compared with the visible `From:` domain. The default alignment mode is relaxed. Domain owners can request strict alignment with the `adkim` tag for DKIM or the `aspf` tag for SPF. Strict alignment is a policy choice, not a universal requirement. DMARC does not require both SPF and DKIM to pass. One aligned pass is sufficient for DMARC to pass. A message can therefore pass DKIM but fail SPF and still pass DMARC if the DKIM identity aligns with the visible domain. ### The record can request aggregate reports A domain owner can request aggregate reports with the `rua` tag. [RFC 9990](https://www.rfc-editor.org/rfc/rfc9990.html) specifies that an aggregate report is an XML document and that a receiver can send it to a destination declared in the DMARC record. Aggregate reports help identify which sources claim to send using a domain and how receivers evaluated their mail. They are evidence about reported traffic, not a complete inventory of every message sent by every system. Receiver participation, report timing, and report coverage vary. Failure reporting is a separate part of the current DMARC specification. [RFC 9991](https://www.rfc-editor.org/rfc/rfc9991.html) defines DMARC failure reporting and obsoletes the corresponding RFC 7489 material. Do not assume that a failure-report destination will receive an individual report for every failed message. ### The requested policy applies to the domain and can cover subdomains The `p=` tag states the requested policy for the domain where the DMARC record is found. The `sp=` tag can state a separate requested policy for subdomains. If a domain owner needs to decide whether subdomains inherit a policy or need a different one, see [how the DMARC `sp` tag works](/learning/glossary/dmarc-sp). A receiver evaluates the applicable DMARC record and message authentication before it considers the requested policy. Publishing `p=reject` does not repair an SPF authorization, create a DKIM signature, or make a third-party sender align with the visible domain. ## When does the requirement take effect? RFC 9989 was published in May 2026 as an IETF Proposed Standard. It is the current core DMARC specification and obsoletes RFC 7489 and RFC 9091. [RFC 9990](https://www.rfc-editor.org/rfc/rfc9990.html), also published in May 2026 as a Proposed Standard, defines aggregate reporting. RFC 9991, published at the same time, defines failure reporting. There is no single protocol-wide date on which every domain must publish DMARC. A domain owner chooses whether to deploy the protocol unless a mailbox provider, customer contract, regulator, or other separate rule imposes a requirement. Those external requirements have their own scope, dates, and enforcement terms. For existing implementations, treat RFC 9989 as the controlling core source rather than relying on the obsolete RFC 7489. The record format and policy concepts remain familiar, but the current standard is the source to use when interpreting current protocol behavior. ## How do I implement the requirement? ### 1. Identify the domain in the visible `From:` address List the domains your organization uses in the visible `From:` field for transactional, marketing, support, and employee mail. DMARC protects the Author Domain in that field, so a return-path domain alone is not enough to determine the DMARC policy you need. ### 2. Confirm SPF or DKIM can align For each sending path, confirm that SPF or DKIM can produce a passing identity aligned with the visible `From:` domain. A sending platform may authenticate a domain that it owns by default, which may leave its result unaligned with your domain. Use the strictness settings only after you understand the sending paths that need to pass. The `adkim` and `aspf` tags change alignment evaluation. They do not make an unauthenticated message valid. ### 3. Publish a monitoring record Start with a valid DNS TXT record that includes `v=DMARC1` and an appropriate `p=` value. A reporting address in `rua` gives participating receivers a destination for aggregate reports. Check the DNS record through the authoritative DNS service and at least one public resolver after publishing it. DNS visibility does not confirm that a sender is using the intended authentication setup. ### 4. Review reported sources before requesting stronger handling Use aggregate reports to identify legitimate sending sources and investigate sources that fail SPF, DKIM, or alignment. Correct the sending configuration before increasing policy strength. A [`p=none` record](/learning/glossary/dmarc-p-none) is still a DMARC policy record. It requests no specific receiver action for failure, so it is useful while the domain owner gathers evidence. Move to `quarantine` or `reject` only when the organization has reviewed the production paths that send with the protected domain. ## How do I validate compliance? Validate DMARC compliance at four layers, from the DNS record through to a delivered message. - DNS: confirm that `_dmarc.yourdomain.com` returns one syntactically valid DMARC TXT record from the authoritative DNS service and a public resolver. - Vendor: confirm in each sending platform that SPF or DKIM has been configured for the domain used in the visible `From:` address. - Message: send a real message through each production path and inspect its raw headers. Confirm that the receiver's DMARC result is `pass` and that the passing SPF or DKIM identity aligns with the visible `From:` domain. - DMARC: review aggregate reports after they accumulate to identify reported sources and recurring authentication or alignment failures. A DNS record check is the narrowest useful first step. [Check the published DMARC record](/tools/dmarc) before changing a policy, then compare the result with a delivered message and your aggregate-report data. A public DNS check cannot prove that a production sender signs mail correctly, that a receiver will honor the requested policy, or that future mail will reach the inbox. ## Turn a valid record into an enforcement plan A published record answers whether a public DMARC policy is visible. It does not show which production sources still fail alignment, which source needs remediation first, or when the domain is ready for a stronger policy. Palisade is agentic DMARC software that analyzes DMARC aggregate-report data, identifies sending sources and authentication or alignment issues, and creates prioritized remediation tickets. It can propose the next policy step when the evidence supports it. Your team reviews the evidence and applies the DNS change. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=existing_content_migration&utm_content=what-does-dmarc-stand-for) Palisade does not autonomously change your DMARC policy, control a receiver's private mail decision, or guarantee delivery or inbox placement. ## Sources and further reading - [RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance (DMARC)](https://www.rfc-editor.org/rfc/rfc9989.html) - [RFC 9990: Domain-Based Message Authentication, Reporting, and Conformance (DMARC) Aggregate Reporting](https://www.rfc-editor.org/rfc/rfc9990.html) - [RFC 9991: Domain-Based Message Authentication, Reporting, and Conformance (DMARC) Failure Reporting](https://www.rfc-editor.org/rfc/rfc9991.html) ## Frequently asked questions ### What does DMARC stand for? DMARC stands for Domain-based Message Authentication, Reporting, and Conformance. The name describes the protocol's focus on a visible email domain, authentication through SPF or DKIM alignment, reporting, and a requested policy for failed validation. ### Does DMARC require both SPF and DKIM? No. RFC 9989 says DMARC passes when either SPF or DKIM passes with an aligned identifier. Using both remains useful because it gives legitimate mail more than one authentication path. ### Is RFC 9989 still the current DMARC standard? No. RFC 9989, published in May 2026 as an IETF Proposed Standard, obsoletes RFC 7489 for the core DMARC protocol. RFC 9990 and RFC 9991 separately define aggregate and failure reporting. ### Does `p=reject` guarantee that all spoofed mail is rejected? No. `p=reject` expresses the domain owner's requested handling for messages that fail DMARC. A receiver makes its own handling decision and may consider other information. ### Does a DMARC record prove that all email from a domain passes DMARC? No. A record proves only that a policy is publicly published. Validate each production sending path with delivered-message headers and review aggregate reports as they arrive. --- # What is a different name used for business email compromise? Canonical: https://www.palisade.email/learning/what-is-a-different-name-used-for-business-email-compromise > Business email compromise (BEC) is also called email account compromise (EAC), the FBI's term pairing for this scam category, per its official guidance. The FBI's official guidance says business email compromise (BEC) is "also known as email account compromise (EAC)." Both terms cover the same scam category: a criminal impersonates or takes over a trusted email account to redirect a legitimate transfer of money or data. Security vendors also use "CEO fraud" for the narrower pattern where the impersonated sender is a company executive, but EAC is the term federal reporting groups pair directly with BEC. ## Quick takeaways - The FBI's business email compromise page states BEC is "also known as email account compromise (EAC)." - The FBI's Internet Crime Complaint Center (IC3) uses the combined heading "Business Email Compromise/Email Account Compromise (BEC)" in its 2024 scam report. - "CEO fraud" is a narrower, vendor-defined term for the executive-impersonation subtype of BEC, not a synonym for the whole category. - IC3 recorded $55,499,915,582 in total exposed BEC/EAC losses across 305,033 domestic and international incidents in the period its September 2024 report covers. - EAC typically describes a case where the criminal had real access to the mailbox, not just a look-alike address. - Liability for a BEC loss is decided case by case under state adoptions of UCC Article 4A, not by one federal rule. ## Why the FBI pairs two names for one scam The [FBI's public guidance on business email compromise](https://www.fbi.gov/how-we-can-help-you/scams-and-safety/common-frauds-and-scams/business-email-compromise) states: "In a BEC scam, also known as email account compromise (EAC), criminals send an email message that appears to come from a known source making a legitimate request." The two labels sit on one mechanism because a BEC scam can happen in two different ways. In the first pattern, a criminal spoofs an address or domain that looks like a trusted sender's without ever touching the real account. In the second, a criminal actually gains control of the real account, through phishing, credential theft, or malware, and sends the fraudulent message from inside it. The [FBI's Internet Crime Complaint Center](https://www.ic3.gov/CrimeInfo/BEC) defines the underlying crime as one "frequently carried out when a subject compromises legitimate business e-mail accounts through social engineering or computer intrusion techniques resulting in an unauthorized transfer of funds." IC3's September 2024 public service announcement uses the combined heading ["Business Email Compromise/Email Account Compromise (BEC)"](https://www.ic3.gov/PSA/2024/PSA240911), treating them as one reporting category rather than two separate crime types. BEC sits inside a wider set of impersonation-based [email threats](/learning/threats) that all rely on the reader trusting a familiar sender. EAC works as a companion label, not a competing one: it names which of the two mechanisms produced the fraudulent message. ## When a different term applies Not every BEC-adjacent term means the same thing. [KnowBe4 defines CEO fraud](https://www.knowbe4.com/ceo-fraud) narrowly, as "a phishing attack where cybercriminals spoof executive email accounts to fool employees into giving away sensitive information." That definition covers only the subset of BEC scams where the impersonated sender holds an executive title. It does not cover the vendor-invoice or title-company patterns the FBI lists as BEC examples, where no executive is impersonated at all. For how a spoofed BEC message compares with a broader phishing attempt, see [business email compromise vs. phishing](/learning/business-email-compromise-vs-phishing). Use EAC when the evidence points to real account access: sent-item history the owner did not create, a login from an unrecognized location, or a mail forwarding rule the owner never set up. Use BEC as the umbrella term whenever the mechanism has not been established yet, since every EAC incident is also a BEC incident, but not every BEC incident involves an actual account takeover. ## What the three BEC patterns FBI cites look like The [FBI's BEC page](https://www.fbi.gov/how-we-can-help-you/scams-and-safety/common-frauds-and-scams/business-email-compromise) lists three confirmed patterns from real victims: - A vendor a company regularly deals with sends an invoice listing an updated mailing or payment address. - A company CEO asks an assistant to buy gift cards for employee rewards and to send back the card serial numbers by email. - A homebuyer receives a message that appears to come from a title company, with wire instructions for a down payment. In every case the FBI cites, the message looked legitimate and the funds went to the criminal instead of the real recipient. Only one of the three involves an executive, which is why "CEO fraud" cannot stand in for the whole BEC category. ![Table naming business email compromise, its federal alternate name, and a narrower vendor term, with the source and scope of each](/images/editorial/what-is-a-different-name-used-for-business-email-compromise/what-is-a-different-name-used-for-business-email-compromise-records.webp "1200x533") *Source: Palisade.* For a single line that captures the mechanism and the name together, use this record: ```text Business Email Compromise (BEC), also known as Email Account Compromise (EAC): a scam in which a criminal impersonates or takes over a trusted email account to redirect a legitimate transfer of funds or data to an account the criminal controls. ``` ## What to check after a suspected BEC message If a message matches one of the FBI's patterns, first work out which mechanism produced it. Compare the full sender address, not just the display name, against your organization's known contact for that vendor, executive, or title company. Check whether the sending domain passed SPF and DKIM, and whether the mailbox sits on infrastructure your organization controls. A pass on both, combined with unfamiliar login activity or a forwarding rule the mailbox owner did not set, points toward EAC rather than a simple look-alike spoof. An authenticated sending domain makes it harder for a criminal to send a message that appears to come directly from your exact domain, but it does nothing against a look-alike domain or a genuinely compromised mailbox. For the financial and operational impact one successful message can cause, see [how business email compromise threatens a business](/learning/what-is-the-complete-guide-to-business-email-compromise-bec-attacks-in-2025). ## Check your domain's exposure to a look-alike BEC message The FBI's examples above all depend on the reader trusting a familiar-looking sender. Run your sending domain through Palisade's checker to see whether SPF, DKIM, and DMARC are published and aligned, which is one part of a wider [email security](/learning/threats) posture that makes exact-domain spoofing harder. [Check your domain's security posture](/tools/email-security-score) A domain security score cannot detect a mailbox that has already been taken over, confirm that a specific email you received is fraudulent, or stop a look-alike domain that only resembles yours. ## Sources and further reading - [FBI: Business Email Compromise](https://www.fbi.gov/how-we-can-help-you/scams-and-safety/common-frauds-and-scams/business-email-compromise) - [FBI IC3: BEC (Internet Crime Complaint Center)](https://www.ic3.gov/CrimeInfo/BEC) - [FBI IC3 PSA240911: Business Email Compromise: The $55 Billion Scam](https://www.ic3.gov/PSA/2024/PSA240911) - [KnowBe4: CEO Fraud Attacks](https://www.knowbe4.com/ceo-fraud) - [Holland & Knight: Fourth Circuit Limits Beneficiary Bank Liability in BEC Schemes](https://www.hklaw.com/en/insights/publications/2025/04/fourth-circuit-limits-beneficiary-bank-liability-in-bec-schemes) ## Frequently asked questions ### What are examples of business email compromise? The FBI cites three confirmed patterns: a vendor invoice that lists a changed payment address, a company executive asking an assistant to buy gift cards and email back the serial numbers, and a homebuyer receiving fake wire instructions from what looks like a title company. In each case the message looked legitimate and the requested funds went to the criminal instead of the real recipient. ### What is a red flag for a business email compromise? A red flag is an unsolicited request to change account, payment, or wire details, especially one that pressures the recipient to act quickly and skip verification. The FBI's guidance also points to slight misspellings in a sender's email address or a linked URL, and any payment request delivered only by email that discourages a phone call to confirm it. ### Who is liable for business email compromise? Not one uniform answer applies. When a BEC scam results in a wire or ACH transfer, U.S. courts generally apply their state's version of UCC Article 4A to decide which party absorbs the loss. A 2025 Fourth Circuit ruling in Studco Building Systems US, LLC v. 1st Advantage Credit Union held that a beneficiary bank is not liable for accepting a misdirected transfer unless a bank employee had actual, provable knowledge of the fraud, not merely information the bank "should have" pieced together. Because BEC liability turns on the specific facts, the account agreement, and the applicable state law, a business that loses funds to a BEC scam should get its own legal counsel rather than assume a default outcome. ### What is the difference between business email compromise and email account compromise? The FBI's Internet Crime Complaint Center does not treat business email compromise and email account compromise as two different scams. Its own reporting pairs them under one heading, "Business Email Compromise/Email Account Compromise (BEC)," and uses EAC to describe the subset of cases where the criminal gained real access to the victim's mailbox rather than only sending a look-alike message. Every EAC incident is also a BEC incident under this framing; not every BEC incident involves an actual account takeover. --- # What is an IP address? IPv4 vs IPv6 explained simply Canonical: https://www.palisade.email/learning/what-is-an-ip-address > What is an IP address? Learn how IPv4 and IPv6 identify network destinations, how DNS uses them, and what they mean for email sending online. An IP address is a numeric address used by Internet Protocol to identify a source or destination for network traffic. IPv4 uses a 32-bit address, commonly written as four decimal values. IPv6 uses a 128-bit address, written in hexadecimal groups. Both let networks route packets toward a destination, but an IP address alone does not identify the person using a device or prove that an email sender is authorized. ## Quick takeaways - An IP address identifies a network interface or destination for Internet Protocol traffic. - IPv4 addresses are 32 bits and are usually written in dotted-decimal form. - IPv6 addresses are 128 bits and use colon-separated hexadecimal groups. - DNS can map a domain name to IPv4 and IPv6 addresses through A and AAAA records. - A public IP address is routable on the Internet, while private IPv4 addresses are reserved for internal networks. - In email, an IP address is one input to SPF evaluation and receiver reputation decisions. ## Who is affected? Anyone who connects a device, service, mail server, or application to an IP network uses IP addressing. The address may belong directly to the device, to a network interface, or to a gateway that forwards traffic for many internal devices. For a public website or mail service, DNS tells clients which IP address to contact. An A record returns an IPv4 address and an AAAA record returns an IPv6 address. The wider [email authentication learning center](/learning) explains how DNS records also publish authentication controls for email domains. Private IPv4 addresses have a narrower scope. [RFC 1918](https://www.rfc-editor.org/rfc/rfc1918) reserves these address blocks for private internets: ```text 10.0.0.0/8 172.16.0.0/12 192.168.0.0/16 ``` A private address is not globally unique or intended for public Internet routing. A gateway can translate internal traffic to a public address, but that does not make the private address publicly reachable. ## What are the requirements? ### IPv4 uses a 32-bit address The original Internet Protocol specification defines IPv4 addresses as four octets, which total 32 bits. [RFC 791](https://www.rfc-editor.org/rfc/rfc791) describes Internet Protocol as moving datagrams between sources and destinations identified by fixed-length addresses. A familiar IPv4 presentation uses four decimal octets separated by periods: ```text 192.0.2.25 ``` This is an illustrative documentation address, not an address to publish or use for a production service. IPv4 routers use the address in a packet header to make forwarding decisions. The address identifies where the packet should go on the network. It does not provide encryption, reliable delivery, or proof that a sender is trustworthy. ### IPv6 uses a 128-bit address [IPv6](https://www.rfc-editor.org/rfc/rfc8200) is the current Internet Protocol Version 6 specification. It defines a 128-bit address format, much larger than IPv4's 32-bit space. IPv6 text notation uses hexadecimal values separated by colons. Consecutive zero groups can be compressed once with `::`. ```text 2001:db8:1234::25 ``` This is also an illustrative documentation address. [RFC 4291](https://www.rfc-editor.org/rfc/rfc4291) defines IPv6 addressing architecture and text representation. IPv6 is not a different form of DNS or email authentication. It is an Internet Protocol version with a different address length and packet format. ![Diagram comparing the 32-bit dotted-decimal IPv4 form with the 128-bit hexadecimal IPv6 form](/images/editorial/what-is-an-ip-address/what-is-an-ip-address-ipv4-ipv6-addresses.webp "1200x442") *Source: Palisade.* ### DNS maps names to IP addresses A domain name is a name, while an IP address is a network destination. DNS supplies the mapping between them. An A record contains an IPv4 address. An AAAA record contains an IPv6 address. ```text yourdomain.com. IN A 192.0.2.25 yourdomain.com. IN AAAA 2001:db8:1234::25 ``` These are structural examples only. Do not publish another organization's production addresses as values for your domain. DNS records describe where a client can attempt a connection. They do not prove that the destination application is healthy, accepts the intended protocol, or is configured to send email for the domain. ### Email authentication uses the sending path, not only a published address An email receiver can evaluate the IP address that connected to it against the sender's SPF policy. SPF is an authorization mechanism for the SMTP client IP address and the envelope sender domain. A matching address can support an SPF pass, but IP authorization is not the same as a successful DMARC result. DMARC also evaluates identifier alignment and can rely on DKIM. An IP address can also influence a receiver's reputation assessment. That assessment is private to the receiver and can change with traffic patterns. Publishing a correct A, AAAA, or SPF-related DNS record does not prove inbox placement or future acceptance. You can also use Palisade's [DMARC checker](/tools/dmarc) to review a domain's DMARC record. ## When does the requirement take effect? There is no single operative compliance date for using an IP address. IPv4 is specified by RFC 791, published in September 1981. IPv6 is specified by RFC 8200, published in July 2017. RFC 8200 obsoletes RFC 2460. The need to use IPv4, IPv6, or both depends on the network and service you operate. A DNS provider, hosting platform, mailbox provider, or network operator may set its own implementation requirements. Those provider-specific requirements are separate from the IP standards. For email, the practical requirement is to verify the exact production path. A sending platform may use IPv4, IPv6, or both. Do not assume that a public website address is also the address used to deliver the domain's email. ## How do I implement the requirement? ### 1. Identify the service that needs an address Decide whether the address is for a website, an API, a mail transfer system, or an internal device. The correct address depends on the service's network interface and hosting design. For an email sender, obtain the real outbound sending-path details from the sending platform or inspect a delivered message's headers. A domain's web-server address is usually not enough evidence. ### 2. Publish the required DNS record type Publish an A record when the service needs an IPv4 destination. Publish an AAAA record when it needs an IPv6 destination. Use the exact address assigned by the hosting or network provider. If a provider gives a hostname rather than an IP address, follow its documented CNAME or MX instructions instead of substituting an A record. The record type must match the service's documented configuration. ### 3. Add email authorization separately If the service sends email for your domain, configure its SPF and DKIM settings according to its documented sending setup. Do not treat an A or AAAA record as email authorization. A sender that changes outbound IPs may use an SPF `include:` mechanism rather than asking you to list individual addresses. Use the provider-generated value. Do not copy an example address from this article into an SPF record. ### 4. Test both address families when you publish both If the service has A and AAAA records, test a connection over IPv4 and IPv6. A service can be reachable over one protocol version while failing over the other. > Do not remove an existing A or AAAA record until you know which production clients and services use it. A DNS change can interrupt web, API, or mail-related connectivity even when another address still responds. ## How do I validate compliance? Start with DNS. Look up the domain's A and AAAA records through authoritative DNS and a public resolver. Palisade's [DNS lookup tool](/tools/dns-lookup) can inspect published DNS answers for a domain. Next, confirm the vendor layer. Check the hosting, network, or email platform's current status for the exact service and assigned address. A public DNS result only shows the record available to resolvers. It does not show whether the vendor has activated the service. For a sending domain, inspect a real delivered message from the production path. Its raw headers show the connecting path and authentication results. Then review DMARC aggregate reports once they have accumulated. This separates a published record from evidence that the intended mail stream is using it. A DNS lookup cannot prove the production sending path, a receiver's private reputation decision, continuous service health, or future inbox placement. ## Check the published addresses for your domain If you need to confirm whether a domain currently publishes IPv4 or IPv6 destinations, inspect its A and AAAA records before changing DNS. Compare the result with the address assignment from your hosting or sending provider. [Look up domain DNS records](/tools/dns-lookup) For teams that need to move from a one-time check to ongoing DMARC work, Palisade is DMARC software that analyzes aggregate-report data, identifies sending sources and authentication or alignment issues, and proposes the next policy step for human review. It does not change the DMARC policy, control a receiver's reputation decision, or guarantee delivery. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=existing_content_migration&utm_content=what-is-an-ip-address) For a provider-specific implementation of these authentication checks, see [What is an impersonation attack and how can you stop it?](/learning/what-is-an-impersonation-attack-and-how-can-you-stop-it). ## Sources and further reading - [RFC 791: Internet Protocol](https://www.rfc-editor.org/rfc/rfc791) - [RFC 8200: Internet Protocol, Version 6 Specification](https://www.rfc-editor.org/rfc/rfc8200) - [RFC 4291: IP Version 6 Addressing Architecture](https://www.rfc-editor.org/rfc/rfc4291) - [RFC 1918: Address Allocation for Private Internets](https://www.rfc-editor.org/rfc/rfc1918) ## Frequently asked questions ### Is an IP address the same as a domain name? No. An IP address identifies a network destination, while a domain name is a human-readable name. DNS can map the domain name to an IPv4 address, an IPv6 address, or both. ### Can a domain have both an IPv4 and IPv6 address? Yes. A domain can publish an A record for IPv4 and an AAAA record for IPv6. Clients and networks decide which available address family they can use. ### Does an IP address prove that email is authorized? No. A sending IP address may be evaluated by SPF, but a valid DMARC result also depends on the relevant authenticated identifier and alignment. An IP address does not prove that every message from a domain is authorized. ### Are private IP addresses visible on the public Internet? No. RFC 1918 private IPv4 ranges are intended for private networks and are not globally routable. A gateway may translate internal traffic to a public address for Internet access. ### Is IPv6 replacing IPv4 immediately? No. IPv6 has a larger address space and is defined by the current IPv6 specification, but IPv4 remains in use. Many services operate with both IPv4 and IPv6. --- # What is ghost phishing and can DMARC stop it? Canonical: https://www.palisade.email/learning/what-is-ghost-phishing > Ghost phishing hides a phishing page until browser-side code renders it. DMARC can stop domain spoofing, but cannot inspect a rendered payload. Ghost phishing is a label for phishing that hides its final lure until code running in the recipient's browser renders or decrypts it. DMARC can reduce one part of the risk: it helps stop attackers from sending mail that falsely uses your protected From domain. DMARC cannot determine whether a message from an attacker-controlled domain is safe, inspect all browser-rendered content, or stop a user from approving a fraudulent sign-in request. ## Quick takeaways - Ghost phishing describes an evasion technique, not a separate email-authentication standard. - An encrypted or encoded message body can still pass DKIM if it has not changed after signing. - DMARC evaluates domain authentication and alignment, not whether a rendered page is trustworthy. - An enforced DMARC policy helps prevent direct spoofing of the protected From domain. - Device-code phishing can abuse a legitimate Microsoft authorization flow when a victim enters and approves an attacker-supplied code. - Browser, identity, and user controls remain necessary when the lure comes from an attacker-controlled domain. ## How ghost phishing works The term "ghost phishing" is not defined by an RFC or a mailbox-provider standard. It is commonly used for a phishing flow where the email or initial web content appears harmless to a static inspection, while browser-side code later reconstructs the credential lure. The important distinction is timing. A secure email gateway can inspect the message delivered to it. A browser can later execute page code and render content that was not readable in its final form during that initial inspection. That does not mean every encrypted attachment or encoded page is malicious. It means authentication and content inspection answer different questions. DMARC is built around domain authentication. [RFC 9989 defines DMARC](https://www.rfc-editor.org/rfc/rfc9989.html) as a mechanism that uses SPF and DKIM results aligned with the visible Header From domain to determine whether a message passes DMARC. It also lets the domain owner publish a requested policy for messages that fail. DKIM does not classify content as safe. [RFC 6376 describes DKIM body integrity](https://www.rfc-editor.org/rfc/rfc6376.html): a valid signature confirms that the signed message content has not been altered in transit. If an attacker signs an encrypted or encoded payload using a domain they control, the signed message can remain intact while the later-rendered page is deceptive. ![Flow showing that DMARC can stop a spoofed protected domain before delivery but cannot determine whether browser-rendered content from an attacker-owned domain is safe](/images/editorial/what-is-ghost-phishing/what-is-ghost-phishing-dmarc-decision.webp "1200x676") *Source: Palisade.* For the wider domain-protection model, see the [DMARC learning hub](/learning/dmarc). ## When DMARC can and cannot help DMARC helps when the attacker attempts to impersonate a domain that has a correctly deployed and enforced DMARC policy. If a message uses your visible From domain but fails aligned SPF and DKIM, `p=quarantine` or `p=reject` asks the receiving system to apply stronger handling. The receiver still makes its own final decision under RFC 9989. DMARC does not stop a ghost-phishing campaign merely because the campaign uses email. It cannot block an attacker from sending from a domain the attacker legitimately controls. It also cannot inspect every page a recipient opens after delivery, reverse a user approval, or guarantee inbox placement. Use this decision rule: - If the suspicious message claims to be from your domain and fails DMARC, an enforced policy can help reduce spoofed delivery. - If the suspicious message passes DMARC from an unfamiliar or attacker-controlled domain, DMARC has confirmed domain authentication, not the sender's intent. - If the attack leads to a sign-in approval or device-code prompt, investigate the identity event in the provider's security tools. A DNS record cannot explain that authorization decision. Microsoft documents that [device code phishing can trick users into authenticating an attacker-controlled session](https://learn.microsoft.com/en-us/entra/identity/conditional-access/policy-block-authentication-flows). The user may complete a real Microsoft sign-in flow, but for a code or session initiated by the attacker. That is an identity-control problem, not a DMARC failure. > Do not move a production domain to `p=reject` solely because of one phishing incident. First identify legitimate sending sources and verify that important mail passes SPF or DKIM with DMARC alignment. [Does DMARC stop phishing?](/learning/does-dmarc-stop-phishing) covers the broader boundary between spoofing protection and phishing defense. For approval-based attacks, [phishing-resistant MFA](/learning/phishing-resistant-mfa) can reduce reliance on a user recognizing a deceptive prompt. ## A worked ghost-phishing decision example Consider a message that links to a page which appears blank or unreadable until the recipient opens it in a browser. The [email headers](/tools/email-header-analyzer) show a DMARC pass for `mailer.attacker-example.com`. ```text Visible From: notices@mailer.attacker-example.com DMARC result: pass DKIM d=: mailer.attacker-example.com Link destination: https://login.attacker-example.com/ Browser behavior: page renders a sign-in or authorization prompt ``` This example does not show a DMARC bypass. It shows a message that authenticated for the attacker-controlled domain. A DMARC pass means that aligned SPF or DKIM authenticated the visible From domain under the receiver's evaluation. It does not mean the domain is known to the recipient, that its content is legitimate, or that the linked page is safe. If the same lure instead claims to be from `yourdomain.com` and does not have aligned authentication for `yourdomain.com`, your enforced DMARC policy can request stronger handling. The exact result still depends on the receiving system. When reviewing a delivered message, use the `Authentication-Results` header as message-level evidence. [RFC 8601 defines the Authentication-Results field](https://www.rfc-editor.org/rfc/rfc8601.html), including result methods such as SPF and DKIM. Preserve the original message and inspect it in the security system approved by your organization. Do not paste unredacted headers, tokens, or customer data into public tools. ## What to do next with the evidence you have Start with the evidence closest to the event: - If you have a suspicious message, preserve the original message and review its authentication results, visible From domain, links, and any identity-provider alerts. - If a user entered a device code or approved an unexpected request, investigate the authorization event in Microsoft Entra ID and follow your incident-response process. Microsoft recommends restricting device-code flow where it is not needed and using Conditional Access controls where appropriate. - If the message impersonated your domain, check the public DMARC record and compare it with the policy your team intended to publish. - If you are planning enforcement, validate four layers: authoritative and public DNS, the sending vendor's status, headers from a real production message, and DMARC aggregate reports after they accumulate. A public lookup is useful for the third item only. It cannot prove the production path, a receiver's private filtering decision, later DNS drift, or whether every legitimate sender aligns. ## Check the DMARC policy behind a spoofing concern If the suspicious message used your domain in the visible From address, inspect the currently published DMARC record before proposing a DNS change. Compare the result with the message's authentication evidence and your approved sender inventory. [Check the DMARC record](/tools/dmarc) A public DMARC check does not inspect a browser-rendered phishing page, repair an identity compromise, monitor every sender, or prove why a receiving mailbox accepted or rejected one message. For teams that need to move beyond one public lookup, Palisade is agentic DMARC software that analyzes DMARC aggregate-report data, identifies sending sources and alignment issues, and creates prioritized remediation tickets. It can propose the next policy stage, while your team reviews the evidence and applies the change. It does not control browser content, automatically change your DMARC policy, or guarantee delivery. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=existing_content_migration&utm_content=what-is-ghost-phishing) ## Sources and further reading - [RFC 9989: Domain-based Message Authentication, Reporting, and Conformance](https://www.rfc-editor.org/rfc/rfc9989.html) - [RFC 6376: DomainKeys Identified Mail Signatures](https://www.rfc-editor.org/rfc/rfc6376.html) - [RFC 8601: Message Header Field for Indicating Message Authentication Status](https://www.rfc-editor.org/rfc/rfc8601.html) - [Microsoft Entra guidance for mitigating device code phishing](https://learn.microsoft.com/en-us/entra/identity/conditional-access/policy-block-authentication-flows) - [Palisade DMARC checker](/tools/dmarc) ## Frequently asked questions ### Is ghost phishing a type of malware? No. Ghost phishing is a label for an evasion and delivery technique. The final objective may be credential theft, session theft, fraudulent authorization, or another phishing outcome. ### Can a message pass DKIM and still be phishing? Yes. DKIM can show that signed content was not altered after signing. It does not determine whether the sender's content, link, or requested sign-in action is legitimate. ### Does a DMARC pass mean a sender is trustworthy? No. A DMARC pass means the receiver obtained aligned SPF or DKIM authentication for the visible From domain. Attackers can authenticate mail for domains they own or control. ### Can `p=reject` stop ghost phishing? Only when an attacker attempts to spoof the protected From domain and fails DMARC. `p=reject` does not block messages from attacker-controlled domains or inspect what a browser renders after delivery. ### Should we disable Microsoft device code flow? Only if your organization does not require it or can restrict it safely. Review Microsoft's documented mitigations, current business use cases, and your identity team's change process before changing access controls. --- # Yahoo Postmaster Tools: what sender data you actually get Canonical: https://www.palisade.email/learning/what-sender-data-does-yahoo-postmaster-provide > Yahoo Postmaster Tools is now Yahoo Sender Hub. Insights shows delivered volume and spam complaint rate for verified DKIM domains, and what it omits. Yahoo's current postmaster service is Yahoo Sender Hub. Its standard Insights view provides aggregate delivered volume and spam complaint rate for a verified DKIM signing domain. Yahoo also offers a separate Complaint Feedback Loop that sends Abuse Reporting Format complaint events for enrolled DKIM domains. These are useful Yahoo-specific signals, but they are not a universal sender-reputation score or proof of placement for an individual message. ## Quick takeaways - Yahoo Sender Hub Insights shows delivered volume and spam complaint rate for verified DKIM domains. - Yahoo calculates its displayed complaint rate from messages delivered to the inbox. - Insights data is grouped by the selected DKIM signing domain, so several From domains can contribute to one view. - The Complaint Feedback Loop provides individual ARF complaint reports for enrolled DKIM domains. - SMTP replies are evidence for one delivery attempt, while Insights shows aggregate trends. - Yahoo's placement and campaign performance feeds are separate documented services, not the standard Insights dashboard. ## How Yahoo Sender Hub data works Yahoo's [Sender Hub FAQ](https://senders.yahooinc.com/faqs/) identifies two standard Insights signals for a verified DKIM domain: **Delivered** and **Spam Complaint Rate**. Delivered is the number of messages Yahoo reports as delivered during the selected period. It can help an operator spot volume changes for that DKIM identity. It does not show every attempted message, prove inbox placement for every delivered message, or describe delivery at Gmail, Microsoft, or another recipient network. For Outlook.com consumer-mail telemetry, use [Microsoft's closest equivalent to Google Postmaster Tools](/learning/what-is-microsoft-s-equivalent-to-google-postmaster-tools), which covers different IP-focused data and complaint evidence. Spam Complaint Rate is an average for the selected period. Yahoo says this rate uses messages delivered to the inbox as its denominator. That can differ from an ESP's internal calculation, which may use accepted, delivered, or attempted messages. Compare trends within each system before treating two differently calculated rates as contradictory. Yahoo groups Insights under the verified DKIM signing domain. If multiple visible From domains sign with the same DKIM `d=` domain, their traffic can appear in the same aggregate view. A complaint-rate increase may therefore require further segmentation in the sender's own data by campaign, From domain, source IP, audience, and send time. Yahoo documents this data in UTC and includes Yahoo-managed domains in its reporting scope. For wider provider-specific guidance, see the [vendor email authentication learning hub](/learning/esp-setup). ![Yahoo Sender Hub data map separating aggregate Insights metrics, individual Complaint Feedback Loop events, SMTP replies, and separate performance feeds](/images/editorial/what-sender-data-does-yahoo-postmaster-provide/what-sender-data-does-yahoo-postmaster-provide-data-map.webp "1200x829") *Source: Palisade.* ## When the answer changes The right Yahoo data source depends on the evidence you need. - Use **Insights** when you need an aggregate trend for a verified DKIM domain, such as whether Yahoo-reported delivered volume or complaint rate changed over time. - Use the **Complaint Feedback Loop**, or CFL, when a recipient-level complaint event is needed for suppression or investigation. Yahoo's [Complaint Feedback Loop documentation](https://senders.yahooinc.com/complaint-feedback-loop/) describes it as a DKIM-domain-based service for DKIM-signed mail. - Use the complete **SMTP response** when a particular delivery attempt deferred or failed. Yahoo's [SMTP error-code reference](https://senders.yahooinc.com/smtp-error-codes/) distinguishes temporary 4xx responses from permanent 5xx failures and documents possible causes. - Use Yahoo's separately documented [Email Deliverability and Performance Feeds](https://senders.yahooinc.com/email-deliverability-performance-feeds/) only when your organization has access to those feeds and needs their documented aggregate outcome or campaign dimensions. A usable decision rule is: start with the narrowest evidence that matches the question. An individual bounce needs its SMTP reply. A complaint suppression workflow needs CFL events. A complaint trend for a signing domain needs Insights. Yahoo's standard Insights view does not answer every sender question. Yahoo says it does not currently provide an Insights API, and it no longer offers an IP- or CIDR-based complaint feedback loop in the [Sender Hub FAQ](https://senders.yahooinc.com/faqs/). Do not substitute an external IP score for Yahoo's own telemetry. ## Worked example: matching Yahoo data to the sending identity Start with a real delivered production message and record the identities that determine where evidence may appear. ```text Visible From domain: news.yourdomain.com DKIM signing domain: yourdomain.com Sending IP: 192.0.2.25 Recipient domain: yahoo.com Campaign identifier: august-product-update Evidence needed: Yahoo complaint trend for the DKIM signing domain ``` In this illustrative example, Sender Hub Insights would be selected for `yourdomain.com`, the DKIM `d=` domain. It would not automatically isolate `news.yourdomain.com` or the named campaign if other streams use the same signing domain. If a Yahoo-hosted recipient marks a covered message as spam and the DKIM domain is enrolled in CFL, the feedback report can provide an event for the sender's complaint-processing workflow. Yahoo's FAQ says ARF reports include a human-readable part, machine-readable feedback metadata, and original message headers. Handle those reports as sensitive operational data and use them to suppress the complaining recipient where appropriate. The Yahoo [bulk sender requirements](/learning/yahoo-bulk-sender-requirements) explain the authentication and complaint expectations that make these signals operationally relevant. If your investigation spans Gmail as well, compare the provider's own data with [what Google's DMARC reports say about sender failures](/learning/what-new-insights-do-google-dmarc-reports-provide-about-sender-requirement-failures), rather than assuming the dashboards measure the same things. ## What to check next When you have only a sending domain, first inspect the published DKIM record and identify the selector and signing domain used by the production mail stream. The record lookup is a DNS check, not proof that an application is currently signing mail with that identity. [Check the DKIM record](/tools/dkim) When you have a Yahoo Sender Hub trend, compare its time window with your ESP or application logs. Split the traffic by DKIM `d=` domain, visible From domain, sending IP, and campaign. Look for the smallest segment that changed during the same period. When you have a complaint event, use the CFL evidence to locate the relevant message and apply the sender's suppression process. When you have a bounce or deferral, preserve the complete SMTP response, timestamp, recipient domain, queue ID, and source IP before interpreting an aggregate graph. After a configuration change, validate at four layers: - Confirm the published DNS record through the authoritative DNS provider and at least one public resolver. - Confirm the vendor's current DKIM verification or Sender Hub status. - Send a real message through the production path and inspect its delivered headers for the actual DKIM result. - Review DMARC aggregate reports after data accumulates to identify sources and alignment issues across the domain. ## Track the sending sources behind Yahoo's aggregate trend Yahoo Insights can show that a verified DKIM domain's delivered volume or complaint rate changed. It does not inventory every production sender sharing that domain, prove future delivery, or control Yahoo's private receiver decisions. Palisade is agentic DMARC software that analyzes DMARC aggregate-report data, identifies sending sources and authentication or alignment issues, and creates prioritized remediation tickets. It can propose the next DMARC policy step when the evidence supports it, while your team reviews the evidence and applies any DNS change. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=existing_content_migration&utm_content=what-sender-data-does-yahoo-postmaster-provide) ## Sources and further reading - [Yahoo Sender Hub FAQ](https://senders.yahooinc.com/faqs/) - [Yahoo Complaint Feedback Loop documentation](https://senders.yahooinc.com/complaint-feedback-loop/) - [Yahoo SMTP error-code reference](https://senders.yahooinc.com/smtp-error-codes/) - [Yahoo Email Deliverability and Performance Feeds](https://senders.yahooinc.com/email-deliverability-performance-feeds/) ## Frequently asked questions ### Does Yahoo Sender Hub provide a sender reputation score? No. Yahoo's standard Sender Hub Insights documentation identifies delivered volume and spam complaint rate for verified DKIM domains. Those signals can support investigation, but Yahoo does not document a universal reputation grade in Insights. ### Does Yahoo Insights show inbox placement? Not for each individual message. Yahoo says its spam complaint-rate calculation uses inbox-delivered messages, but the standard Insights view is an aggregate trend. It does not prove the folder placement of a specific message. ### Does Yahoo's Complaint Feedback Loop work by IP address? No. Yahoo's current documentation says CFL enrollment is based on the DKIM signing domain. Yahoo no longer offers an IP- or CIDR-based complaint feedback loop. ### Do I need to enroll in the Complaint Feedback Loop to use Insights? No. Yahoo's Sender Hub FAQ says CFL enrollment is not required to view Insights. They are separate services with different evidence: aggregate trends in Insights and complaint events through CFL. ### Can several brands appear in one Yahoo Insights view? Yes. If several sending programs use the same verified DKIM signing domain, Yahoo groups their data under that selected DKIM domain. Use first-party campaign and From-domain data to isolate the stream behind a change. --- # How does DNS poisoning work and how can teams defend against it? Canonical: https://www.palisade.email/learning/whatisdnspoisoning > DNS poisoning works when a resolver caches a forged DNS answer. Learn how cache poisoning redirects users and how to validate and defend DNS. DNS poisoning, also called DNS cache poisoning, works when an attacker causes a recursive DNS resolver to cache a forged answer for a domain. Users of that resolver can then be sent to an attacker-controlled IP address until the cached data expires or is removed. Teams defend against it with DNSSEC validation, hardened resolvers, encrypted resolver connections, and checks that compare resolver answers with authoritative DNS. ## Quick takeaways - DNS cache poisoning puts forged DNS data in a recursive resolver's cache. - A forged response must arrive before the legitimate response and match values the resolver expects. - Source-port randomization and transaction-ID randomness make forged responses harder to guess, but they do not authenticate DNS data. - DNSSEC lets validating resolvers reject unsigned or incorrectly signed answers for signed zones. - DNS over HTTPS and DNS over TLS protect the client-to-resolver path, not a compromised resolver or authoritative DNS account. - A public lookup can reveal a current DNS difference, but it cannot prove the production resolver path or future DNS state. ## How DNS poisoning works A recursive resolver receives a DNS question, obtains an answer from authoritative DNS infrastructure, and caches that answer for its time to live, or TTL. The cache lets the resolver answer later requests without querying the authoritative server again. Cache poisoning occurs when the resolver accepts fabricated DNS data as though it came from an authoritative server. [RFC 5452's guidance for resisting forged DNS answers](https://datatracker.ietf.org/doc/html/rfc5452) explains that a forged response must match the pending query's question, transaction ID, destination address, and source port. An attacker tries to send enough plausible responses before the legitimate answer arrives. If the forged answer is cached, the impact can extend beyond one device. Every client using that resolver can receive the false answer until the resolver discards it. The false record might point a web name at a phishing host, redirect an API endpoint, or return a fraudulent MX record for mail routing. DNS poisoning is different from a registrar or DNS-provider account takeover. In an account takeover, the attacker changes authoritative records or delegation. In cache poisoning, the authoritative record can remain correct while a resolver distributes false cached data. Both incidents can produce a mismatch between what users receive and what the domain owner intended. [DNS security guidance from NIST](https://csrc.nist.gov/pubs/sp/800/81/r3/final) treats DNSSEC, encrypted DNS, protective DNS services, and logging as separate defensive layers. That separation matters because each control addresses a different part of the DNS path. ![Decision flow for comparing a resolver answer with authoritative DNS and selecting the next DNS-poisoning response](/images/editorial/whatisdnspoisoning/whatisdnspoisoning-decision-flow.webp "1200x829") *Source: Palisade.* ## When the answer changes The right response depends on where the suspicious answer appears. - If one workstation receives an unexpected answer while authoritative DNS and independent resolvers agree, inspect that workstation's configured resolver, local hosts file, VPN, router, and endpoint security evidence. This may be a local configuration problem or an on-path issue rather than resolver cache poisoning. - If one recursive resolver returns an answer that differs from authoritative DNS, preserve the resolver response, TTL, query time, resolver address, and authoritative answer. Treat the resolver as potentially poisoned or misconfigured until its operator investigates. - If authoritative DNS returns the unexpected answer, cache flushing will not fix the incident. Review DNS-provider access, registrar access, delegation records, DNS change history, and recovery procedures. - If the zone is DNSSEC-signed and a validating resolver reports validation failure, do not bypass the failure by disabling validation. A signature or delegation problem can interrupt resolution, but accepting unvalidated data removes the integrity protection DNSSEC provides. [RFC 4033 defines the DNSSEC security model](https://datatracker.ietf.org/doc/html/rfc4033). A resolver answer can legitimately differ by geography, CDN routing, load balancing, or a planned DNS change. The usable decision rule is to compare the exact record type and queried name against the authoritative answer, then confirm whether the difference is expected in the relevant network and time window. ## A worked DNS comparison Use a domain you administer or have permission to test. First, query the recursive resolver that produced the suspicious result. Then query an authoritative nameserver for the same record. ```bash # Illustrative only. Replace the names and resolver with authorized values. # Query the resolver used by the affected client. dig www.yourdomain.com A @resolver.example.net # Query an authoritative nameserver without recursion. dig www.yourdomain.com A @ns1.yourdomain.com +norecurse # Check DNSSEC-related response information. dig yourdomain.com SOA @resolver.example.net +dnssec ``` Do not publish internal resolver names, customer domains, tokens, or full incident logs when sharing results. Compare these evidence points: - The fully qualified name and record type, such as `www.yourdomain.com A`. - The returned values and TTLs. - The responding server and query timestamp. - The `ad` flag, which indicates that a security-aware resolver authenticated data when DNSSEC validation succeeds. [RFC 4035 defines the authenticated-data flag and validator behavior](https://datatracker.ietf.org/doc/html/rfc4035). - The authoritative response and any approved DNS change record. A mismatch alone does not identify the cause. It does establish where to continue: the affected resolver, the authoritative zone, or the client path. ## What to do next Start with the evidence you have. - With a suspicious browser or application result, capture the domain, record type, time, resolver address, returned answer, and any certificate warning. Query the same name through the affected resolver and an authoritative nameserver. - With control of a recursive resolver, apply current vendor updates and verify that the resolver uses unpredictable source ports and transaction IDs. [Google Public DNS documents source-port randomization, DNS Cookies, and response checks among its resolver protections](https://developers.google.com/speed/public-dns/docs/security). Restrict recursion to authorized clients if you operate an internal resolver. - With control of the authoritative zone, evaluate DNSSEC signing and maintain the DS, DNSKEY, and signing process carefully. DNSSEC protects signed DNS data only when the chain of trust is correctly deployed and validation is enabled. - For endpoints, use an encrypted connection to a trusted resolver where your platform and policy support it. [RFC 7858 specifies DNS over TLS](https://datatracker.ietf.org/doc/html/rfc7858), while [RFC 8484 specifies DNS over HTTPS](https://datatracker.ietf.org/doc/html/rfc8484). These protocols reduce exposure between the client and resolver. They do not validate an answer from a poisoned or compromised resolver. For email domains, DNS integrity also affects [MX](/tools/mx), [SPF](/tools/spf), [DKIM](/tools/dkim), and DMARC lookups. The [email security learning center](/learning) covers the controls that depend on those records. The [DMARC checker](/tools/dmarc) can inspect DMARC records. After resolving an incident, retain authoritative and resolver responses with timestamps so the team can distinguish cached data from an authorized DNS change. ## Check the DNS answer from public resolvers Use Palisade's [DNS lookup tool](/tools/dns-lookup) to inspect the current public DNS response for the affected name and record type. Compare it with an authoritative query and the response seen by the affected client before changing DNS. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=security&utm_content=whatisdnspoisoning) Palisade can analyze DMARC aggregate-report data, identify sending sources and authentication or alignment issues, and propose a next DMARC policy step for human review. It does not prove that a DNS poisoning incident occurred, control a resolver's cache, or guarantee future DNS integrity. ## Sources and further reading - [RFC 5452: Measures for Making DNS More Resilient against Forged Answers](https://datatracker.ietf.org/doc/html/rfc5452) - [NIST SP 800-81r3: Secure Domain Name System Deployment Guide](https://csrc.nist.gov/pubs/sp/800/81/r3/final) - [RFC 4033: DNS Security Introduction and Requirements](https://datatracker.ietf.org/doc/html/rfc4033) - [Google Public DNS security documentation](https://developers.google.com/speed/public-dns/docs/security) - [RFC 7858: Specification for DNS over Transport Layer Security](https://datatracker.ietf.org/doc/html/rfc7858) ## Frequently asked questions ### Can DNS poisoning affect only one computer? Yes. A local DNS setting change, malicious hosts-file entry, compromised router, or on-path interference can affect one computer or network. Cache poisoning at a shared recursive resolver can affect every client that uses that resolver. ### Does DNSSEC stop every DNS attack? No. DNSSEC helps validating resolvers detect forged DNS data for correctly signed zones with an intact chain of trust. It does not prevent DNS-provider account compromise, registrar compromise, endpoint malware, or an attacker changing legitimate authoritative records. ### Does DNS over HTTPS prevent cache poisoning? No. DNS over HTTPS encrypts DNS traffic between a client and its resolver. It does not make a compromised or poisoned resolver trustworthy, and it does not replace DNSSEC validation. ### Should a team flush DNS caches after finding a mismatch? Only after preserving evidence and determining the likely source of the mismatch. Flushing a cache can remove malicious cached data, but it cannot correct an authoritative record that was changed or fix a compromised client or router. ### Can DNS poisoning redirect email? Yes. A poisoned answer for an MX record can redirect where a sending system attempts delivery. DNS integrity also matters for SPF, DKIM, and DMARC record lookups, although a public lookup alone does not prove the exact production mail path. --- # How to validate SPF record syntax Canonical: https://www.palisade.email/learning/validate-spf-syntax > Validate SPF syntax by checking the DNS TXT record's v=spf1 version tag, mechanism grammar, and the 10 DNS-lookup limit defined in RFC 7208. An SPF record's syntax is valid when it is published as a DNS TXT record that begins with the exact version tag `v=spf1`, uses only the mechanisms and modifiers defined in RFC 7208, and stays inside the protocol's DNS lookup limits. A single misplaced qualifier, an unrecognized mechanism name, or a lookup count over 10 makes the whole record return a permanent error, or permerror, instead of a partial result. Validating syntax means checking the published record against this grammar before checking whether SPF is passing on real mail. ## Quick takeaways - SPF records must be published as DNS TXT (type 16) records only. The dedicated SPF resource record (type 99) was dropped from the protocol, so receivers do not need to query it. - A valid record must start with the exact version string `v=spf1`, ending at a space or the end of the record. A near match such as `v=spf10` is not a valid SPF record. - The grammar defines exactly eight mechanisms: `all`, `include`, `a`, `mx`, `ptr`, `ip4`, `ip6`, and `exists`. A token outside that list breaks the grammar. - Any single syntax error anywhere in the record makes evaluation return permerror for the whole record, with no partial credit for the parts that were written correctly. - Terms that trigger a DNS query, `include`, `a`, `mx`, `ptr`, `exists`, and `redirect`, are capped at 10 total per evaluation. Exceeding that cap also returns permerror. - A domain must not publish more than one SPF record that an authorization check would select. Zero matching records returns "none"; more than one returns permerror. ## How SPF syntax validation works [RFC 7208 defines SPF](https://www.rfc-editor.org/rfc/rfc7208) as a DNS-published policy that a receiving mail system evaluates through a function called `check_host()`. Validating syntax means confirming that a published record parses correctly under that function's grammar, before asking whether any particular message passes. The record must exist as a TXT record. [RFC 7208 Section 14.1](https://www.rfc-editor.org/rfc/rfc7208#section-14.1) notes that a dedicated SPF resource record type (type 99) was defined early in the protocol's life but dropped, because migration to it was judged very unlikely. Publishing SPF as anything other than a TXT record is not part of the current specification. Inside that TXT string, the record must open with a version section of exactly `v=spf1`. [RFC 7208 Section 4.5](https://www.rfc-editor.org/rfc/rfc7208#section-4.5) treats the version section as ending at the first space or at the end of the record, so a string that only starts with those characters but continues differently, such as `v=spf10`, is not recognized as SPF. After the version tag, the grammar is closed. [RFC 7208 Section 4.6.1](https://www.rfc-editor.org/rfc/rfc7208#section-4.6.1) defines a record as a version followed by terms, where each term is either a directive (an optional qualifier plus one of the eight defined mechanisms) or a modifier (`redirect`, the explanation modifier `exp`, or an unrecognized `name=value` pair). Terms are separated by one or more spaces. The qualifier before a mechanism is one of `+`, `-`, `?`, or `~`, and defaults to `+` when omitted. The [SPF hub](/learning/spf) covers how these mechanisms fit into a full record; this article stops at whether the grammar itself is well formed. For a term-by-term breakdown of mechanism and qualifier meaning, see [SPF record syntax explained](/learning/spf-record-syntax-explained-mechanisms-qualifiers). An unrecognized modifier is not automatically an error. [RFC 7208 Section 6](https://www.rfc-editor.org/rfc/rfc7208#section-6) states that unrecognized modifiers must be ignored no matter where or how often they appear. There is no equivalent tolerance for mechanisms in the grammar: a token that does not match one of the eight defined mechanism names, and does not match the modifier grammar either, falls outside every production in the record syntax. That gap is what the Section 4.6 evaluation rule turns into a permerror; it is not a separately quoted forgiveness clause the way unrecognized modifiers get. ## When SPF syntax validation fails Treat a record as failing validation, and stop before checking anything downstream, when any one of these conditions is true: - **A syntax error exists anywhere in the record.** [RFC 7208 Section 4.6](https://www.rfc-editor.org/rfc/rfc7208#section-4.6) states that `check_host()` returns permerror immediately on a syntax error, "without further interpretation or evaluation." A record with nine correct terms and one broken term is still a broken record. - **More than one record is published.** [RFC 7208 Section 3.2](https://www.rfc-editor.org/rfc/rfc7208#section-3.2) requires that a domain not publish multiple records that an authorization check would select. Zero matching records produces the result "none"; more than one produces permerror. - **DNS-querying terms exceed 10.** [RFC 7208 Section 4.6.4](https://www.rfc-editor.org/rfc/rfc7208#section-4.6.4) limits `include`, `a`, `mx`, `ptr`, `exists`, and `redirect` to 10 total per evaluation. `ip4`, `ip6`, and `all` do not count toward that limit, because they resolve without a DNS query. Each `mx` or `ptr` term is also separately capped at 10 address-record lookups. - **Void lookups exceed the recommended limit.** The same section states that implementations should limit lookups that return no answer, a "void lookup," to two before returning permerror. - **A TXT character-string exceeds its bounds.** [RFC 7208 Section 3.3](https://www.rfc-editor.org/rfc/rfc7208#section-3.3) caps a single TXT character-string at 255 octets. Longer records are split across multiple strings, which receivers concatenate without inserting spaces. Record content is US-ASCII. > A permerror is not a warning. [RFC 7208 Section 8.7](https://www.rfc-editor.org/rfc/rfc7208#section-8.7) describes permerror as meaning the published records "could not be correctly interpreted" and states the condition "definitely requires DNS operator intervention to be resolved." A receiver rejecting on permerror at SMTP time is expected to use reply code 550 with enhanced status code 5.5.2, so a broken record can turn into hard rejections at enforcement, not just a missed pass. ## A worked SPF record example The record below is illustrative only. Do not publish it as written; a real record must list the domain's actual sending sources, not a documentation example. ```text v=spf1 include:spf.provider.example ip4:203.0.113.0/24 -all ``` Reading it against the grammar: - `v=spf1` is the mandatory version tag, present exactly once at the start. - `include:spf.provider.example` is a directive using the `include` mechanism. No qualifier is written before it, so it defaults to `+` (pass). `include` is a DNS-querying term and counts toward the 10-lookup limit. - `ip4:203.0.113.0/24` is a directive using the `ip4` mechanism with the reserved documentation range from RFC 5737. `ip4` does not require a DNS query, so it does not count toward the lookup limit. - `-all` is a directive using the `all` mechanism with the `-` qualifier, requesting fail for anything that reaches this term without matching an earlier one. `all` also does not query DNS. A record built from only these four terms uses one of the ten available DNS-querying lookups. A domain that chains several `include` mechanisms, each of which may itself contain further `include` or `redirect` terms, can reach the limit quickly, which is why the lookup count matters as much as the individual mechanism syntax. ![SPF record mechanisms and DNS lookup costs](/images/editorial/validate-spf-syntax/validate-spf-syntax-terms.webp "1200x1078") *Source: Palisade.* ## What to check next Work in this order once a record is in hand: - Query the domain's TXT records at the authoritative name server and at a second public resolver, and confirm exactly one record begins with `v=spf1`. - Read that record against the grammar above: version tag, only the eight defined mechanisms, valid qualifiers, and modifiers that are either `redirect`, `exp`, or an ignorable unrecognized `name=value` pair. - Count every `include`, `a`, `mx`, `ptr`, `exists`, and `redirect` term, including any reached through a chain of includes, and confirm the total is 10 or fewer. - If the record fails any of these checks, correct the DNS record directly. A permerror is a DNS-operator problem under RFC 7208, not something a receiver or sender application can work around. SPF syntax is one input into the broader email authentication picture alongside DKIM and DMARC alignment; the [email authentication overview](/learning) covers how the three fit together, and [what SPF is](/learning/what-is-spf) covers the mechanism at a higher level than the syntax rules here. ## Check SPF syntax before troubleshooting delivery further Run the domain through [Palisade's SPF Record Checker](/tools/spf) to look up the published record, validate its syntax, and count its DNS lookups without registering an account. Do this after reading the record manually so a tool result confirms, rather than replaces, what the grammar rules above already show. [Check SPF](/tools/spf) A syntax check confirms the published record parses correctly and counts its DNS lookups. It does not confirm that every legitimate sending source is included in the record, and it does not show whether a specific delivered message actually passed SPF; that requires the message's own authentication result. ## Sources and further reading - [RFC 7208: Sender Policy Framework (SPF) for Authorizing Use of Domains in Email](https://www.rfc-editor.org/rfc/rfc7208) - [Palisade SPF Record Checker](https://www.palisade.email/tools/spf) ## Frequently asked questions ### Does a valid SPF syntax check prove that mail from the domain will pass SPF? No. A syntax check confirms that the published record parses correctly under the RFC 7208 grammar. Whether a specific message passes SPF also depends on the sending IP address matching an authorized mechanism and the identifier used for the check, which a syntax check alone does not evaluate. ### Can a domain publish more than one SPF record? No. RFC 7208 requires that a domain not publish multiple records that an authorization check would select. Zero matching records returns the result "none," and more than one matching record returns permerror, the same outcome as a record with a syntax error. ### What happens after an SPF record returns permerror? A permerror means the published record could not be correctly interpreted and requires the DNS operator to fix it. RFC 7208 does not define a partial-credit outcome; a receiver rejecting on permerror at SMTP time is expected to use reply code 550 with enhanced status 5.5.2. ### Do ip4 and ip6 mechanisms count toward the 10 DNS-lookup limit? No. The lookup limit in RFC 7208 applies to `include`, `a`, `mx`, `ptr`, `exists`, and `redirect`, because those terms require a DNS query to evaluate. `ip4`, `ip6`, and `all` resolve without querying DNS and do not count toward the limit. ### Is a qualifier required before every SPF mechanism? No. RFC 7208 defines four qualifiers, `+`, `-`, `?`, and `~`, and states that the qualifier defaults to `+` when a mechanism is written without one. A bare mechanism name such as `include:spf.provider.example` is treated the same as `+include:spf.provider.example`. --- # SMTP vs IMAP vs POP3: what's the difference? Canonical: https://www.palisade.email/learning/smtp-vs-imap-vs-pop3-whats-the-difference > SMTP vs IMAP vs POP3: SMTP sends mail, while IMAP syncs server mail and POP3 downloads it. Learn the secure ports and validation steps clearly. SMTP sends and relays email. IMAP and POP3 let a mail client retrieve email from a mailbox. SMTP is required for message submission and server-to-server transfer, while an account normally uses either IMAP or POP3 for access to received mail. These are IETF protocols, not a single provider rule, so there is no shared enforcement date. Use SMTP with TLS for sending, then choose IMAP for synchronized server mail or POP3 for download-oriented access. ## Quick takeaways - SMTP submits outgoing email and relays it between mail servers. - IMAP keeps the mailbox state on the server and synchronizes that state with clients. - POP3 retrieves messages for a client and does not define multi-device folder synchronization. - RFC 8314 recommends implicit TLS services for mail access and submission. - Port 587 is the message-submission port, while ports 993 and 995 are the registered implicit TLS ports for IMAP and POP3. - SMTP, IMAP, and POP3 transport mail. They do not replace sender authentication controls such as SPF, DKIM, and DMARC. ## Who is affected? Anyone configuring an email client, mailbox service, help-desk workflow, or managed email environment is affected. The sending client needs SMTP submission settings. The receiving client needs an access protocol, commonly IMAP or, in some environments, POP3. SMTP is used both by a mail user agent submitting a message and by mail transfer agents relaying it toward a destination. [RFC 5321 defines SMTP](https://www.rfc-editor.org/rfc/rfc5321), while [RFC 6409 defines the Message Submission protocol](https://www.rfc-editor.org/rfc/rfc6409) used when a client hands mail to a submission server. IMAP and POP3 apply after a mailbox service has accepted mail for a user. [RFC 9051 defines IMAP4rev2](https://www.rfc-editor.org/rfc/rfc9051), and [RFC 1939 defines POP3](https://www.rfc-editor.org/rfc/rfc1939). Neither protocol decides where another domain should receive SMTP mail. That adjacent DNS task belongs to [MX records](/learning/what-is-an-mx-record) and related [email transport security guidance](/learning/infrastructure). A webmail user may not see these settings because the browser talks to the provider's web application instead. The provider still uses mail protocols and storage systems behind that interface, but the user is not necessarily configuring IMAP or POP3 directly. ## What are the requirements? ### SMTP submits and relays messages SMTP is a push protocol. A sending client or server opens a connection, identifies itself, supplies an envelope sender and recipient, and transfers the message data. SMTP does not provide mailbox browsing or synchronize a user's read state. ```text EHLO mailclient.yourdomain.com MAIL FROM:<sender@yourdomain.com> RCPT TO:<recipient@example.net> DATA From: sender@yourdomain.com To: recipient@example.net Subject: Illustrative SMTP message Example message content. . QUIT ``` The commands above are illustrative only. Do not use a production server without its required authentication and TLS settings. For end-user submission, RFC 6409 assigns port 587 and says a submission server **MUST** support the STARTTLS extension. A submission server can require authentication according to its local policy. Port 25 remains the SMTP relay port defined for message transfer, but it is not the normal client-submission choice. ### IMAP accesses a server mailbox IMAP lets a client access messages and mailbox state held by the server. RFC 9051 defines operations for selecting mailboxes, fetching messages, searching, and changing flags. That server-side state is why multiple IMAP clients can observe the same folders and message flags when they synchronize with the same mailbox. ```text a001 LOGIN user@example.com password a002 SELECT INBOX a003 FETCH 1:* (FLAGS) a004 LOGOUT ``` The commands are illustrative only. Do not place real passwords in a terminal transcript, ticket, or documentation. IMAP does not guarantee that every client has identical local cache behavior at every instant. A client can work from cached data while disconnected, then reconcile with the server later. The protocol's useful distinction is that the mailbox and its state remain available to clients through the server. ### POP3 retrieves messages for a client POP3 is a mailbox-access protocol with a smaller model. RFC 1939 describes authorization, transaction, and update states. A client typically lists and retrieves messages, then can mark messages for deletion before ending the session. ```text USER user@example.com PASS password STAT LIST RETR 1 QUIT ``` The commands are illustrative only. Do not use real credentials in test scripts or shared logs. POP3 does not define IMAP-style server mailbox folders, flags, or synchronized read state. A client may choose to leave retrieved messages on the server, but that is a client and server configuration decision, not equivalent to IMAP synchronization. If a team needs consistent folders and read status across laptops, phones, and webmail, IMAP is usually the better fit. ![Protocol comparison showing SMTP submission and relay, IMAP synchronization with a server mailbox, and POP3 download to a client](/images/editorial/smtp-vs-imap-vs-pop3-whats-the-difference/smtp-imap-pop3-flow.webp "1200x676") *Source: Palisade.* ### TLS protects the protocol connection [RFC 8314 recommends cleartext-free access to mail](https://www.rfc-editor.org/rfc/rfc8314). It updates the registered service ports for implicit TLS: 465 for submissions, 993 for IMAP, and 995 for POP3. It also describes STARTTLS as an upgrade mechanism for existing cleartext ports. Use the settings published by the mailbox or submission provider. The RFC registration does not prove a particular provider supports every port or authentication method. A provider can require an approved TLS version, a specific hostname, OAuth-based authentication, or another local setting. > Do not change a working mail client from IMAP to POP3 without confirming retention and backup behavior. A POP3 client can be configured to delete messages from the server after retrieval, which can make those messages unavailable to other clients. ## When does the requirement take effect? There is no one-time rollout date for SMTP, IMAP, and POP3. Each protocol is an established IETF specification used by services that choose to support it. The controlling SMTP specification is RFC 5321, published in October 2008. RFC 6409, published in November 2011, defines message submission and updates RFC 4409. IMAP4rev2 is defined by RFC 9051, published in August 2021, which obsoletes RFC 3501. POP3 remains defined by RFC 1939, published in May 1996. RFC 8314, published in January 2018, updates the TLS service-port registrations for mail access and submission. A provider can change its supported client settings independently of these publication dates. Check the provider's current setup documentation before changing hostnames, ports, TLS modes, or authentication methods. ## How do I implement the requirement? ### 1. Identify the account's sending and receiving roles Record the outgoing submission hostname and the incoming mailbox hostname supplied by the provider. Do not assume they are the same host. Use SMTP for the outgoing role. Select IMAP or POP3 only for the incoming role. An account can use SMTP plus IMAP, or SMTP plus POP3. ### 2. Select IMAP or POP3 based on mailbox behavior Choose IMAP when users need shared mailbox state across devices, server-side folders, or access through webmail and native clients. Choose POP3 only when the provider supports it and the operational intent is download-oriented access. Decide explicitly whether the client leaves messages on the server. Test that choice with a non-production mailbox first. ### 3. Configure TLS and provider-supported authentication Use the provider's documented hostname, port, TLS mode, and authentication method. RFC 8314 registers port 465 for submissions, 993 for IMAP over TLS, and 995 for POP3 over TLS. Do not disable certificate validation to work around a hostname or trust error. Correct the configured server name or resolve the provider-side certificate problem through the provider's support path. ### 4. Separate mailbox access from domain authentication SMTP transport settings do not prove that mail sent with a domain authenticates successfully. Sender authentication depends on DNS records, signing behavior, alignment, and receiver evaluation. For DNS context, review how a [CNAME differs from an A record](/learning/cname-vs-a-record-whats-the-difference) and how an [A record differs from an AAAA record](/learning/a-record-vs-aaaa-record-whats-the-difference). Those records may support mail-service configuration, but they do not replace an [MX record](/tools/mx) or a sender-authentication record. ## How do I validate compliance? Validate the configured service at four separate layers. - DNS: Resolve the provider hostname from the intended network and confirm it returns the expected address. This proves a current public name resolution result, not that the service accepts the account's credentials. - Vendor: Confirm the provider's current client-settings documentation and any account-level status page. This confirms the documented path, not a successful delivered message. - Message: Send a test message through the exact production SMTP submission path. Inspect the receiving mailbox and its raw headers to confirm the message arrived through the expected route. - DMARC: After aggregate reports accumulate, inspect the sending domain's authentication and alignment results. This identifies whether production sources are passing DMARC, which SMTP connectivity alone cannot establish. If an IMAP client connects but one device shows different message state, check that every client uses the same IMAP mailbox and that none is configured for POP3 retrieval. If SMTP submission fails, preserve the exact provider error and check the provider's documented authentication and TLS requirements before changing ports. A public [email security score](/tools/email-security-score) can inspect a domain's published email-authentication posture. It cannot test your mail-client credentials, prove a specific SMTP submission succeeded, inspect private mailbox state, or show a receiver's private delivery decision. For the distinction between a one-time check and an ongoing observation process, see [active vs passive monitoring](/learning/active-vs-passive-monitoring-whats-the-difference). ## Check the domain authentication behind SMTP sending SMTP can submit a message, but a successful connection does not show which production services pass SPF, DKIM, and DMARC alignment for the sending domain. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=email_transport_security&utm_content=smtp-vs-imap-vs-pop3-whats-the-difference) Palisade is agentic DMARC software that analyzes DMARC aggregate-report data, identifies sending sources and authentication or alignment issues, and proposes the next policy step for human review. It does not change your mail-client protocol settings, automatically change DMARC policy, or guarantee delivery or inbox placement. ## Sources and further reading - [RFC 5321: Simple Mail Transfer Protocol](https://www.rfc-editor.org/rfc/rfc5321) - [RFC 6409: Message Submission for Mail](https://www.rfc-editor.org/rfc/rfc6409) - [RFC 9051: Internet Message Access Protocol (IMAP) Version 4rev2](https://www.rfc-editor.org/rfc/rfc9051) - [RFC 1939: Post Office Protocol, Version 3](https://www.rfc-editor.org/rfc/rfc1939) - [RFC 8314: Cleartext Considered Obsolete](https://www.rfc-editor.org/rfc/rfc8314) ## Frequently asked questions ### Is SMTP used to receive email? No. SMTP transfers and submits email. A mailbox service receives SMTP-delivered mail, then a user accesses that mailbox through IMAP, POP3, webmail, or another provider interface. ### Is IMAP better than POP3? Yes. IMAP is usually the better choice when the same mailbox is used on multiple devices because it supports server mailbox state and synchronization. POP3 can fit a deliberate local-download workflow, but it does not define synchronized folders and flags across clients. ### Can I use SMTP with IMAP? Yes. This is a common configuration. SMTP handles outgoing message submission, and IMAP provides access to received mail held in the server mailbox. ### Are ports 465, 993, and 995 always required? No. RFC 8314 registers those implicit TLS ports, but the provider's current documentation controls which connection settings its service accepts. Some services also support STARTTLS on their applicable cleartext ports. ### Does TLS make SMTP mail authenticate with DMARC? No. TLS protects the connection between participating endpoints. DMARC evaluation depends on SPF and DKIM authentication, identifier alignment, and the receiver's DMARC processing of the delivered message. --- # What is an AAAA DNS record (Quad-A explained)? Canonical: https://www.palisade.email/learning/what-is-an-aaaa-dns-record-quad-a-explained > AAAA DNS records map host names to IPv6 addresses. Learn the Quad-A record format, when to publish it, and how to validate IPv6 DNS for services. An AAAA DNS record, pronounced "Quad-A", maps a host name to an IPv6 address. It is the IPv6 equivalent of an A record, which maps a name to an IPv4 address. Publish an AAAA record only when the named service can accept connections at that IPv6 address. For a dual-stack service, publish both record types so IPv4-only and IPv6-capable clients can resolve the same host. ## Quick takeaways - An AAAA record is a DNS resource record that stores an IPv6 address for a host name. - The AAAA record type is defined by [RFC 3596](https://datatracker.ietf.org/doc/html/rfc3596), a Standards Track RFC that obsoleted RFC 1886. - An IPv6 address is 128 bits and is normally written as hexadecimal groups separated by colons. - A dual-stack service can publish both A and AAAA records for the same name. - DNS resolution proves the published record, but it does not prove that the destination host accepts IPv6 connections. - Email systems that send from IPv6 need separate evidence for reverse DNS, authentication, and delivered-message behavior. ## Who is affected? AAAA records affect domain owners, hosting teams, network operators, and application teams that make a website, API, mail host, or other internet-facing service reachable over IPv6. The record applies to a specific DNS owner name. For example, an AAAA record for `www.yourdomain.com` does not create IPv6 service for `mail.yourdomain.com`. Each hostname needs the appropriate record and a reachable service behind it. A domain does not need an AAAA record merely because it has DNS or sends email. If the destination has no configured, routable IPv6 address, publishing one can direct IPv6-capable clients to a path that fails. Teams using an alias should also understand the difference between an address record and a [CNAME record](/learning/what-is-a-cname-record), which points one DNS name at another name rather than directly storing an IP address. For email-authentication work, AAAA records are adjacent infrastructure rather than an SPF, DKIM, or DMARC control. The [email authentication learning hub](/learning) covers the records and message evidence that authenticate mail. ## What are the requirements? ### An AAAA record contains an IPv6 address [RFC 3596 defines the AAAA record type](https://datatracker.ietf.org/doc/html/rfc3596) as a resource record that stores one IPv6 address in its RDATA. RFC 3596 also specifies that its type value is 28. An IPv6 address has 128 bits. [RFC 4291 defines IPv6 address text representation](https://datatracker.ietf.org/doc/html/rfc4291), including hexadecimal groups separated by colons and the `::` compression convention for one contiguous sequence of zero-valued groups. ```text ; Illustrative only. Publish the IPv6 address assigned to your own service. www.yourdomain.com. 3600 IN AAAA 2001:db8:1234:5678::10 ``` > Do not copy the example address into a live zone. `2001:db8::/32` is reserved for documentation, and your provider or network team must supply the routable IPv6 address for the service. ![AAAA record anatomy showing a hostname, TTL, record type, and illustrative IPv6 address](/images/editorial/what-is-an-aaaa-dns-record-quad-a-explained/what-is-an-aaaa-dns-record-quad-a-explained-aaaa-record.webp "1200x600") *Source: Palisade.* ### The record owner name must match the service name The left side of the record identifies the DNS name clients query. A zone editor may display the zone apex as `@`, but `@` is a provider-editor shorthand, not a literal DNS label sent to resolvers. For example, a record for `www.yourdomain.com` can direct clients to an IPv6 web endpoint, while a record for `smtp.yourdomain.com` can direct clients to a distinct IPv6 SMTP endpoint. Do not assume that an AAAA record for one name applies to every host beneath the domain. A service may have multiple AAAA records. DNS can return more than one IPv6 address for the same owner name, and the client chooses how to use the returned addresses. That DNS result does not establish that each address has the same application configuration or health. ### A dual-stack service can publish A and AAAA records together An A record contains an IPv4 address, while an AAAA record contains an IPv6 address. A host can publish both: ```text ; Illustrative only. www.yourdomain.com. 3600 IN A 192.0.2.10 www.yourdomain.com. 3600 IN AAAA 2001:db8:1234:5678::10 ``` Publishing both records does not make IPv4 and IPv6 interchangeable. Each address must route to a host that can serve the intended protocol, certificate name, and application behavior. Test the actual hostname on both address families after a change. ### An AAAA record is forward DNS, not reverse DNS An AAAA record maps a name to an IPv6 address. Reverse DNS maps an address back to a name through the `ip6.arpa` namespace. The reverse mapping uses a PTR record, which is a separate administrative control. See the related guide to [PTR records and reverse DNS](/learning/what-is-a-ptr-record) before treating a forward AAAA record as evidence that reverse DNS is configured. This distinction matters for outbound email. A public AAAA lookup can show the address a hostname publishes. It cannot show which IP address a production mail platform uses to send a specific message, whether the address has an appropriate PTR record, or whether a receiving mailbox provider accepts that mail. ## When does the requirement take effect? There is no mailbox-provider enforcement date for publishing an AAAA record. It is a DNS and IPv6 mechanism, not a sender-volume requirement. RFC 3596 was published in October 2003 as a Standards Track RFC and obsoleted RFC 1886. It remains the controlling RFC for the AAAA resource record type. RFC 4291, published in February 2006, defines the IPv6 addressing architecture and standard textual representation used for IPv6 addresses. A DNS provider may have its own interface labels and validation rules. Those are implementation details, not changes to the AAAA record standard. Confirm the current path in the provider's documentation before editing a production zone. ## How do I implement the requirement? ### 1. Confirm that the target service supports IPv6 Get the exact public IPv6 address from the hosting, network, or platform owner. Confirm that the service is configured to listen on IPv6 and that firewall and routing rules allow the intended traffic. Do not create the AAAA record first and use it to discover whether the service is ready. ### 2. Identify the exact hostname Choose the hostname clients will use, such as `www.yourdomain.com`, `api.yourdomain.com`, or `smtp.yourdomain.com`. Check existing A, AAAA, and CNAME records for that name. A name with a CNAME has DNS constraints that require the alias target to provide the address response. Do not add conflicting records without understanding the existing zone design. ### 3. Add the AAAA record in the authoritative DNS zone Create an AAAA record for the hostname and enter the assigned IPv6 address as the value. Select a TTL that fits the operational change window and your normal DNS caching policy. Record the prior DNS state before replacing an existing AAAA value. An incorrect IPv6 address can affect clients that prefer or select IPv6 even when the IPv4 service remains healthy. ### 4. Query the authoritative DNS servers Find the authoritative nameservers for the zone, then query one directly. This separates a zone-publishing problem from cache behavior at a public resolver. ```bash dig @ns1.example-dns.net AAAA www.yourdomain.com +short ``` The response should contain the intended IPv6 address. Replace `ns1.example-dns.net` with an authoritative nameserver for your own zone. ### 5. Test the hostname over IPv6 Use an IPv6-capable test network or monitoring location to request the exact hostname and protocol. For a web service, test HTTPS with the hostname so certificate and virtual-host configuration are included. ```bash curl -6 --verbose https://www.yourdomain.com/ ``` A successful DNS answer alone does not prove this request will succeed. ## How do I validate compliance? Validate an AAAA deployment in layers. First, query the authoritative server and at least one public resolver. Confirm that both return the intended IPv6 address after caches expire. Second, test the actual service over IPv6 using the hostname. For a website, verify the HTTPS request, certificate name, redirect behavior, and expected application response. For SMTP or another protocol, use a controlled test that exercises that protocol rather than a web request. Third, compare IPv4 and IPv6 behavior if the service is dual-stack. The same hostname can resolve correctly on both families while one path points to an old application release, a different certificate, or a blocked port. For email infrastructure, inspect the headers of a real message sent through the production path and then review aggregate reporting when it is available. A correct AAAA record does not prove that the sending source passes SPF, that DKIM signs the message, or that DMARC aligns. DNS text-based authentication controls have their own requirements, including [TXT records](/learning/what-is-a-txt-record). ## Check the published IPv6 record before changing production traffic If you have the hostname and need to inspect its public DNS response, use the [Palisade DNS lookup tool](/tools/dns-lookup) to check the published record before redirecting production traffic. Compare the result with an authoritative-server query and an IPv6 service test. A public DNS lookup does not prove that the destination accepts connections, that the production mail path uses that IPv6 address, or that a receiver will accept a future message. If your organization needs to track which sending sources still fail authentication or alignment across domains, [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=email_authentication&utm_content=what-is-an-aaaa-dns-record-quad-a-explained). Palisade is agentic DMARC software that analyzes DMARC aggregate-report data, identifies sending sources and authentication or alignment issues, and proposes the next policy step for human review. It does not change your DNS or DMARC policy automatically, and it cannot prove IPv6 application reachability from a published AAAA record. ## Sources and further reading - [RFC 3596: DNS Extensions to Support IP Version 6](https://datatracker.ietf.org/doc/html/rfc3596) - [RFC 4291: IP Version 6 Addressing Architecture](https://datatracker.ietf.org/doc/html/rfc4291) - [IANA DNS parameters: resource record types](https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml) - [RFC 1034: Domain names, concepts and facilities](https://datatracker.ietf.org/doc/html/rfc1034) ## Frequently asked questions ### Is an AAAA record the same as an A record? No. An A record stores an IPv4 address, while an AAAA record stores an IPv6 address. Both map a DNS name to an address, but clients use them for different IP address families. ### Do I need an AAAA record if my domain sends email? No. A domain needs an AAAA record only for a hostname that should be reachable over IPv6. If an outbound mail server sends from IPv6, validate that server's actual IPv6 path, reverse DNS, message authentication, and receiver results separately. ### Can I publish both A and AAAA records for one hostname? Yes. A dual-stack service can publish an A record and an AAAA record for the same hostname. Test both paths because each address family can reach different network or application configuration. ### Does an AAAA record create reverse DNS? No. An AAAA record is forward DNS. Reverse DNS uses PTR records in the `ip6.arpa` namespace and is normally controlled by the organization that manages the address allocation. ### Why does an AAAA record resolve but my site still fail over IPv6? The DNS record may be correct while IPv6 routing, a firewall, the application listener, TLS configuration, or the destination host is incorrect. Query DNS first, then test the exact hostname and protocol over IPv6. --- # What is an impersonation attack and how can you stop it? Canonical: https://www.palisade.email/learning/what-is-an-impersonation-attack-and-how-can-you-stop-it > An impersonation attack poses as a trusted person or domain to obtain money, data, or access. Learn how to identify, contain, and reduce email. An impersonation attack is a phishing attack in which someone pretends to be a trusted person, company, or domain to make a recipient send money, disclose information, or take another unsafe action. Stopping it requires two responses: verify unusual requests through a separate channel, then reduce forged-domain mail with DMARC and mail-provider impersonation controls. Those controls reduce risk, but they do not prove every message or request is legitimate. ## Quick takeaways - An impersonation attack can copy a person's display name, a company domain, or both. - A message can be an impersonation attempt even when it has correct spelling and professional formatting. - Confirm unexpected payment, credential, payroll, or bank-detail requests through a known phone number or another trusted channel. - DMARC helps receivers identify mail that forges a domain in the visible From address. - Look-alike domains can pass their own authentication, so DMARC alone does not stop every impersonation attempt. - Mail-provider anti-phishing controls can protect selected people and domains, then quarantine or otherwise handle detected impersonation attempts. ## How an impersonation attack works Email impersonation relies on a recipient recognizing a name, role, supplier, or domain and acting before checking the request. Microsoft describes business email compromise as phishing that uses forged trusted senders, such as financial officers, customers, or partners, to persuade recipients to approve payments, transfer funds, or reveal data. [Microsoft's anti-phishing guidance](https://learn.microsoft.com/en-us/defender-office-365/anti-phishing-protection-about) distinguishes this from broad phishing because the message is tailored around a trusted identity. The identity can be imitated in more than one way: - **Display-name impersonation** uses the name of an executive, colleague, or vendor while sending from a different address. - **Domain impersonation** uses a domain that looks similar to the real one, such as a changed character or different top-level domain. - **Direct domain spoofing** forges the legitimate domain in the visible From address. These methods have different technical controls. [Microsoft's impersonation-policy documentation](https://learn.microsoft.com/en-us/defender-office-365/anti-phishing-policies-about) defines user impersonation protection around a protected sender's email address and domain impersonation protection around domains that resemble domains the organization protects. DMARC addresses direct domain spoofing. Under [RFC 9989](https://datatracker.ietf.org/doc/html/rfc9989), DMARC evaluates whether SPF or DKIM passes with alignment to the visible From domain. A domain owner can publish a policy requesting how receivers handle messages that fail that evaluation. It does not tell a receiver that a separately registered look-alike domain is trustworthy or fraudulent. ![Decision flow showing how to treat an unexpected request based on the sender identity, authentication evidence, and out-of-band verification](/images/editorial/what-is-an-impersonation-attack-and-how-can-you-stop-it/what-is-an-impersonation-attack-and-how-can-you-stop-it-response-flow.webp "1200x829") *Source: Palisade.* For a broader view of these controls, see the [email security learning hub](/learning). ## When the answer changes The safest response depends on what the attacker is imitating and what evidence you have. If the visible From domain is your own domain, inspect DMARC, SPF, and DKIM first. A DMARC failure can support a spoofing finding, but a receiver still applies its own local handling. Microsoft notes that a composite authentication failure does not automatically mean a message is blocked because its systems consider other signals as well. See [Microsoft's explanation of anti-spoofing protection](https://learn.microsoft.com/en-us/defender-office-365/anti-phishing-protection-spoofing-about). If the sender uses a look-alike domain, a valid DMARC record on your real domain will not authenticate or reject that other domain. The message may use correctly configured authentication for its own domain while attempting to deceive the recipient. This is why recipient verification and domain-impersonation controls matter alongside DMARC. Use this decision rule: - If the request is unexpected and concerns money, credentials, payroll, tax records, bank details, or confidential data, stop and verify it through a contact method already known to be legitimate. - If the address claims to use your domain, preserve the message and examine its full headers and authentication results before drawing conclusions. - If the domain is similar to a trusted domain, report it to the security team or mail administrator. Do not reply to the message to verify it. - If the message contains a link, do not use the link as the verification path. Find the organization's site or contact details independently. A copied signature, familiar name, or expected project reference is not identity proof. The [guidance on stopping spoofing attacks](/learning/what-exactly-is-spoofing-and-how-can-you-stop-it) covers the separate task of reducing forged use of a domain. ## A worked email-impersonation check Start with the message evidence rather than the display name. In a delivered email, `Authentication-Results` records a receiver's authentication assessment. [RFC 8601](https://www.rfc-editor.org/rfc/rfc8601.html) defines this header field and its properties, including `smtp.mailfrom` and `header.d`. ```text From: Finance Director <finance-director@yourdomain.com> Reply-To: payments-review@similar-domain.example Authentication-Results: receiver.example; dmarc=fail header.from=yourdomain.com; spf=fail smtp.mailfrom=similar-domain.example; dkim=none ``` This is illustrative only. Do not publish message headers that contain customer addresses, message IDs, or other sensitive information. In this example, the visible From domain is `yourdomain.com`, while the return path is a different domain and DMARC fails. That combination should lead to containment and investigation, not a reply or payment action. The header does not establish who sent the message, whether a mailbox was compromised, or why a particular receiver made its final delivery decision. A contrasting example is a look-alike domain: ```text From: Finance Director <finance-director@yourdoma1n.example> Authentication-Results: receiver.example; dmarc=pass header.from=yourdoma1n.example; spf=pass smtp.mailfrom=yourdoma1n.example; dkim=pass header.d=yourdoma1n.example ``` A pass here can mean that the sender authenticated `yourdoma1n.example`, not that it is your organization. Compare the exact domain spelling with a known address, and verify the request outside the email thread. For executive-targeted attacks, see [what a whaling attack is and how to stop it](/learning/what-is-whaling-attack-cybersecurity). ## What to do next, based on your evidence If you have a suspicious message, preserve it and report it through your organization's incident process. Do not click links, open attachments, or continue the conversation. Contact the supposed sender through a known phone number, internal directory entry, or a separate, established conversation. If money has already moved or credentials were submitted, escalate immediately under the incident-response process. If you administer the affected domain, validate four layers before treating a control as effective: - **DNS:** Query the authoritative DNS service and a public resolver for the published DMARC record. - **Vendor:** Confirm the mail provider's current anti-phishing and impersonation policy settings. - **Message:** Send a test through the real production path and inspect the delivered message's `Authentication-Results`. - **DMARC:** Review aggregate reports after they accumulate to identify sources that fail authentication or alignment. > Do not move a DMARC policy to `quarantine` or `reject` based only on a DNS lookup. A published record does not prove that every legitimate production sender aligns. Microsoft 365 administrators can configure anti-phishing policies for specified users and domains, then choose an action for detected impersonation, including quarantine. The [Microsoft configuration guide](https://learn.microsoft.com/en-us/defender-office-365/anti-phishing-policies-mdo-configure) documents the available settings and their scope. Other mail platforms have different controls, so use the provider's current documentation for the actual policy path. ## Check the domain controls behind a suspected spoof If a suspicious email claims to come from your domain, inspect the domain's public DMARC, SPF, DKIM, and related security configuration before changing DNS. Compare the result with the message headers and your provider's detection records. [Check the email security configuration](/tools/email-security-score) A public configuration check cannot prove who sent an individual message, detect a look-alike domain, monitor future attacks, or explain a receiver's private delivery decision. If the public record is correct but reports show unknown sources, missing alignment, or later DNS drift, Palisade is agentic DMARC software that analyzes aggregate-report data, identifies sending sources and authentication or alignment issues, and creates prioritized remediation tickets. It can propose the next DMARC policy step for human review, but it does not automatically change the policy or guarantee delivery. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=email_security&utm_content=what-is-an-impersonation-attack-and-how-can-you-stop-it) ## Sources and further reading - [RFC 9989: Domain-based Message Authentication, Reporting, and Conformance](https://datatracker.ietf.org/doc/html/rfc9989) - [RFC 8601: Message Header Field for Indicating Message Authentication Status](https://www.rfc-editor.org/rfc/rfc8601.html) - [Microsoft Defender anti-phishing protection](https://learn.microsoft.com/en-us/defender-office-365/anti-phishing-protection-about) - [Microsoft Defender anti-phishing policies](https://learn.microsoft.com/en-us/defender-office-365/anti-phishing-policies-about) - [Palisade Email Security Score](/tools/email-security-score) ## Frequently asked questions ### Is an impersonation attack the same as phishing? No. Impersonation is a type of phishing that focuses on appearing to be a specific trusted person, organization, or domain. A generic phishing message may imitate a broad service, while an impersonation attack usually uses a relationship, role, or look-alike identity to increase trust. ### Can DMARC stop every impersonation attack? No. DMARC helps receivers handle messages that forge the visible From domain and fail aligned SPF or DKIM. It does not stop a separately registered look-alike domain, a compromised legitimate mailbox, or a fraudulent request sent through another channel. ### Should a recipient trust a message that passes DMARC? No. A DMARC pass confirms aligned authentication for the visible From domain under the receiver's evaluation. It does not confirm that a payment request is authorized, that the sender's mailbox is uncompromised, or that a similar-looking domain belongs to the expected organization. ### What is the first action after receiving a suspected impersonation email? Do not reply, click, open attachments, or act on the request. Preserve the message and verify the request with the supposed sender through a trusted, separate channel. Then report it through the organization's security or incident-response process. ### Can a copied display name identify an impersonation attempt? Only sometimes. A copied display name can be a warning, but it is not enough to prove fraud because legitimate messages can use familiar names. Check the full sender address, inspect headers when available, and independently verify unusual requests. ### Do mail-provider impersonation controls replace employee verification? No. Provider controls can detect and act on configured user or domain impersonation signals, but they can miss attacks or create false positives. Independent verification remains necessary for high-risk requests. --- # What is MTA-STS and how does it secure SMTP with TLS? Canonical: https://www.palisade.email/learning/what-is-mta-sts > MTA-STS is an SMTP transport policy that requires supporting senders to use authenticated TLS with a domain's authorized MX hosts. Learn how to deploy it. [MTA-STS, or Mail Transfer Agent Strict Transport Security](https://datatracker.ietf.org/doc/html/rfc8461), lets a receiving email domain tell supporting SMTP senders to use authenticated TLS when delivering mail to its authorized MX hosts. A domain publishes a DNS discovery record and an HTTPS policy file. In `enforce` mode, a supporting sender must treat mail as undeliverable if it cannot make a compliant TLS connection to a policy-authorized MX host. ## Quick takeaways - MTA-STS protects the SMTP connection to a receiving domain. It does not authenticate the visible sender of an email. - RFC 8461 is an IETF Proposed Standard published in September 2018. - A working deployment needs both an `_mta-sts` DNS TXT record and an HTTPS policy file. - The policy names permitted MX host patterns, a policy mode, and a cache lifetime. - `testing` records failures without requesting enforcement, while `enforce` requests compliant TLS from supporting senders. - TLS-RPT is separate from MTA-STS and can provide reports about TLS and policy failures. ## Who is affected? MTA-STS applies to inbound SMTP delivery for a domain that receives email and publishes an MTA-STS policy. The receiving domain owner publishes the DNS record and hosts the HTTPS policy. A sending mail transfer agent decides whether it supports RFC 8461, retrieves the policy, and applies it before delivery. The protocol addresses SMTP transport security. Historically, SMTP commonly used opportunistic TLS: a sender could continue delivery without TLS if TLS negotiation failed. Under an MTA-STS `enforce` policy, a supporting sender must require authenticated TLS and a destination MX host that matches the policy. MTA-STS does not replace SPF, DKIM, or DMARC. Those protocols help a receiving system assess whether a message is authorized by the purported sending domain. MTA-STS helps a sending system protect its connection to the receiving domain. The [infrastructure hub](/learning/infrastructure) covers the related transport controls. The policy does not compel SMTP software that does not implement MTA-STS to retrieve it. It also does not control a mailbox provider's filtering, spam classification, or inbox-placement decision. ## What are the requirements? ### The domain publishes an MTA-STS DNS discovery record RFC 8461 defines a TXT record at `_mta-sts` below the policy domain. The record contains `v=STSv1` and an `id` value. The `id` signals that the policy may have changed, so a sender can decide whether to fetch a replacement. ```text _mta-sts.yourdomain.com. IN TXT "v=STSv1; id=20260811" ``` This is illustrative only. Do not copy the example `id` as an operating process. Change the `id` when the policy content changes, and account for DNS and policy caching before assuming every supporting sender has retrieved the new policy. ![MTA-STS policy components showing DNS discovery, HTTPS policy retrieval, and authorized receiving MX hosts](/images/editorial/what-is-mta-sts/what-is-mta-sts-policy-components.webp "1200x676") *Source: Palisade.* A DNS record alone is insufficient. The record tells a sender where MTA-STS exists, but the enforcement mode, MX patterns, and cache duration are in the HTTPS policy. ### The domain hosts a policy file over HTTPS RFC 8461 specifies a fixed HTTPS retrieval URL: ```text https://mta-sts.yourdomain.com/.well-known/mta-sts.txt ``` The policy file contains `version`, `mode`, one or more `mx` fields, and `max_age`. ```text version: STSv1 mode: testing mx: mail.yourdomain.com max_age: 86400 ``` This policy is illustrative only. Replace the example MX hostname with the real receiving MX hostname or supported wildcard pattern after confirming the production mail infrastructure. The policy host needs HTTPS that a supporting sender can validate. The `mx` fields identify the hosts permitted to receive mail under the policy. They do not create mail routing records and do not replace the domain's DNS MX records. ### The policy mode controls requested sender behavior RFC 8461 defines `enforce`, `testing`, and `none` policy modes. - `enforce` tells a supporting sender that delivery requires a valid TLS connection to an MX host matching the MTA-STS policy. - `testing` tells a supporting sender to evaluate the policy and report failures, while continuing normal delivery behavior. - `none` tells a supporting sender that the domain does not request MTA-STS enforcement through the current policy. For `enforce`, RFC 8461 requires a supporting sender to validate the destination server certificate and confirm that the destination MX host matches the policy. If it cannot establish a compliant connection, the sender treats the message as undeliverable rather than falling back to unauthenticated SMTP. > Do not move to `enforce` until every active production MX host presents a certificate that validates for its SMTP hostname. A mismatch can delay or prevent delivery from supporting senders. For a closer explanation of the mode field, see [what `mode` means in an MTA-STS policy](/learning/glossary/mta-sts-mode). ### Supporting senders cache the policy The `max_age` field tells a supporting sender how long it may cache a retrieved policy. RFC 8461 uses cached policy data to preserve transport protections when a later policy lookup fails. A policy update is therefore not an immediate global switch. Plan MX changes, certificate renewals, and policy edits around the published cache lifetime. The DNS `id` indicates a changed policy, but it does not guarantee that every supporting sender has refreshed at the same time. See [what `max_age` means in an MTA-STS policy](/learning/glossary/mta-sts-max-age) for the cache-specific behavior. ## When does the requirement take effect? [RFC 8461](https://datatracker.ietf.org/doc/html/rfc8461) was published in September 2018 as an IETF Proposed Standard. It is the controlling MTA-STS specification. It did not replace an earlier MTA-STS RFC, and it does not set a universal enforcement date for all email domains. A domain's policy becomes relevant when that domain publishes the required DNS record and policy file, and when a sending system that supports RFC 8461 delivers mail to it. The effective behavior also depends on the policy's mode and any cached policy held by the sender. ## What is SMTP TLS Reporting? SMTP TLS Reporting, or TLS-RPT, is defined in [RFC 8460](https://datatracker.ietf.org/doc/html/rfc8460), published in September 2018 as a Proposed Standard alongside MTA-STS. It is the mechanism that gathers information about the TLS connections senders establish when delivering mail to a domain: a reporting sender generates a report that identifies which TLS sessions succeeded and which failed, along with the reasons behind failed connections, such as failed TLS negotiation, DNS-related issues, or problems with the MTA-STS policy itself. TLS-RPT does not make MTA-STS mandatory, and [the TLS-RPT specification guide](/learning/tls-rpt-rfc) covers the standard in full. To receive reports, the domain publishes a DNS TXT record at `_smtp._tls` that specifies where they should be delivered, including the URI that receives them. [Reviewing the reports](/learning/tls-rpt-reporting) shows whether supporting senders are reaching the domain over secure connections and points at the failures to investigate. ### The TLS report structure TLS reports are JSON documents, delivered gzipped as `application/tlsrpt+json`. A report contains these components: - Report ID: a unique identifier assigned to each report, used to track and reference it. - Date range: the start and end dates of the period the report covers. - Organization name: the reporting party that generated the report. - Contact info: how to reach the reporting party with questions. - Policies: the policies the sender evaluated for the domain. RFC 8460 defines three policy types: `sts` (MTA-STS), `tlsa` (DANE), and `no-policy-found`. For MTA-STS, this section repeats the policy file string. - Summary: the total counts of successful and failed TLS sessions during the reporting period. - Failure details: the type of each failure, such as failed TLS negotiation, a DNS-related issue, or an MTA-STS problem, plus the sending server, receiving IP, and MX hostname involved in the failed connection. The failure details are the actionable part. They identify which host and which failure type to investigate before a policy moves to `enforce`. ## How do I implement the requirement? ### 1. Inventory every production receiving MX host Retrieve the domain's MX records and identify every hostname that can receive production email. Include active failover hosts and any provider-operated host that receives mail for the domain. Compare the list with the certificate names presented during SMTP TLS negotiation. An MTA-STS policy must authorize the real destination hosts that supporting senders use. ### 2. Verify TLS and certificate behavior on each host Test each production MX host for SMTP TLS availability and certificate validation. Confirm that the certificate identity covers the hostname a sender reaches. A public DNS result can show published MX records, but it cannot prove the live certificate behavior seen from every SMTP sending path. Keep message delivery tests and mail-server logs when investigating a TLS failure. ### 3. Publish the DNS record and HTTPS policy Publish the `_mta-sts` TXT record with `v=STSv1` and a new `id`. Serve the policy at the RFC-defined HTTPS path. Begin with `testing` while you compare the policy's `mx` fields against active MX records, TLS certificates, and operational failover paths. Update the DNS `id` whenever the policy changes. ### 4. Add TLS-RPT when failure reports are needed Publish TLS-RPT separately according to [RFC 8460's SMTP TLS reporting requirements](https://datatracker.ietf.org/doc/html/rfc8460). Route reports to a monitored mailbox or processing endpoint that the team can review. Use reports to investigate policy retrieval failures, certificate failures, and MX mismatches. The absence of reports does not prove that all sending systems reached the domain successfully. ### 5. Change to `enforce` after the evidence supports it Move to `enforce` only after each active MX host has passed the TLS and certificate checks, the HTTPS policy is reachable, and the policy's MX patterns match the production path. Keep a rollback plan. If an MX migration or certificate issue appears after enforcement, restore a safe policy mode only after identifying the affected hosts and the impact on mail delivery. ## How do I validate compliance? Validate MTA-STS compliance in five separate layers, working outward from the DNS record to evidence from real sending: - Check DNS: confirm the authoritative DNS response and at least one public resolver return the intended `_mta-sts` TXT record. - Check the policy host: retrieve `/.well-known/mta-sts.txt` over HTTPS and confirm that its syntax, mode, MX patterns, and `max_age` match the intended policy. - Check SMTP TLS: test every active MX host for TLS negotiation and certificate validation under its delivery hostname. - Check sender evidence: inspect TLS-RPT reports when configured, plus SMTP logs or delivery records from the actual sending path. - Check ongoing changes: repeat the checks after MX, certificate, DNS, or mail-provider changes. Use the [MTA-STS checker](/tools/mta-sts) to inspect the public DNS record and HTTPS policy before changing the policy mode. A public checker can identify published MTA-STS configuration issues. It cannot prove every production sender supports MTA-STS, continuously test each SMTP path, or establish how a specific mailbox provider handled an individual message. ## Check the published MTA-STS policy before enforcing it Run the receiving domain through the [MTA-STS checker](/tools/mta-sts) to inspect the published DNS record and HTTPS policy. Compare the result with the domain's real MX inventory and SMTP TLS evidence before moving from `testing` to `enforce`. For teams responsible for many domains, Palisade is agentic DMARC software that analyzes DMARC aggregate-report data, identifies authentication and alignment issues, and creates prioritized remediation tickets. It can help organize the sender-authentication work that accompanies a broader domain-security program, while a human reviews the evidence and applies policy changes. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=email_authentication&utm_content=what-is-mta-sts) Palisade can also host a domain's MTA-STS policy through CNAME delegation, with the agent proposing changes and a human approving them before anything is applied. It does not prove SMTP TLS behavior for every sender or guarantee future mail delivery. ## Sources and further reading - [RFC 8461: SMTP MTA Strict Transport Security](https://datatracker.ietf.org/doc/html/rfc8461) - [RFC 8460: SMTP TLS Reporting](https://datatracker.ietf.org/doc/html/rfc8460) - [IANA MTA-STS parameter registry](https://www.iana.org/assignments/mta-sts/mta-sts.xhtml) ## Frequently asked questions ### Is MTA-STS the same as DMARC? No. MTA-STS protects the SMTP transport connection to a receiving domain's authorized MX hosts. DMARC evaluates whether a message's visible From domain aligns with SPF or DKIM authentication. ### Does MTA-STS require every sender to use TLS? No. MTA-STS applies only when a sending mail system supports RFC 8461 and retrieves the receiving domain's policy. Non-supporting SMTP systems are not compelled by the policy to enforce it. ### Does `testing` mode block email delivery? No. RFC 8461 defines `testing` mode for evaluating the policy and reporting failures while a supporting sender continues normal delivery behavior. `enforce` is the mode that requests compliant TLS before delivery. ### Can an MTA-STS policy use wildcard MX patterns? Yes. RFC 8461 permits an `mx` value with a wildcard only in the left-most label, such as `*.yourdomain.com`. The wildcard matches exactly one label before the policy domain suffix: `*.yourdomain.com` covers `mail.yourdomain.com` but not `a.b.yourdomain.com`, so it should cover only legitimate receiving hosts. ### Does TLS-RPT prove that all email delivery is working? No. TLS-RPT provides evidence from senders that generate and send reports. It cannot prove that every sender attempted delivery, that every SMTP path is healthy, or that every message reached the inbox. --- # A record vs AAAA record: what's the difference? Canonical: https://www.palisade.email/learning/a-record-vs-aaaa-record-whats-the-difference > A record vs AAAA record: A records return IPv4 addresses, while AAAA records return IPv6 addresses. Learn when to publish each DNS record type. An A record maps a DNS name to an IPv4 address, while an AAAA record maps a DNS name to an IPv6 address. Publish an A record when the service is reachable over IPv4, an AAAA record when it is reachable over IPv6, and both when it supports both address families. The authoritative definition of these DNS record types is in [RFC 1035](https://datatracker.ietf.org/doc/html/rfc1035) and [RFC 3596](https://datatracker.ietf.org/doc/html/rfc3596). ## Quick takeaways - An A record contains a 32-bit IPv4 address such as `192.0.2.10`. - An AAAA record contains a 128-bit IPv6 address such as `2001:db8::10`. - A hostname can publish both A and AAAA records at the same name. - An AAAA record should only point to an IPv6 address that accepts the intended traffic. - A and AAAA records are address records, not aliases, so they differ from a CNAME record. - For email infrastructure, an MX hostname needs usable address records for the transport paths it advertises. ## Who is affected? The DNS specification defines an A record as an Internet address resource record that holds an IPv4 address. [RFC 1035](https://datatracker.ietf.org/doc/html/rfc1035) defines the record type. [RFC 3596](https://datatracker.ietf.org/doc/html/rfc3596) defines AAAA as the DNS record type for IPv6 addresses. "AAAA" is commonly pronounced "quad-A." It does not mean that an AAAA record is an alias, a higher-priority record, or a replacement for every A record. It is a separate query type with a separate address format. The scope is hostname-to-address mapping. These records do not configure mail authentication, decide which host receives mail, or prove that an application is listening on the resolved address. MX, TXT, PTR, SPF, DKIM, and DMARC records each have separate roles. A hostname may have several A records, several AAAA records, or both types. That can support multiple reachable endpoints, provided each published address is correctly configured for the service. For related DNS concepts, see Palisade's [learning center](/learning), the explanation of [CNAME versus A records](/learning/cname-vs-a-record-whats-the-difference), and the detailed guide to [AAAA DNS records](/learning/what-is-an-aaaa-dns-record-quad-a-explained). ## Affected senders A hostname used for web, application, or mail infrastructure can publish A records, AAAA records, or both. For a mail receiving domain, begin with the hostname named in the MX record, which an [MX lookup](/tools/mx) returns along with its preference order. That hostname then needs usable address resolution for the SMTP connection path. ## What are the requirements? ### An A record contains an IPv4 address RFC 1035 defines the A record's `RDATA` as a 32-bit Internet address. IPv4 addresses are normally written as four decimal values separated by periods. ```text www.yourdomain.com. 300 IN A 192.0.2.10 ``` The example uses the documentation-only `192.0.2.0/24` address range. Do not publish the example value for a live service. Use the address assigned to the host, load balancer, or DNS provider configuration. An A query asks DNS for IPv4 address data. A resolver can use the returned address only if the client has a working IPv4 path to it. DNS does not test the application, certificate, SMTP service, or firewall for the requester. ### An AAAA record contains an IPv6 address RFC 3596 defines the AAAA record type for IPv6 addresses. Its `RDATA` is a 128-bit IPv6 address, normally written in hexadecimal notation with colons. ```text www.yourdomain.com. 300 IN AAAA 2001:db8::10 ``` The `2001:db8::/32` range is reserved for documentation. Do not publish this illustrative value in production. Obtain the real IPv6 address from the system or provider that terminates the service. An AAAA record is not a fallback record. It is a published assertion that the name is reachable through the listed IPv6 address for the intended service. If the address routes incorrectly, points to a retired host, or cannot accept the service traffic, clients that attempt IPv6 can fail even when the A record is correct. ### The records can coexist at one hostname DNS distinguishes records by owner name and record type. An A record and an AAAA record can therefore exist for the same hostname. ```text mail.yourdomain.com. 300 IN A 192.0.2.25 mail.yourdomain.com. 300 IN AAAA 2001:db8::25 ``` This dual-stack pattern lets IPv4-capable clients use the A record and IPv6-capable clients use the AAAA record. It does not require every name in a zone to have both record types. Do not confuse this with a CNAME. RFC 1034 states that if a CNAME resource record is present at a node, no other data should be present at that node. An address record can coexist with other appropriate records, but a hostname used as a CNAME target should be designed according to that rule. ![A record and AAAA record comparison showing the same hostname mapped to IPv4 and IPv6 documentation addresses](/images/editorial/a-record-vs-aaaa-record-whats-the-difference/a-record-vs-aaaa-record-whats-the-difference-records.webp "1200x442") *Source: Palisade.* ## When does the requirement take effect? [RFC 1035](https://datatracker.ietf.org/doc/html/rfc1035), published in November 1987, defines the DNS A record format. It remains the controlling RFC for that record type. [RFC 3596](https://datatracker.ietf.org/doc/html/rfc3596), published in October 2003, defines the AAAA record and replaces the IPv6 address record specification in RFC 1886. RFC 3596 is a Proposed Standard RFC, not a draft. The record definitions do not have a provider enforcement date. A hosting provider, CDN, email platform, or application can have its own current interface and validation behavior. Check that provider's documentation before changing a production DNS zone. ## How do I implement the requirement? ### 1. Identify the hostname's actual network endpoints Start with the hostname that clients will connect to, such as `www.yourdomain.com` or `mail.yourdomain.com`. Confirm whether the service has a working IPv4 address, IPv6 address, or both. Use the addresses provided by the host, load balancer, CDN, or mail infrastructure. Do not infer IPv6 support from an application setting alone. For a mail receiving domain, begin with the hostname named in the MX record. RFC 5321 says an MX record's exchange value must be a domain name, not an IP address. That hostname then needs usable address resolution for the SMTP connection path. ### 2. Publish the A record for the IPv4 endpoint Create or update the A record at the hostname with the production IPv4 address. Set the TTL according to the change window and the DNS provider's operating guidance. If the hostname already has an A record, determine whether it represents a second active endpoint or an old address. Leaving an obsolete A record can send some clients to a host that no longer serves the application. ### 3. Publish the AAAA record only for a working IPv6 endpoint Create the AAAA record if the hostname has a production-ready IPv6 endpoint. Confirm that routing, firewall rules, and the service itself accept IPv6 connections. > Do not add an AAAA record only because IPv6 looks desirable. A published but unreachable IPv6 address can create connection failures that an IPv4-only test does not reveal. If the service does not support IPv6, leave the AAAA record absent. That is preferable to publishing an address that does not provide the expected service. ### 4. Keep address records aligned with infrastructure changes When an endpoint moves, review A and AAAA records separately. A migration can update IPv4 while leaving an old IPv6 address in place, or the reverse. If DNS is managed by a provider or infrastructure-as-code repository, make the address-family ownership clear. The operational question is not whether two records have similar names. It is whether both resolved addresses lead to the current service. ## How do I validate compliance? Validate DNS first. Query the exact hostname for both record types against the authoritative DNS service and at least one public resolver. ```bash dig A mail.yourdomain.com dig AAAA mail.yourdomain.com ``` The expected result depends on the design. A dual-stack hostname should return the intended IPv4 and IPv6 addresses. An IPv4-only hostname should return the intended A record and no unintended AAAA record. Then validate the service over each published address family. For a web service, test a real HTTPS connection over IPv4 and IPv6. For a mail exchanger, test the SMTP path and the server identity on the relevant address family. A correct DNS response does not prove that an application accepts traffic. For email, validate the vendor and message layers separately. Confirm the sending or receiving platform recognizes the intended hostname. Then inspect a real message from the exact production path, including its delivery behavior and authentication results where applicable. Once mail has flowed, DMARC aggregate reports can show which sending sources use the domain, but DMARC reporting does not validate a website's A or AAAA record. A public [DNS lookup tool](/tools/dns-lookup) can inspect the published A and AAAA answers before you change a service configuration. It cannot prove the production application's behavior, a mail receiver's private decision, future DNS state, or end-to-end delivery. ## Inspect the published address records before changing mail infrastructure Before changing an MX host, SMTP endpoint, or related DNS entry, inspect the hostname's published A and AAAA records. Compare the result with the addresses and service paths your provider says are active. [Inspect A and AAAA DNS records](/tools/dns-lookup) A public lookup checks the DNS answers visible at the time of the query. It does not prove that every production mail source is configured correctly, identify later DNS drift, or control a mailbox provider's delivery decision. For ongoing DMARC work, Palisade is agentic DMARC software that analyzes aggregate-report data, identifies sending sources and authentication or alignment issues, and proposes prioritized remediation work for human review. It does not change the DMARC policy or guarantee delivery. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=existing_content_migration&utm_content=a-record-vs-aaaa-record-whats-the-difference) ## Sources and further reading - [RFC 1035: Domain names, implementation and specification](https://datatracker.ietf.org/doc/html/rfc1035) - [RFC 3596: DNS extensions to support IP version 6](https://datatracker.ietf.org/doc/html/rfc3596) - [RFC 1034: Domain names, concepts and facilities](https://datatracker.ietf.org/doc/html/rfc1034) - [RFC 5321: Simple Mail Transfer Protocol](https://datatracker.ietf.org/doc/html/rfc5321) ## Frequently asked questions ### Is an AAAA record the same as an A record? No. Both are DNS address records, but an A record returns an IPv4 address and an AAAA record returns an IPv6 address. ### Do I need both A and AAAA records? Only when the hostname has working IPv4 and IPv6 endpoints that should accept the service traffic. An IPv4-only hostname normally needs an A record but no AAAA record. ### Can an A record and an AAAA record use the same hostname? Yes. DNS distinguishes records by type, so the same hostname can publish an A record and an AAAA record. This is a common dual-stack configuration. ### Does an AAAA record make a website or mail server use IPv6? No. It publishes an IPv6 address in DNS. The network route, firewall, and application must also accept connections over IPv6. ### Can an MX record point directly to an IPv4 or IPv6 address? No. RFC 5321 requires the MX exchange value to be a domain name. That hostname can then resolve through A records, AAAA records, or both. ### Does a DNS lookup prove email delivery will work? No. It proves only the DNS answers returned at the time of the lookup. Validate the provider configuration, a real delivered message, and DMARC reporting separately when those layers apply. --- # Advanced Email Security from GoDaddy Canonical: https://www.palisade.email/learning/advanced-email-security-godaddy > Advanced Email Security from GoDaddy is a Microsoft 365 email protection service with spam, phishing, quarantine, and encryption controls for tenants. GoDaddy Advanced Email Security is an add-on security service for eligible GoDaddy Microsoft 365 email accounts. GoDaddy documents protections for spam, phishing, malware, spoofing, and sensitive-message encryption, plus administrator controls for filtering and quarantine. It is an inbound email-security product, not proof that a tenant is configured correctly, that a specific message is safe, or that the sending domain's DMARC policy is valid. ## Quick takeaways - GoDaddy Advanced Email Security is designed for GoDaddy Microsoft 365 email customers. - GoDaddy documents anti-spam, anti-phishing, malware, spoofing, quarantine, and encryption capabilities for the service. - Administrators access the product through GoDaddy's Email & Office Dashboard, then select the Advanced Email Security sign-in action. - Spam settings include controls such as Spam Sensitivity and Inbound domain spoofing protection. - A public DMARC record is separate evidence from an inbound filtering product's settings or a mailbox's message outcome. - A quarantine or filtering decision needs portal and message evidence, not a public DNS lookup alone. ## How GoDaddy Advanced Email Security works [GoDaddy's Advanced Email Security product description](https://www.godaddy.com/en/email/secure-email) presents the service as email protection for phishing, spam, malware, and other unwanted mail. Its [product help article](https://help-center-east.dc-aws.godaddy.com/help/what-is-advanced-email-security-20148) describes the service for Microsoft 365 email and lists functions that include inbound filtering, quarantine, anti-spoofing protection, and email encryption. The practical model is an email-security gateway and policy layer. It evaluates inbound mail according to the protections and settings available in the GoDaddy service. That makes it part of a broader set of [email security controls](/learning/threats), alongside mailbox configuration, user reporting, endpoint protection, and sender-domain authentication. GoDaddy's documentation also distinguishes administrator activity from ordinary mailbox use. An administrator can access Advanced Email Security through the Email & Office Dashboard and use the documented portal controls. Users may interact with mail that reaches their mailbox, while the tenant's filtering settings and policy choices require the appropriate GoDaddy account access. This product category answers an inbound question: how a service evaluates messages delivered toward a mailbox. It does not replace the sender's responsibility to publish and maintain SPF, DKIM, and DMARC. Those controls allow receivers to evaluate whether a visible From domain aligns with authenticated mail. For that separate protocol question, see [are DMARC failure reports worth the trouble for email security](/learning/what-exactly-is-a-dmarc-failure-report-and-why-should-you-care). ## When the answer changes The right evidence depends on the question being asked. - If the question is "What capabilities does GoDaddy Advanced Email Security offer?", GoDaddy's current product and help documentation is the relevant evidence. - If the question is "Is this tenant configured to use those capabilities?", use the authenticated GoDaddy portal and the account's assigned service details. - If the question is "Why was this message filtered, quarantined, or delivered?", inspect the relevant message evidence and the tenant's portal evidence. A public DNS record cannot answer that question. - If the question is "Does this sending domain publish DMARC?", query the public DMARC TXT record. That reveals sender-domain policy, not GoDaddy's inbound filtering outcome. GoDaddy's [spam-settings instructions](https://help-center.dc-aws.godaddy.com/help/edit-advanced-email-security-spam-settings-23947) document the portal path `Security Settings` > `Email` > `Spam Settings`. The documented settings include Spam Sensitivity, Quarantine release policy, and Inbound domain spoofing protection. The names establish what GoDaddy documents for the service. They do not show which options a particular tenant has selected or whether a given message matched a policy. > Do not release or alter a quarantine policy solely because a sender claims a message is legitimate. Confirm the message, sender, recipient, and applicable tenant policy before changing a control that can affect future mail flow. The same boundary applies when comparing vendor categories. [Abnormal Email Security](/learning/abnormal-email-security) describes another named email-security product. A product name alone does not establish that two services expose the same controls, licensing, or tenant evidence. ## A decision rule for checking the right evidence Use this decision rule before treating an email-security result as proof. ```text Question: "Is GoDaddy Advanced Email Security operating as intended?" Need to verify a documented feature? Use GoDaddy's current product and help documentation. Need to verify this tenant's settings or entitlement? Sign in through the GoDaddy Email & Office Dashboard. Need to verify why one message was handled a certain way? Inspect the delivered message or quarantine evidence in the tenant context. Need to verify a sending domain's published DMARC policy? Query _dmarc.yourdomain.com through a public DNS check. ``` A DMARC record has a specific DNS location and format. This is an illustrative structure only. Do not publish copied values, reporting addresses, or records from another organization. ```text _dmarc.yourdomain.com TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com" ``` The DMARC record above can express a domain owner's requested handling for mail that fails DMARC. [RFC 9989 defines DMARC](https://datatracker.ietf.org/doc/html/rfc9989) and the relationship between DMARC evaluation, alignment, policy discovery, and reporting. It does not define GoDaddy Advanced Email Security settings, a tenant's quarantine state, or an individual inbound message verdict. ![Decision map separating GoDaddy portal settings, mailbox message evidence, and a public DMARC record](/images/editorial/advanced-email-security-godaddy/advanced-email-security-godaddy-evidence-map.webp "1200x718") *Source: Palisade.* ## What to do next Start with the evidence closest to your question. For access, GoDaddy's [Advanced Email Security sign-in instructions](https://www.godaddy.com/en-uk/help/sign-in-to-advanced-email-security-32138) direct administrators to sign in to the GoDaddy Email & Office Dashboard, open the Advanced Email Security page, and choose the sign-in action. Use that route to confirm the service is available to the account and to reach its administrative portal. For a suspected unwanted or missing message, preserve the message context before changing settings. Record the sender address, recipient address, delivery time, subject, and whether the message was delivered, quarantined, or rejected. Then compare that evidence with the applicable portal settings. A green status indicator or a published DNS record does not prove why that individual message was handled as it was. For broader security planning, use the [email threats hub](/learning/threats) to separate phishing, spoofing, malware, and sender impersonation questions. Each requires evidence from the appropriate system. ## Check the sending domain's public DMARC policy If the remaining question is whether the sender's domain publishes a DMARC policy, inspect that public DNS record before drawing conclusions about sender-domain authentication. [Check the DMARC record](/tools/dmarc) A public DMARC check cannot inspect GoDaddy Advanced Email Security settings, scan a mailbox, review a quarantine decision, or prove that an inbound message was safe. ## Sources and further reading - [GoDaddy Advanced Email Security product page](https://www.godaddy.com/en/email/secure-email) - [GoDaddy: What is Advanced Email Security?](https://help-center-east.dc-aws.godaddy.com/help/what-is-advanced-email-security-20148) - [GoDaddy: Sign in to Advanced Email Security](https://www.godaddy.com/en-uk/help/sign-in-to-advanced-email-security-32138) - [GoDaddy: Edit Advanced Email Security spam settings](https://help-center.dc-aws.godaddy.com/help/edit-advanced-email-security-spam-settings-23947) - [RFC 9989: Domain-based Message Authentication, Reporting, and Conformance](https://datatracker.ietf.org/doc/html/rfc9989) ## Frequently asked questions ### Should I activate GoDaddy Advanced Email Security? Only if your GoDaddy Microsoft 365 account is eligible for the service and its documented inbound protections fit your email-security requirements. Confirm the service assignment and available controls in the GoDaddy Email & Office Dashboard before treating it as active for a tenant. ### Is GoDaddy Advanced Email Security free? No. GoDaddy presents Advanced Email Security as an email-security product or add-on, rather than a universal free feature of every Microsoft 365 mailbox. Check GoDaddy's current account and product information for the plan and price that apply to your tenant. ### How do I log into GoDaddy Advanced Email Security? Sign in to the GoDaddy Email & Office Dashboard with an administrator account, open the Advanced Email Security page, and select the documented sign-in action. The portal path and available actions can depend on the account's assigned service and permissions. ### What is AES GoDaddy? AES is a common shorthand for GoDaddy Advanced Email Security. It is GoDaddy's documented email-security service for eligible Microsoft 365 email accounts, with protections and controls for inbound threats such as spam, phishing, malware, and spoofing. ### Does GoDaddy Advanced Email Security configure DMARC for my domain? No. GoDaddy Advanced Email Security and a domain's DMARC record answer different questions. The product handles documented inbound email-security functions, while DMARC is a sender-domain authentication policy published in DNS. Verify the DMARC record separately. ### Does a DMARC record prove GoDaddy blocked a phishing email? No. A DMARC lookup shows the sending domain's public policy record. It cannot show a GoDaddy tenant's filtering settings, explain a quarantine decision, or prove that a specific message was phishing. --- # Amazon report phishing email Canonical: https://www.palisade.email/learning/amazon-report-phishing-email > Report a suspicious Amazon email to stop-spoofing@amazon.com, learn the claims these messages make, and verify any order notice inside Amazon itself. To report a phishing email that claims to be from Amazon, do not click its links, open attachments, or use contact details inside the message. Instead, verify any claimed account issue by opening Amazon independently, then forward the suspicious email to `stop-spoofing@amazon.com`, as instructed in [Amazon's suspicious-email reporting guidance](https://aws.amazon.com/security/report-suspicious-emails/). If you entered credentials, a one-time verification code, or payment details, change course from reporting to account recovery. ## Quick takeaways - Do not reply to, click, download, open attachments in, or call a number listed in a suspicious Amazon-branded email. - Open Amazon independently rather than following a link from the message. - Amazon directs recipients to forward suspicious purported Amazon emails to `stop-spoofing@amazon.com`. - Forwarding the email preserves more useful evidence than sending only a screenshot or retyped text. - A suspicious email can be reported even if you are unsure whether it is genuine. - If you shared account credentials, a verification code, or payment details, recovery steps matter in addition to reporting. ## How Amazon phishing email reporting works A phishing email tries to persuade a recipient to disclose information, install something harmful, or follow a link controlled by someone else. In this case, the attacker uses Amazon's name, account language, order notices, delivery claims, or payment prompts to make the request look familiar. Amazon's [Report Suspicious Emails page](https://aws.amazon.com/security/report-suspicious-emails/) warns that purported Amazon messages can contain malicious links or attachments. Its reporting instruction is deliberately separate from the email itself: forward the suspicious message to `stop-spoofing@amazon.com`. That separation matters. A report address copied from a message could itself be controlled by an attacker. Use Amazon's published guidance, or independently type a known Amazon address into your browser before taking action. The safest sequence is: - Leave the email's links, buttons, attachments, and reply controls unused. - Open Amazon outside the message and check whether the claimed order, alert, or account issue appears there. - Forward the suspicious email to Amazon's published reporting address. - Take account-recovery steps if you entered a password, a one-time verification code, a payment detail, or other sensitive information. A message about Amazon Pay is a separate case. [Amazon Pay's phishing guidance](https://pay.amazon.com/help/201754760) covers scams and phishing in that service specifically, so apply it to Amazon Pay matters rather than treating it as a rule for every Amazon service or country. Either way, reach the account and service named in the message only after you have independently opened the official site. ## How to recognize an Amazon phishing scam email An Amazon phishing scam email is a message that impersonates Amazon to make you click a link, open an attachment, call a number, or hand over account details. A message can be suspicious without being conclusively proven fraudulent, and the safe handling is the same either way. These messages almost always claim one of a short list of things, because each one makes a recipient act quickly: - An order you do not recognize, or an order about to be cancelled. - A refund waiting to be claimed. - An account suspension or a locked account. - An unusual sign-in or a security alert. - A payment method that has failed. - A request to confirm or update account details. - A phone number to call about any of the above. None of the following establishes who actually sent a message: - A display name that reads "Amazon". - A familiar logo or an Amazon-styled template. - An order number, tracking number, or account reference. - A sender address that resembles an Amazon address. Amazon's [scam-prevention guidance](https://www.aboutamazon.com/news/retail/how-to-avoid-amazon-scams) directs customers to verify correspondence through the Amazon app or website rather than through the message itself. That independent check can show whether the claimed order or notice exists in the account. It does not prove the sender's intent or establish that every destination in the email is safe. Sender authentication has the same limit. SPF, DKIM, and DMARC describe whether a sender authenticated a domain. They do not establish that a private message is harmless, because a compromised or abused authenticated sender can still send harmful content. See [why phishing emails can pass SPF and DKIM](/learning/why-do-phishing-emails-pass-spf-and-dkim) for that distinction, and [how to spot fake emails and protect yourself from scams](/learning/email-address-spoofing-prevention) for signs that apply across impersonation attempts. ## When reporting is not the only action Forwarding a suspicious email is appropriate when you received it and did not interact with its contents. The answer changes when the email led to an action that exposed something valuable. Use this decision rule: - If you only received the message, do not interact with it. Verify the claim independently, then report it. - If you clicked a link but did not submit information or download anything, stop using the linked page and inspect the account independently. Review [what to do if you clicked a phishing link](/resources-post/what-to-do-if-you-clicked-on-a-phishing-link) for the next recovery actions. A [URL reputation lookup](/tools/url-reputation) can also show whether that address already appears on threat blocklists. - If Amazon shows a real matching order, notice, or account event, the underlying issue may be genuine even though the email is still not trustworthy. Continue only in the independently opened app or site, and do not go back to the email's links, buttons, or contact details. - If you entered an Amazon password, a one-time verification code, payment information, or another account detail, treat the situation as possible account compromise. A verification code counts even if you never typed a password: handing one over can be enough to let someone else into the account, so change the password as well. Use Amazon's independent account-recovery and security controls, then report the original email. - If the message reached a work mailbox, report it through your organization's security process as well. An internal team may need the original message to investigate who else received it, so send it to that process rather than to coworkers for an informal opinion. Forwarding a message with live links or attachments spreads the payload. A reported email does not prove that an Amazon account has been hacked. It reports a suspected impersonation attempt. Account compromise needs separate evidence, such as unexpected account changes, orders, payment activity, or security notifications visible after you sign in through an independently opened official site. For the broader concepts behind these messages, see [email threats and phishing guidance](/learning/threats). If the message is a general scam rather than an Amazon impersonation, [how to report email phishing scams](/learning/report-email-phishing-scams) covers wider reporting options. ## Worked example: choose the safe reporting path Suppose an email says that an Amazon order will be cancelled unless you confirm your account details. The message includes a button and an attachment. The email claims: "Confirm your account details to avoid order cancellation." The safe response, in order: - **Step 1.** Do not select the button or open the attachment. - **Step 2.** Open Amazon independently and check orders and account notices. - **Step 3.** Forward the original suspicious email to stop-spoofing@amazon.com. - **Step 4.** If account details or a one-time verification code were submitted, start recovery through the official site. The wording in the email does not establish that there is an order problem. The independent account check is the evidence step. Amazon's [official reporting instructions](https://aws.amazon.com/security/report-suspicious-emails/) establish where to send the suspicious message, while the account view reached outside the email establishes whether the claimed event exists. ![Decision flow for handling a suspicious Amazon-branded email without interacting with message links or attachments](/images/editorial/amazon-report-phishing-email/amazon-report-phishing-email-decision-flow.webp "1200x829") *Source: Palisade.* Forward the original email when possible. The full message can retain technical details that help investigators assess the report. Do not include passwords, payment card numbers, or other sensitive information in the forwarded content. > Warning: Do not use a phone number, reply address, web link, or attachment supplied by the suspicious email to report or recover the account. Find Amazon's official reporting or account path independently. ## What to do next with the evidence you have If you still have the suspicious email and did not interact with it, follow [Amazon's published suspicious-email reporting route](https://aws.amazon.com/security/report-suspicious-emails/) and forward it to `stop-spoofing@amazon.com`. Amazon's reporting page states that a recipient who believes a purported Amazon email is a forgery "may submit a report," and may "also forward phishing emails and other suspected forgeries directly to stop-spoofing@amazon.com." If you cannot forward the message, use that report form instead, reached from Amazon's own site rather than from anything in the suspicious email. If you only have a screenshot or copied text, do not reopen a malicious attachment to recreate the message. Report what you have through the official route and independently review your Amazon account for the specific claim. If you manage email for a team, keep the original message available for your security process. A phishing report can support investigation, but it does not show whether other recipients received the same campaign or whether a similar sender will appear later. ## Build a safer response path for suspicious email After you have reported the Amazon-branded message, use the [email security learning hub](/learning/threats) to review phishing-response and email-protection guidance for your organization. [Review email security guidance](/learning/threats) An educational guide cannot inspect a private Amazon email, submit Amazon's report, confirm account compromise, or replace your organization's incident-response process. ## Sources and further reading - [Amazon Web Services: Report Suspicious Emails](https://aws.amazon.com/security/report-suspicious-emails/) - [What is phishing?](/learning/what-is-phishing) - [Amazon: How to avoid Amazon scams](https://www.aboutamazon.com/news/retail/how-to-avoid-amazon-scams) - [Amazon Pay: Internet scams and phishing](https://pay.amazon.com/help/201754760) - [Palisade email security learning hub](/learning/threats) - [What to do if you clicked a phishing link](/resources-post/what-to-do-if-you-clicked-on-a-phishing-link) ## Frequently asked questions ### How do I report phishing emails to Amazon? Do not interact with the message's links or attachments. Verify any claimed account issue by opening Amazon independently, then forward the suspicious purported Amazon email to `stop-spoofing@amazon.com` under [Amazon's reporting guidance](https://aws.amazon.com/security/report-suspicious-emails/). ### Where can you report a phishing email? You can report it to the organization being impersonated, your employer's security team when it reached a work account, and relevant official reporting channels in your jurisdiction. For a purported Amazon email, that route is `stop-spoofing@amazon.com` or Amazon's report form; for another brand, use that organization's independently located official abuse route. Start with the impersonated organization's published route, not any reporting address or link included in the suspicious message. ### How will I know if my Amazon account has been hacked? You cannot tell from the phishing email alone. Independently sign in to Amazon and look for unexpected orders, account-detail changes, payment activity, or security notices. If you entered credentials, a one-time verification code, or payment details through the suspicious message, treat that as possible exposure and begin recovery through Amazon's official site. ### Should I click the link to see whether the Amazon warning is real? No. Amazon advises recipients not to open links or attachments in suspicious purported Amazon emails. Open Amazon independently and check for the claimed order, security notice, or account issue there. ### Can an email-security score confirm that an Amazon email is legitimate? No. An [email security score](/tools/email-security-score) assesses a domain's public email-security configuration. It cannot inspect a private message, prove that a specific email is legitimate, or establish whether Amazon sent it. ### How can I tell whether an email is really from Amazon? Do not judge it from the message. Open the Amazon app or type Amazon's address into a browser yourself, sign in there, and check Your Orders and account notifications for the claimed issue. If no matching order, notice, or security event appears, treat the email as a suspected forgery and report it. If a matching order, notice, or event does appear, handle it inside that independently opened session: a real underlying issue does not make the email safe to click. ### Where should I check a claimed Amazon security notice? Inside your Amazon account, not from the email. Amazon's [reporting guidance](https://aws.amazon.com/security/report-suspicious-emails/) tells recipients not to open links or attachments in a suspicious purported Amazon message, so an independently opened session is the place to confirm whether a notice exists. The exact notification format can vary by account, service, and region. ### Can SPF, DKIM, or DMARC prove that an Amazon email is safe? No. Those protocols report whether a sender authenticated a domain. They cannot establish that the content of a private message is legitimate, and an authenticated sender that has been compromised or abused can still deliver a harmful message. ### Is there an Amazon email scam going around? Amazon-branded phishing circulates continuously rather than as a single identifiable campaign, so the useful question is not whether a scam is going around but whether this message can be verified. Check the claimed order or notice inside an independently opened Amazon session, and report the message if nothing matches. --- # Bounce back email Outlook: diagnose and fix the NDR Canonical: https://www.palisade.email/learning/bounce-back-email-outlook > Bounce back email Outlook errors are non-delivery reports. Read the exact SMTP code and diagnostic text, apply the narrow repair, then retest. Bounce back email Outlook errors are usually an Outlook or Exchange Online non-delivery report, also called an NDR. The NDR's exact SMTP status code and diagnostic text determine the next action. Preserve that evidence before changing DNS, recipient details, message content, or policy. A bounce can indicate a bad recipient address, a temporary route problem, a size or quota limit, or a receiver policy decision. ## Quick takeaways - An Outlook or Exchange Online NDR is evidence about one attempted delivery path, not a general verdict on your domain. - SMTP replies beginning with `4` are temporary failures, while replies beginning with `5` indicate a permanent failure for that attempt. - The enhanced status code and diagnostic text are more useful than the word "bounce" alone. - A recipient, quota, malware, tenant-policy, or private filtering decision often needs action from an administrator or the recipient organization. - Retest with a new message through the same application, account, recipient domain, and route after the repair. - A passing public DNS check cannot explain every Outlook NDR or prove that a recipient will accept the next message. ## What does the failure mean? Microsoft describes an NDR as a message returned when Exchange Online cannot deliver a message. Its [Exchange Online NDR reference](https://learn.microsoft.com/en-us/troubleshoot/exchange/email-delivery/ndr/non-delivery-reports-in-exchange-online) directs senders to use the error code and diagnostic information to identify the cause. An NDR normally includes a reply shaped like this. The fields below are a redacted evidence pattern, not a diagnosis: ```text Delivery has failed to these recipients or groups: recipient@recipientdomain.com The email address you entered couldn't be found. Please check the recipient's email address and try to resend the message. ``` ![Microsoft example of an Exchange Online non-delivery report showing delivery failure details](/images/editorial/bounce-back-email-outlook/bounce-back-email-outlook-shot-1.png "768x432") *Source: Microsoft Learn, Exchange Online non-delivery reports.* Do not treat this example as proof that every Outlook bounce means an invalid address. Save the complete NDR, including the recipient, sending time, status code, and diagnostic text. If you administer the sender tenant, preserve the message ID and the original sender and recipient addresses in an access-controlled incident record. [SMTP defines reply classes](https://www.rfc-editor.org/rfc/rfc5321.html): a `4xx` reply is a transient negative completion reply, while a `5xx` reply is a permanent negative completion reply. [Enhanced mail-system status codes](https://www.rfc-editor.org/rfc/rfc3463.html) add detail about whether the failure concerns an address, mailbox, system, network, protocol, content, or security policy. The code still does not prove every underlying cause. A `5xx` response can show that the same unmodified attempt will not succeed, but the receiver's diagnostic text and the responsible administrator determine the repair. ![Decision flow for preserving an Outlook NDR, classifying its SMTP code and diagnostic text, assigning an owner, and retesting the same route](/images/editorial/bounce-back-email-outlook/bounce-back-email-outlook-ndr-triage.webp "1200x980") *Source: Palisade.* ## What usually causes it? ### The recipient address or mailbox is unavailable An NDR that explicitly says the recipient address could not be found points first to the address, alias, group membership, or recipient mailbox. Microsoft lists recipient-related NDR causes and recommended actions in its [Exchange Online NDR troubleshooting reference](https://learn.microsoft.com/en-us/troubleshoot/exchange/email-delivery/ndr/non-delivery-reports-in-exchange-online). Check the address against a current directory entry or confirm it directly with the recipient. Do not substitute a guessed alias. If the address is correct but the NDR identifies a recipient-side restriction, the recipient organization's administrator may need to investigate. ### The failure is temporary A `4.x.x` reply indicates a transient condition under SMTP. The cause may involve routing, a temporary server condition, or a resource issue. The correct action depends on the returned diagnostic text, not on assuming that every temporary failure is caused by the sender. Wait for the sender's normal retry behavior where it applies, then resend only after the stated temporary condition has cleared or the responsible administrator confirms a change. Repeated manual sends can create noise without adding evidence. ### The message exceeds a size, quota, or content limit Microsoft's NDR guidance includes failures related to message size, mailbox capacity, and message restrictions. An attachment, recipient limit, blocked file type, transport rule, or recipient mailbox quota can stop a message even when the address and DNS records are correct. Compare the failed message with a smaller plain-text test sent through the same account. If the smaller test succeeds, add the production content back in stages. That result is evidence of a message-specific difference. It does not identify a precise size threshold unless the NDR or administrator documentation provides one. ### A sender or recipient policy rejected the message Some NDRs identify a transport rule, security policy, authentication policy, or sender restriction. Read the Microsoft diagnostic text literally and use the named policy owner or administrator path. Do not infer that a policy rejection means spam, a compromised account, or a DMARC failure unless the NDR says so. When the NDR explicitly identifies DMARC policy, use the [DMARC rejection troubleshooting guide](/learning/email-rejected-per-dmarc-policy). That workflow is specific to authentication and alignment evidence, not a substitute for a recipient, quota, or Exchange tenant-policy investigation. ### The message was accepted but later placed in Junk Mail placed in Junk is different from an NDR. An NDR means the recipient system did not accept the message for delivery in the reported attempt. A message that Outlook accepted and later filtered remains a placement issue. See [why email can go to spam in Outlook but not Gmail](/learning/why-is-my-email-going-to-spam-in-outlook-but-not-gmail) when the message was accepted rather than rejected. ## How do I diagnose the failure? ### 1. Preserve the original NDR Forwarding an NDR can remove context, so retain the original returned message and, where available, its full headers. Record: - The exact SMTP and enhanced status code. - The complete diagnostic text. - The failed recipient address or group. - The sending account, application, time, and message ID. - Whether the message had attachments, external links, encryption, or an unusual recipient count. Redact personal data before sharing the evidence outside the people responsible for the incident. Do not edit the code or diagnostic text to make it easier to read. Exact wording can determine which Microsoft guidance applies. ### 2. Classify the reply before changing anything Start with the leading SMTP class. A `4.x.x` status means the server reported a temporary failure. A `5.x.x` status means the sender needs a change, a correction, or action from the relevant administrator before retrying the same attempt. Then classify the diagnostic text into one of these investigation paths: - Address or recipient path: confirm the mailbox, alias, distribution group, or recipient restriction. - Route or server path: examine the sending and receiving route, then use the diagnostic text to identify the service owner. - Message or quota path: compare message size, attachments, recipients, and content restrictions. - Policy path: identify the named policy and who administers it. - Authentication path: preserve the message headers and confirm the NDR actually names an authentication failure. An ESP may label a bounce "soft" or "hard," but that label is not a replacement for the Outlook NDR. [Soft and hard bounce classifications](/learning/soft-bounce-vs-hard-bounce-email) are useful for campaign handling, while the returned SMTP evidence determines this repair. ### 3. Check the sender-side trace when you administer Exchange Online For an Exchange Online tenant, Microsoft documents [message trace](https://learn.microsoft.com/en-us/exchange/monitoring/trace-an-email-message/message-trace-faq) as a way for authorized administrators to investigate a message's path. Search using the original sender, recipient, time range, and message details captured from the NDR. Use trace results to establish whether Exchange Online submitted, routed, deferred, or failed the message. Do not use a trace result as proof of the recipient provider's private filtering decision unless the available diagnostic evidence states that decision. If you do not administer the tenant, give the NDR and original send time to the organization that does. Do not request credentials or make tenant-wide policy changes for one unexplained bounce. ### 4. Run the narrowest controlled test Use the same sending account and application, but reduce variables only when the NDR points to a message, recipient, or route distinction. For a suspected attachment or size issue, send a small plain-text message to the same recipient. For a suspected recipient issue, confirm the address and retry with no changed content. > Do not remove authentication controls or loosen the DMARC policy as a general response to an Outlook bounce. That changes requested enforcement and does not repair an address, quota, route, or recipient-policy failure. If a controlled test changes the outcome, record exactly what changed. If it does not, keep the original NDR as the strongest evidence and follow the provider-specific diagnostic guidance. ### 5. Separate public DNS evidence from private delivery evidence A public check can help only when the NDR explicitly points to a public authentication or DNS configuration issue. It cannot inspect the recipient mailbox, Exchange queue, private tenant policy, message trace, or original account-specific NDR. For a broader explanation of delivery-status notifications across providers, see [Bounce-back email: how to read the error and fix the cause](/learning/bounce-back-email). Keep the Outlook or Exchange NDR beside that general guidance because its exact code and text remain the deciding evidence. ## How do I fix it? ### Correct the recipient detail or recipient-side setting When the NDR identifies an invalid or unavailable recipient, correct the address from an authoritative contact or directory source. If the recipient is a group, confirm that external senders are permitted and that the sender is allowed to use it. This repair changes recipient addressing or access, not authentication or DMARC enforcement. If the recipient organization controls the restriction, send the NDR to its administrator rather than changing your sender domain. ### Reduce the confirmed message-specific trigger When the evidence identifies size, attachment, or content restrictions, remove or replace only the confirmed trigger. A secure file-sharing method may be appropriate when an attachment is too large, but use the recipient organization's approved process where required. This repair changes message construction, not domain authentication. Test the adjusted message through the same sending account and recipient route before treating it as resolved. ### Repair the documented route or service condition For a transient route or service error, follow the owner and action stated in the NDR. If Microsoft guidance identifies an Exchange Online configuration or service condition, an authorized administrator should make the minimum change supported by that evidence. Keep the previous configuration available for rollback. A route adjustment can affect other mail flows, so verify a representative message path after the focused retest. ### Investigate an explicitly named authentication failure Only treat authentication as the cause when the NDR or trusted received-message evidence identifies it. Check the domain's published records, then compare those records with the exact sending path and message headers. A public record can be correct while an application still uses a different return path or fails to sign its messages. This repair may affect authentication or alignment. It is separate from a policy relaxation. Do not lower `p=` to make an NDR disappear. ## How do I validate the repair? Send a new message through the same Outlook or Exchange account, application, recipient domain, and message path that produced the NDR. Preserve the new result. For a recipient repair, confirm that the corrected recipient accepted the message. For a message-specific repair, repeat the original content case after changing only the confirmed trigger. Validate at the applicable layers: - DNS: if the failure named public authentication or DNS, check the authoritative record and at least one public resolver. - Vendor: use the relevant administrator evidence, such as message trace, only when an authorized tenant administrator can access it. - Message: inspect the new delivered message and its trusted receiver-added authentication results when authentication is in scope. - DMARC: after authentication-related changes, review aggregate reports once enough production data has accumulated. A successful retest proves that tested path accepted that new message. It does not guarantee future placement, prove every sender path, or reveal a receiver's private filtering rules. ## Check the public security posture only when the NDR points to it If the returned evidence explicitly identifies a public email-authentication or DNS issue, [check your domain's email security posture](/tools/email-security-score) before making a record change. Compare the result with the original NDR and a newly delivered message. An email security score cannot inspect a recipient mailbox, repair an Outlook tenant policy, view private message trace data, or prove why one recipient rejected one message. ## Sources and further reading - [Microsoft Learn: Email nondelivery reports and SMTP errors in Exchange Online](https://learn.microsoft.com/en-us/troubleshoot/exchange/email-delivery/ndr/non-delivery-reports-in-exchange-online) - [Microsoft Learn: Message Trace FAQ](https://learn.microsoft.com/en-us/exchange/monitoring/trace-an-email-message/message-trace-faq) - [RFC 5321: Simple Mail Transfer Protocol](https://www.rfc-editor.org/rfc/rfc5321.html) - [RFC 3463: Enhanced Mail System Status Codes](https://www.rfc-editor.org/rfc/rfc3463.html) - [Palisade email security score](/tools/email-security-score) ## Frequently asked questions ### How to fix email bounce back in Outlook? Read the exact Outlook or Exchange NDR first. Correct the specific cause it identifies, such as a recipient address, message restriction, temporary route condition, or named policy, then send a new message through the same path. Do not change DNS or DMARC unless the NDR specifically points to authentication or a public configuration issue. ### How do I recall a message in Outlook that's already sent? Only Outlook recall can attempt to retrieve a message after it has been sent, and its result depends on the recipient environment and whether the message has been read. Recalling a sent message does not repair an NDR because an NDR means the reported delivery attempt was not completed. ### How to set a bounce back email in Outlook? Only an administrator can configure many Exchange Online delivery and transport behaviors. A sender cannot set a generic bounce-back destination to solve an NDR. Use the returned NDR to identify whether the issue belongs to the sender, recipient, message, route, or a tenant policy owner. ### How long does it take for an email to bounce back in Outlook? It depends on the SMTP response and retry behavior. A permanent `5xx` failure can produce an NDR promptly, while a temporary `4xx` failure may be retried before a final result is returned. The delivery-status notification provides the evidence for that specific attempt. ### Does an Outlook bounce mean the message went to spam? No. An NDR indicates that the recipient system did not accept the message for delivery in the reported attempt. Spam or Junk placement applies when the message was accepted and then filtered into a mailbox folder. ### Can changing DMARC to `p=none` fix an Outlook bounce? No. Changing the DMARC policy changes the domain's requested handling for DMARC failures. It does not correct an invalid recipient, attachment restriction, mailbox quota, route problem, or recipient tenant policy. --- # Cloud based email security Canonical: https://www.palisade.email/learning/cloud-based-email-security > Cloud based email security adds a cloud-delivered protection layer around cloud mailboxes. Assess the controls included before selecting a service. Cloud based email security is a cloud-delivered protection layer used with a cloud mailbox environment, such as Microsoft 365 or Google Workspace. In practice, the term does not describe one fixed set of controls or prove a particular security outcome. Treat it as a delivery model and confirm what the selected product and plan actually protect before relying on it. ## Quick takeaways - Cloud based email security can supplement a cloud mailbox environment rather than replace it. - A vendor's feature list is not evidence that every product includes the same controls. - Inbound threats, outbound controls, human-risk features, and operational workflows need separate evaluation. - Protection claims should be checked against the selected product and plan. - Email-borne phishing, malware, and social engineering remain distinct [email security threats](/learning/threats). - A domain or public posture check cannot prove what a production mailbox service blocks or permits. ## How cloud based email security works The available evidence supports a narrow, practical description: cloud-email security vendors can offer an additional protection layer around an existing cloud email service. For example, [Guardian Digital's cloud email security page](https://guardiandigital.com) says its solutions can bolster existing email protection in Microsoft 365, Google Workspace, and Microsoft Exchange. Guardian Digital also says its solutions protect against threats "from phishing to ransomware to zero-day attacks." Those are product-specific marketing claims, not a universal definition of cloud based email security or a guarantee of protection. [KnowBe4's Email Collaboration Security offering](https://knowbe4.com) describes layered cloud defenses intended to block phishing, malware, and social-engineering attacks before inbox delivery. That supports an example of inbound cloud-email protection. It does not establish which controls every cloud security product uses, how each product is deployed, or how it will behave in a particular tenant. The useful distinction is between the mailbox platform and the added security service. A mailbox platform provides email service. A cloud-based email-security product may add controls around that service, subject to its documented scope and configuration. Teams assessing wider cloud controls can also review [how cloud security frameworks protect cloud environments](/learning/threats). ## When the answer changes The answer changes when "cloud based email security" is used as shorthand for a specific product capability. The delivery model alone does not tell you whether the service covers inbound messages, outbound messages, employee-focused controls, or the operational work needed to investigate events. Use this decision rule: - If the question is "Is this an additional cloud-delivered layer for our mailbox environment?", the vendor descriptions support that framing. - If the question is "Will it stop a specific threat?", check the product's current documentation for that threat and the plan your organization is considering. - If the question is "Does it protect our outbound mail or data?", do not infer an answer from an inbound phishing claim. - If the question is "Will it work with our exact mail flow?", validate that through the vendor's documented deployment path and your own production testing. - If the question is "Will it guarantee inbox placement or delivery?", the answer is no. Authentication and security controls can support safer email operations, but they do not control a receiver's private delivery decision. This is an inference from the Guardian Digital and KnowBe4 descriptions. Neither source documents an industry-wide capability checklist. A product evaluation should therefore separate advertised coverage from the controls your organization requires. ![Decision flow for assessing whether a cloud-based email security service covers the required mailbox environment and control area](/images/editorial/cloud-based-email-security/cloud-based-email-security-decision-rule.webp "1200x676") *Source: Palisade.* ## A worked evaluation example Suppose an IT team uses Google Workspace and is considering a cloud-based email-security service after seeing a vendor claim about phishing protection. The claim establishes only that phishing is within the vendor's stated scope. It does not establish that the service covers every phishing technique, every message path, or every mailbox configuration. Record the evaluation as a set of questions rather than a broad "protected" status: ```text Environment: Google Workspace Primary question: Does the selected service add documented phishing protection? Vendor evidence: Product documentation for the exact service and plan Required confirmation: Which inbound controls are included? Separate questions: Are outbound controls included? Are human-risk features included? Operational test: Validate the documented deployment in the organization's own mail flow ``` The example is a decision record, not a configuration. It keeps a vendor claim tied to the condition it supports. A security team should also keep email authentication separate from threat protection. DMARC, SPF, and DKIM help receivers evaluate whether a message is authorized to use a domain. They do not establish that a cloud security service will detect all malicious content or make a receiver deliver a message. For adjacent context, see [whether DMARC failure reports are worth the trouble for email security](/learning/what-exactly-is-a-dmarc-failure-report-and-why-should-you-care). ## Assess the next evidence you need Start with the evidence already available: - If you have a vendor name and plan, review its official documentation and identify the controls it explicitly includes. - If you have a public domain and need a broad starting point, use the [Palisade email security score](/tools/email-security-score) to inspect the available result before treating additional controls as a substitute for basic email security hygiene. - If you need a broader foundation before comparing products, read Palisade's [email security guide](/learning/threats). - If you are assessing a named product, keep that evaluation tied to the vendor's current documentation. A page about Abnormal email security is a separate product-specific research path. For an operational deployment, validation needs more than a public check. Confirm the documented vendor status, test messages through the exact production path, and review the evidence produced by that path. A public score or DNS result cannot prove which cloud-email controls are active, how a specific message was handled, or what a receiving system will decide later. ## Build the evaluation around your actual mailbox risk A cloud-delivered security service should be assessed against the cloud mailbox environment and the specific control area you need to verify. Start with the vendor's documented coverage, then separate inbound, outbound, human-risk, and operational requirements before treating a product claim as a control decision. [Read the email security guide](/learning/threats) An educational guide cannot verify a vendor configuration, prove that a service will block a specific message, or replace testing in your production mail flow. ## Sources and further reading - [Guardian Digital cloud email security information](https://guardiandigital.com) - [KnowBe4 Email Collaboration Security information](https://knowbe4.com) - [Palisade email security guide](/learning/threats) - [Palisade email security score](/tools/email-security-score) ## Frequently asked questions ### Is cloud based email security a replacement for a cloud mailbox platform? No. It can supplement a cloud mailbox environment with an additional protection layer, subject to the selected product's documented scope and configuration. ### Does a vendor feature list prove that every product includes the same controls? No. Product-specific claims do not establish a universal definition or show that every service includes the same controls. ### Does inbound phishing protection prove that outbound mail or data is protected? No. Inbound, outbound, human-risk, and operational controls need separate evaluation. ### Can a public domain or email security score prove what a production mailbox service blocks? No. A public score or DNS result cannot prove which cloud-email controls are active, how a specific message was handled, or what a receiving system will decide later. ### Will cloud based email security guarantee inbox placement or delivery? No. Authentication and security controls can support safer email operations, but they do not control a receiver's private delivery decision. --- # CNAME vs A record: what's the difference? Canonical: https://www.palisade.email/learning/cname-vs-a-record-whats-the-difference > CNAME vs A record: learn how A records map names to IPv4 addresses, how CNAME aliases work, and where DNS rules prohibit CNAME use for common DNS setups. An A record maps a DNS name directly to an IPv4 address. A CNAME record maps one DNS name to another DNS name, so the resolver follows the alias before retrieving the requested data. Use an A record when you have the host's IPv4 address. Use a CNAME when a service gives you a hostname to alias, provided that hostname does not need other DNS records. ## Quick takeaways - An A record returns an IPv4 address for the exact DNS name queried. - A CNAME record aliases one DNS name to a canonical target hostname. - A standard CNAME owner name cannot also hold A, AAAA, MX, TXT, or other DNS data. - A zone apex normally cannot use a standard CNAME because it must contain SOA and NS records. - An MX or NS record target must not be a CNAME alias. - DKIM selectors can use CNAME records when the email provider explicitly supplies a CNAME target. ## Who is affected? These DNS rules affect anyone publishing website, email-routing, domain-verification, or email-authentication records. They matter to internal IT teams and MSPs because a record that looks harmless in a DNS control panel can break mail routing or prevent an email service from verifying a domain. The controlling standards are [RFC 1034, Domain Names Concepts and Facilities](https://datatracker.ietf.org/doc/html/rfc1034) and [RFC 2181, Clarifications to the DNS Specification](https://datatracker.ietf.org/doc/html/rfc2181). Both are final RFCs, not drafts. RFC 2181 clarifies the CNAME restrictions that affect operational DNS changes. An A record covers IPv4. Its IPv6 counterpart is an AAAA record, explained in [A record vs AAAA record: what's the difference?](/learning/a-record-vs-aaaa-record-whats-the-difference). A CNAME is different because it does not contain an IP address. It identifies another DNS name as the canonical target. The restrictions apply to standard DNS CNAME records. Some DNS providers offer apex aliasing, ALIAS records, ANAME records, or CNAME flattening. For example, [Cloudflare documents CNAME flattening as provider behavior](https://developers.cloudflare.com/dns/cname-flattening/), not as a replacement for the DNS standard's CNAME rules. Confirm the behavior before moving a domain to another DNS provider. ## What are the requirements? ### An A record contains an IPv4 address RFC 1034 defines an A record as an address record with a 32-bit Internet address. Operationally, it gives a resolver an IPv4 address for the name it queried. ```text ; Illustrative only. Replace with values for your own domain and service. app.yourdomain.com. IN A 192.0.2.25 ``` The value in an A record is an IP address, not another hostname. An A record can coexist with other record types at the same owner name unless another record's rule prevents it. ### A CNAME record identifies a canonical hostname RFC 1034 defines a CNAME record as a canonical name for an alias. If a resolver receives a CNAME while requesting another record type, it restarts the query using the canonical target. ```text ; Illustrative only. Do not publish another service's target hostname. www.yourdomain.com. IN CNAME app.provider.example. ``` The trailing dot is zone-file notation for a fully qualified domain name. DNS control panels often add it automatically. Follow the DNS provider's input format, but copy the hostname supplied by the service exactly. ![Illustrative comparison of an A record returning an IPv4 address and a CNAME record pointing to a target hostname](/images/editorial/cname-vs-a-record-whats-the-difference/cname-vs-a-record-whats-the-difference-records.webp "1200x442") *Source: Palisade.* A CNAME can let a provider change the target hostname's A or AAAA records without requiring you to edit the alias. It does not mean the alias itself has a fixed IP address. ### A CNAME owner name cannot hold other DNS data [RFC 2181 section 10.1](https://datatracker.ietf.org/doc/html/rfc2181#section-10.1) states: "If a CNAME RR is present at a node, no other data should be present". A DNS name used as a CNAME therefore cannot also publish an A, AAAA, MX, TXT, or other record at that same name. This is a DNS rule, not a registrar preference. The zone apex, such as `yourdomain.com`, normally cannot be a standard CNAME because it must contain SOA and NS records. Use an address record, a redirect, or a documented provider-specific apex feature instead. ### MX and NS targets must not be aliases [RFC 2181 section 10.3](https://datatracker.ietf.org/doc/html/rfc2181#section-10.3) states: "The domain name used as the value of a NS or MX record must not be an alias." ```text ; Illustrative only. yourdomain.com. IN MX 10 mail.provider.example. mail.provider.example. IN A 192.0.2.50 ``` > Do not replace a mail provider's MX target with a CNAME to make DNS records look consistent. The MX target is part of the production mail-routing path. This rule concerns the hostname named in the MX or NS record's value. It does not prevent a separate DKIM selector from using a CNAME when an email provider directs you to publish one. See [what a DKIM CNAME record is and how to set it up](/learning/dkim-cname). ## When does the requirement take effect? RFC 1034 was published in November 1987. RFC 2181 was published in July 1997 and clarifies CNAME exclusivity plus the prohibition on alias targets for MX and NS records. There is no rollout date or sender-volume threshold. These are DNS protocol rules whenever you publish the records. Provider-specific features such as CNAME flattening have their own current behavior, limits, and cache handling, so the provider's documentation controls those implementation details. ## How do I implement the requirement? ### 1. Identify the exact hostname and supplied value Start with the owner name that needs a record. Publish an A record if you have an IPv4 address. Publish a CNAME only when the service gives you a target hostname. Do not derive a target from another account, a similar domain, or an old setup guide. Obtain the current value from the service that owns the destination. ### 2. Inspect records already published at that name Before creating a CNAME, inspect all records at the same owner name. A CNAME cannot coexist there with a TXT verification record, an A record, an MX record, or another record type. This is especially relevant for email authentication. A provider might assign a name such as `selector1._domainkey.yourdomain.com` for DKIM. That selector can be a CNAME, but only if it does not also need other DNS data. ### 3. Keep the zone apex separate Do not publish a standard CNAME at the zone apex. If a website provider requires apex routing, use the provider's documented approach and record that dependency for the next DNS administrator. A provider-specific alias feature may behave differently after a DNS migration. Treat it as implementation guidance, not as evidence that standard CNAME rules no longer apply. ### 4. Preserve mail-routing targets Copy MX records exactly as the receiving mail provider specifies, then [check the domain's MX records](/tools/mx) to confirm the published set matches. If you control the target zone, verify that each MX target is a real host name with address records rather than a CNAME alias. A DKIM CNAME at a selector is separate from the MX requirement. One does not justify changing the other. ### 5. Publish the change and allow caching to expire Publish one focused DNS change, then allow for the configured TTL and resolver caching. Avoid combining an alias conversion with unrelated SPF, DMARC, or MX changes. Separate changes give you clearer evidence if delivery or verification later fails. ## How do I validate compliance? Use a [DNS lookup](/tools/dns-lookup) to inspect the public answer for the exact hostname. For an A record, compare the returned IPv4 address with the intended service address. For a CNAME, compare the returned canonical target with the provider-supplied hostname and verify that the alias owner name has no other data. For a mail-routing change, inspect every MX target and verify it is not an alias. Then validate at four layers where email is affected: - DNS: Query the authoritative DNS provider and at least one public resolver after the expected cache period. - Vendor: Check the provider's current verification status if it offers one. - Message: Send a real message through the affected production path and inspect the delivered headers. - DMARC: Review aggregate-report data after it accumulates to identify sources or alignment issues that DNS answers alone cannot show. A passing public DNS lookup does not prove the production sender uses the intended configuration, that a recipient accepted the message, or that a mailbox provider will make a particular delivery decision. For the distinction between spot checks and ongoing evidence, see [active vs passive monitoring: what's the difference?](/learning/active-vs-passive-monitoring-whats-the-difference). ## Inspect the published DNS record, then track the mail path Check the exact hostname before changing records or asking a provider to reverify the domain. [Check the DNS record](/tools/dns-lookup) A DNS lookup can show the public A or CNAME answer for the name you enter. It cannot prove which production senders use the domain, monitor later DNS drift, or confirm future inbox placement. For domains with ongoing DMARC aggregate-report data, Palisade is DMARC software that analyzes reporting data, identifies sending sources and authentication or alignment issues, and creates prioritized remediation tickets. A human reviews the evidence and applies any DNS or DMARC policy change. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=existing_content_migration&utm_content=cname-vs-a-record-whats-the-difference) ## Sources and further reading - [RFC 1034: Domain Names Concepts and Facilities](https://datatracker.ietf.org/doc/html/rfc1034) - [RFC 2181: Clarifications to the DNS Specification](https://datatracker.ietf.org/doc/html/rfc2181) - [Cloudflare documentation: CNAME flattening](https://developers.cloudflare.com/dns/cname-flattening/) ## Frequently asked questions ### Is a CNAME record the same as an A record? No. An A record contains an IPv4 address. A CNAME record contains another hostname, and the resolver follows that hostname to obtain the requested DNS data. ### Can a CNAME and TXT record use the same hostname? No. RFC 2181 says that if a CNAME record exists at a node, no other DNS data should be present there. Use a different hostname when both a CNAME and TXT record are required. ### Can the root domain use a CNAME record? No. Normally, the zone apex must contain SOA and NS records, which conflicts with the standard CNAME exclusivity rule. A DNS provider may offer an apex-specific alias feature, but that is provider behavior rather than a standard CNAME. ### Can an MX record point to a CNAME? No. RFC 2181 states that the hostname used as the value of an MX record must not be an alias. Use the mail provider's specified MX target without substituting a CNAME. ### Does a DKIM record use a CNAME or TXT record? Yes. Either can be used, depending on the email provider's instructions. A provider-managed DKIM selector often uses a CNAME, while other providers publish the DKIM public key in a TXT record. Follow the provider's current setup value for the exact selector name. --- # Difference between IMAP and SMTP Canonical: https://www.palisade.email/learning/difference-between-imap-and-smtp > IMAP retrieves and manages mail stored on a server; SMTP transfers and submits outgoing mail between systems, per RFC 9051, RFC 5321, and RFC 6409. IMAP and SMTP are both mail protocols, but they cover opposite ends of the mail path. IMAP4rev2 (RFC 9051) lets a mail client read, organize, and search messages that stay stored on a server. SMTP (RFC 5321) transfers and, through RFC 6409, also submits messages between mail systems. Neither protocol replaces the other; a typical mail client uses SMTP to send and IMAP to read and file the same messages. ## Quick takeaways - SMTP (RFC 5321) transfers mail between servers and, via RFC 6409, also handles a client's outgoing message submission. - IMAP4rev2 (RFC 9051) lets a client read, organize, and search mail that stays stored on the server; it explicitly does not define how mail is sent. - Message submission uses port 587 under RFC 6409, a role separate from SMTP's original port 25 relay function. - IMAP4rev2 listens on port 143 for a cleartext connection or port 993 for Implicit TLS, per RFC 9051. - RFC 8314 recommends Implicit TLS for IMAP, POP, and SMTP submission, and asks providers to discourage, then deprecate, cleartext access. - A working mail account typically needs both protocols configured at once: SMTP (or its submission variant) to send, IMAP to retrieve and manage. ## Who is affected? Anyone configuring a mail client, troubleshooting delivery, or building mail-handling software works with both protocols, because IMAP and SMTP cover different halves of the same mail path. IMAP4rev2, defined in [RFC 9051](https://www.rfc-editor.org/rfc/rfc9051), governs the connection between a mail client and the server where a mailbox lives: reading, organizing, flagging, and searching messages that remain on the server. SMTP, defined in [RFC 5321](https://www.rfc-editor.org/rfc/rfc5321), governs how a message moves from a sending client or server toward its destination, including relay through intermediary systems. This article does not cover POP3, a separate protocol that downloads mail rather than synchronizing it in place; see [SMTP vs IMAP vs POP3: what's the difference](/learning/smtp-vs-imap-vs-pop3-whats-the-difference) for that comparison. It also does not cover proprietary mail APIs, which can sit in front of either protocol without exposing it directly to a mail client. Three roles recur across both protocols, defined in [RFC 6409](https://www.rfc-editor.org/rfc/rfc6409): - A mail user agent (MUA) is the mail client a person uses to read and send mail. - A mail submission agent (MSA) accepts outgoing messages from an MUA. - A mail transfer agent (MTA) accepts messages from an MSA or another MTA and relays them onward. ## What are the requirements? ### What SMTP defines RFC 5321 states SMTP's objective is "to transfer mail reliably and efficiently" (Section 1.1). An SMTP client with a message to send establishes a two-way transmission channel to an SMTP server (Section 2.1). That transfer can happen in a single connection or as "a series of hops through intermediary systems," and relaying mail across multiple networks is named as a core SMTP feature (Section 2.1). ```text SMTP (RFC 5321): mail transfer - Client opens a two-way channel to a receiving server - Transfer may cross multiple intermediary hops (relay) - Objective: reliable, efficient mail transfer between servers ``` ### What IMAP4rev2 defines RFC 9051 defines IMAP4rev2 as a protocol that lets a client "access and manipulate electronic mail messages on a server," treating remote mailboxes in a way "functionally equivalent to local folders" (Abstract). Its operations include creating, deleting, and renaming mailboxes, checking for new messages, removing messages, setting and clearing flags, searching, and fetching selected parts of a message. The same RFC is explicit about what IMAP4rev2 does not do: it "does not specify a means of posting mail," leaving that to a mail submission protocol such as the one in RFC 6409 (Abstract, Section 1.3). ```text IMAP4rev2 (RFC 9051): mailbox access and management - Create, delete, rename mailboxes - Check for and remove messages - Set and clear flags; search; fetch selected message parts - Does not define how mail is sent ``` ### How message submission splits from relay RFC 6409 "splits message submission from message relay." SMTP was originally defined as a transfer protocol between servers; RFC 6409 built a message submission role on the same protocol, so SMTP is now "widely used as a message submission protocol" as well (Abstract, Section 1). An MSA accepts messages from a user agent and relays them to an MTA; an MTA accepts messages from an MSA or another MTA and relays them onward (Section 2.1). Port 587 is reserved for message submission, and messages received on that port are defined to be submissions (Section 3.1). ### Which ports and encryption modes apply Current IETF guidance in [RFC 8314](https://www.rfc-editor.org/rfc/rfc8314) recommends Implicit TLS for POP, IMAP, and SMTP submission, and asks providers to discourage and then deprecate cleartext connections (Section 3). Under that guidance, the imaps service defaults to port 993 and the submissions service defaults to port 465, each starting a TLS handshake immediately on connect (Sections 3.2, 3.3). ![IMAP and SMTP port and purpose reference table showing protocol, port, RFC source, and function](/images/editorial/difference-between-imap-and-smtp/difference-between-imap-and-smtp-decision-table.webp "1200x666") *Source: Palisade.* ## When does the requirement take effect? RFC 5321 (SMTP) was published in October 2008 and remains the current Standards Track specification for mail transfer. RFC 9051 (IMAP4rev2) was published in August 2021. It is the current IMAP standard, succeeding the earlier IMAP4rev1 specification. RFC 6409 (Message Submission for Mail) was published in November 2011 and defines the current split between message submission and message relay. RFC 8314 was published in January 2018 and sets the current recommendation for Implicit TLS on IMAP, POP, and SMTP submission connections. It does not set a fixed deadline by which every provider must retire cleartext access; it directs providers to discourage, then deprecate, that access over time. ## How do I implement the requirement? ### 1. Identify which half of the mail path the task touches ![Protocol decision table for identifying whether a task relates to IMAP retrieval or SMTP submission](/images/editorial/difference-between-imap-and-smtp/difference-between-imap-and-smtp-difference-between-imap-and-smtp-protocol-decision-table.png "1600x900") *Source: Palisade.* Reading, filing, flagging, or searching mail that already reached the server is an IMAP task. Sending, relaying, or diagnosing why a message never left the outbox is an SMTP, or SMTP submission, task. Treating the two as one problem often points a fix at the wrong connection. ### 2. Match the port and TLS mode to the protocol in use Use port 993 for IMAP4rev2 over Implicit TLS, or port 143 only where a cleartext or STARTTLS connection is explicitly required. Use port 465 for message submission over Implicit TLS, or port 587 for submission that negotiates TLS with STARTTLS. Port 25 remains SMTP's server-to-server relay port and is not the port a mail client should use to submit outgoing mail. ### 3. Configure retrieval and sending as two separate connections A mail client opens one IMAP connection to read and manage the mailbox, and a separate SMTP submission connection to send. Fixing one does not fix the other. A client that can read mail over IMAP but cannot send has a separate, unrelated submission-side problem. ### 4. Confirm exact hostnames and credentials with the provider's documentation RFC 9051, RFC 5321, RFC 6409, and RFC 8314 define protocol behavior and default ports. None of them assigns a specific server hostname, authentication method, or account credential. That detail is the mail provider's decision, published in that provider's own account setup documentation. ## How do I validate compliance? Confirm each connection independently. For IMAP, connect on the expected port and confirm the TLS handshake completes before any mailbox command is issued. For SMTP submission, confirm the same on port 465 or 587, and confirm the server treats the connection as a submission rather than a relay. A successful IMAP connection is not evidence that SMTP submission works, and the reverse is also true. The two use separate connections and separate failure points. When a message fails during transfer or relay rather than during submission, that failure shows up in delivery and bounce diagnostics rather than a mailbox-access problem; see the [delivery errors troubleshooting hub](/learning/delivery-errors) for that separate failure path. DNS plays a supporting role too: the MX record for a domain tells a sending SMTP server which host to connect to, and it can be checked with the [DNS lookup tool](/tools/dns-lookup). A correct MX record does not by itself prove that the receiving host accepts the connection on the expected port or completes the TLS handshake; it only identifies where the connection attempt should go. ## See how these protocols fit into transport security IMAP and SMTP define the mail-handling protocols themselves. The encryption and certificate behavior around those same connections belongs to transport security, a related but separate layer. [Read the email transport security guide](/learning/infrastructure) That guide covers the TLS and certificate layer around SMTP and IMAP connections. It does not replace testing the actual port and TLS handshake for a specific mail client. --- Ready to ensure your mail infrastructure is secure and compliant? [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=standards_explainer&utm_content=difference-between-imap-and-smtp) with Palisade to monitor DMARC, SPF, and DKIM policies automatically. ## Sources and further reading - [RFC 5321: Simple Mail Transfer Protocol](https://www.rfc-editor.org/rfc/rfc5321) - [RFC 9051: Internet Message Access Protocol (IMAP), version 4rev2](https://www.rfc-editor.org/rfc/rfc9051) - [RFC 6409: Message Submission for Mail](https://www.rfc-editor.org/rfc/rfc6409) - [RFC 8314: Cleartext considered obsolete, use of TLS for email submission and access](https://www.rfc-editor.org/rfc/rfc8314) ## Frequently asked questions ### How do I find my IMAP and SMTP? This depends on the mail provider and account, not on the protocols themselves. Neither RFC 9051 nor RFC 5321 assigns a universal hostname; each provider publishes its own IMAP and SMTP submission server names and ports in that provider's account or help documentation. Use the port reference in this article to know what to expect once the provider's page names the host: port 993 for IMAP over Implicit TLS, and port 465 or 587 for submission. ### Is the password for IMAP and SMTP the same? Not defined by IMAP or SMTP. Neither protocol's RFC specifies how a server authenticates a client or whether IMAP and SMTP submission must share one credential. That choice belongs to the mail provider. Check the account's own setup documentation to confirm whether one password covers both connections or whether a separate one is required. ### Is SMTP used anymore? Yes. SMTP, as defined in RFC 5321, still transfers mail between servers. RFC 6409 also built the message submission variant of SMTP on top of the same protocol, splitting message submission from message relay so a mail client's outgoing connection and a server's relay connection are handled as related but distinct roles. That submission variant is what most mail clients use today to send outgoing messages. ### Should I use IMAP or SMTP? Not a choice between the two. IMAP4rev2 and SMTP handle different halves of the same mail flow: SMTP, and its message submission variant, sends and relays mail, while IMAP4rev2 reads and manages mail already stored on a server. RFC 9051 states directly that IMAP4rev2 does not define how mail is posted, so a mail client needs a submission connection for sending no matter how it is configured for retrieval. A typical account uses both protocols at once. For a broader walkthrough of what each protocol does, see [SMTP vs POP3 vs IMAP: what each protocol does](/learning/smtp-vs-imap-vs-pop3-whats-the-difference). ### What ports do IMAP and SMTP use? IMAP4rev2 listens on port 143 for a cleartext connection or port 993 for Implicit TLS, per RFC 9051. SMTP relay uses port 25, while message submission under RFC 6409 uses port 587, or port 465 when using Implicit TLS as described in RFC 8314. --- # Do subdomains inherit DMARC policy? Canonical: https://www.palisade.email/learning/dmarc-policy-for-subdomains > Do subdomains inherit DMARC policy? Yes, when no valid record exists at the subdomain, DMARC can apply parent p, sp, or np tags for DMARC failures. Yes. A subdomain can inherit an applicable DMARC policy when it does not publish a valid DMARC record of its own. DMARC first checks the visible From domain, called the Author Domain. If discovery finds an applicable parent policy domain instead, the `sp` tag can control existing subdomains, `np` can control non-existent subdomains, and `p` is the fallback when those tags are absent. This page answers the policy-discovery question: which `p`, `sp`, or `np` value applies after the RFC 9989 DNS Tree Walk. For the separate question of how relaxed and strict SPF or DKIM alignment work together, use the [`aspf` and `adkim` comparison](/resources-post/dmarc-and-subdomains-aspf-adkim-and-sp-tags-explained). For an operational strict-DKIM change, use the [`adkim` validation and rollback guide](/learning/dmarc-adkim-tag). ## Quick takeaways - A subdomain does not need its own DMARC record when the parent policy provides the intended handling. - A valid DMARC record at the exact visible From domain takes precedence over a parent policy. - The `sp` tag requests handling for existing subdomains when policy discovery selects the Organizational Domain or PSD record. - The `np` tag requests handling for non-existent subdomains under the applicable policy domain. - If `sp` or `np` is absent where applicable, DMARC falls back to the parent record's `p` value. - RFC 9989 ignores `sp` on a DMARC Policy Record published on a subdomain of an Organizational Domain or PSD. - Inherited policy does not make a sender pass DMARC. The message still needs aligned SPF or DKIM. ## `p`, `sp`, and `np` precedence at a glance | Policy discovery result | Author Domain status | Requested policy used after DMARC failure | |---|---|---| | Valid record found at the exact Author Domain | Existing or non-existent | That record's `p` | | Applicable record found at the Organizational Domain or PSD | Existing subdomain | `sp`, or `p` when `sp` is absent | | Applicable record found at the Organizational Domain or PSD | Non-existent subdomain | `np`, or `sp`, then `p`, when the more specific tag is absent | The table describes [RFC 9989 Section 4.10.1 policy discovery](https://www.rfc-editor.org/rfc/rfc9989.html#section-4.10.1). It does not guarantee a delivery outcome: the published value is a Domain Owner Assessment Policy that a Mail Receiver can consider alongside its local handling rules. ## How DMARC policy inheritance works [DMARC policy discovery in RFC 9989](https://www.rfc-editor.org/rfc/rfc9989.html#section-4.10.1) starts with the domain in the message's visible From header. For a message from `billing.example.com`, the receiver first queries `_dmarc.billing.example.com`. If it does not find a valid record there, it follows the standard's bounded DNS Tree Walk to find the Author Domain's Organizational Domain or PSD. RFC 9989 caps the walk at eight DNS queries for deeply nested names. The resulting policy record determines the requested treatment only after the message fails DMARC. A message passes DMARC when SPF or DKIM passes and the authenticated domain aligns with the visible From domain. For the broader protocol context, see [what a domain's DMARC policy means](/learning/domain-s-dmarc-policy). When a parent record supplies the policy, [RFC 9989 section 4.7 defines the relevant tags](https://www.rfc-editor.org/rfc/rfc9989.html#section-4.7): - `p` is the requested handling for DMARC failures at the policy domain and the fallback policy where no more specific applicable tag changes the result. - `sp` is the requested handling for failures using existing subdomains when the applicable record belongs to the prevailing Organizational Domain or PSD. - `np` is the requested handling for failures using non-existent subdomains of the policy domain. These tags express a domain owner's requested handling. A receiving system still applies its own local policies and makes the final delivery decision. An inherited `p=reject` request does not prove that every receiver will reject every future failing message. ![Decision flow showing whether a DMARC policy comes from an exact subdomain record or parent p, sp, and np tags](/images/editorial/dmarc-policy-for-subdomains/dmarc-policy-for-subdomains-policy-flow.webp "1200x676") *Source: Palisade.* ## When the answer changes The answer changes based on whether the subdomain exists and whether it publishes its own usable record. ### A valid record exists at the visible From domain A record published for `marketing.example.com` can govern mail that uses `marketing.example.com` in the visible From field. In that case, the parent record does not supply the policy for that Author Domain. Publishing a separate record is useful when that subdomain needs a different reporting destination, alignment setting, policy stage, or operational owner. It is not required merely because the subdomain sends mail. The exact Author Domain record uses its `p` value. Its `sp` value does not create another policy layer below that subdomain: RFC 9989 says `sp` is ignored on DMARC Policy Records published on subdomains of Organizational Domains and PSDs. ### The subdomain exists but has no valid DMARC record For an existing subdomain that inherits a parent policy record, `sp` applies if the parent record includes it. If `sp` is absent, the parent record's `p` value applies. For example, `p=reject; sp=quarantine` asks receivers to use `quarantine` for DMARC failures from existing subdomains that inherit this record, while failures from the policy domain itself receive the `reject` request. ### The subdomain does not exist For a non-existent subdomain, `np` applies when the applicable policy record includes it. If `np` is absent, the protocol uses the fallback defined by the applicable policy, which can be `sp` and then `p`. This distinction matters when a domain owner wants stronger protection against spoofing from unused names without imposing the same requested handling on legitimate active subdomains. The [meaning of the DMARC `sp` tag](/learning/glossary/dmarc-sp) is useful when reviewing the existing-subdomain case. A usable decision rule is: - Publish an explicit subdomain record only when that Author Domain needs a different policy or reporting arrangement. - Use `sp` when existing subdomains should receive a different inherited policy from the parent domain. - Use `np` when non-existent subdomains need a different inherited policy. - Keep `p` as the parent policy baseline. > Do not raise a parent `p`, `sp`, or `np` policy based on DNS alone. A policy can affect mail from many Author Domains, including low-volume production paths that a public lookup cannot reveal. ## Worked example: a parent policy with subdomain rules The following is illustrative only. Do not copy the reporting address into production. Use the address authorized for your own DMARC report processor. ```text v=DMARC1; p=quarantine; sp=reject; np=reject; rua=mailto:dmarc-reports@yourdomain.com ``` For this parent policy at `_dmarc.yourdomain.com`: - Mail using `yourdomain.com` in the visible From field receives the `quarantine` request after DMARC failure. - Mail from an existing subdomain such as `billing.yourdomain.com`, with no valid record at `_dmarc.billing.yourdomain.com`, receives the `reject` request after DMARC failure. - Mail from a non-existent subdomain such as `madeup.yourdomain.com` receives the `reject` request after DMARC failure. - A valid DMARC record at `_dmarc.billing.yourdomain.com` can supply the policy for `billing.yourdomain.com` instead. The record does not identify legitimate senders or show whether their messages align. For each active source, inspect a real delivered message's authentication results and confirm that SPF or DKIM passes with alignment to the visible From domain. [RFC 8601 defines the `Authentication-Results` header field](https://www.rfc-editor.org/rfc/rfc8601.html), which records the receiver's authentication assessment. ## Validate the policy that production mail uses Start with the evidence you have, then move through independent checks. ### If you have only a domain name Use the [Palisade DMARC checker](/tools/dmarc) to inspect the public record for the parent domain and each active visible From subdomain. Record the exact TXT values, lookup time, and DNS TTL. A public lookup can show what DNS publishes, but it cannot prove that an application sends through the expected path or that a receiver applied the requested policy. Query authoritative DNS and at least one public resolver after any change. Resolver caching can delay the result seen by different receivers. ### If you manage a sending application Check the sending provider's current authentication status for the exact production domain. Then send a real message through that application to a mailbox where you can inspect the full headers. Confirm the visible From domain, the SPF and DKIM results, and alignment in `Authentication-Results`. A green provider status is useful vendor evidence. It is not proof that the delivered production message used the configured return path or DKIM signing domain. ### If you receive DMARC aggregate reports Review reports after sufficient production traffic accumulates. Group the data by `header_from` domain so parent-domain traffic and subdomain traffic do not blend together. Look for legitimate sources that fail SPF or DKIM alignment before moving an inherited policy toward `quarantine` or `reject`. Palisade is agentic DMARC software that analyzes DMARC aggregate-report data, identifies sending sources and authentication or alignment issues, and creates prioritized remediation tickets. It can propose the next policy step when a domain appears ready, while a human reviews the evidence and applies the DNS change. ## Check the public policy before changing subdomain handling Inspect the parent domain and the exact visible From subdomain before deciding whether inheritance is the issue. Compare the published tags with delivered-message headers and aggregate reports, especially when a subdomain is sent by a separate application. [Check the DMARC policy](/tools/dmarc) A public DMARC check does not prove which production sources still fail alignment, whether a receiver applied a local exception, or whether every future message will authenticate. When reports show an ongoing cross-domain inventory and remediation problem, [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=email_authentication&utm_content=dmarc-policy-for-subdomains) to analyze aggregate-report evidence and prioritize the remaining work. Palisade proposes policy steps, but your team reviews the evidence and applies any DNS change. ## Sources and further reading - [RFC 9989: Domain-based Message Authentication, Reporting, and Conformance](https://www.rfc-editor.org/rfc/rfc9989.html) - [RFC 9989 section 4.7: DMARC policy tag definitions](https://www.rfc-editor.org/rfc/rfc9989.html#section-4.7) - [RFC 9989 section 4.10.1: DMARC Policy Discovery](https://www.rfc-editor.org/rfc/rfc9989.html#section-4.10.1) - [RFC 8601: Authentication-Results header field](https://www.rfc-editor.org/rfc/rfc8601.html) - [Palisade DMARC checker](/tools/dmarc) ## Frequently asked questions ### Does every sending subdomain need its own DMARC record? No. A sending subdomain can inherit an applicable parent DMARC policy when it has no valid record of its own. It still needs aligned SPF or DKIM for its messages to pass DMARC. ### Does `sp` override `p` for every subdomain? No. The `sp` tag applies to existing subdomains that inherit the applicable parent policy. A valid DMARC record at the exact Author Domain can supply that domain's policy instead. ### What happens if the parent record has no `sp` tag? The applicable parent `p` value is used for an existing subdomain that inherits the parent policy. The receiver still makes the final local handling decision. ### Can `np` protect unused subdomains? Yes. The `np` tag can request handling for DMARC failures from non-existent subdomains under the applicable policy domain. It does not authenticate messages or prove that a receiver will take a particular action. ### Does an inherited `p=reject` guarantee rejection? No. DMARC policy tags are requests from the domain owner. A receiver can consider the request alongside its own local policy and other message signals. --- # How can DNS poisoning redirect traffic and what stops it? Canonical: https://www.palisade.email/learning/dns-poisoning-redirects-prevention > DNS poisoning redirects traffic by causing a resolver to return a false DNS answer. Learn how DNSSEC, resolver controls, and validation reduce the risk. DNS poisoning can redirect traffic when an attacker causes a DNS resolver to cache and return a false answer for a legitimate domain. A client that trusts that resolver may then connect to an attacker-controlled IP address instead of the intended service. DNSSEC validation, patched and restricted recursive resolvers, and comparison with authoritative DNS answers reduce this risk, while TLS certificate checks limit what a false DNS answer can successfully impersonate. ## Quick takeaways - DNS cache poisoning affects a resolver's stored answer, so later users of that resolver can receive the same false address. - A forged DNS response must be accepted and cached before it can redirect future traffic through that resolver. - [RFC 5452 guidance for DNS resilience](https://datatracker.ietf.org/doc/html/rfc5452) recommends stronger query matching and other resolver defenses against forged responses. - DNSSEC lets validating resolvers authenticate signed DNS data through a chain of trust. - A public DNS lookup can reveal the answer returned at one moment, but it cannot prove the behavior of every resolver, client, or future request. - DNS integrity also matters for email-authentication records, because SPF, DKIM, and DMARC policies are published through DNS. ## How DNS poisoning redirects traffic A recursive DNS resolver asks authoritative name servers for the records needed to answer a client's query, then caches answers according to their DNS data. Cache poisoning occurs when the resolver stores incorrect data and later gives that data to clients. [RFC 5452 describes cache poisoning](https://datatracker.ietf.org/doc/html/rfc5452) as an attack in which forged responses try to match an outstanding DNS query before the legitimate response arrives. For a web destination, a poisoned `A` or `AAAA` record can send a browser to the wrong IP address. For email, false TXT or MX answers can interfere with the DNS information receivers use to evaluate mail. That does not mean every DNS problem is poisoning. A compromised registrar account, an unauthorized authoritative-zone edit, and a local hosts-file change can all redirect traffic through different paths. The distinction matters during response. A cache-poisoning event is centered on a recursive resolver and its cached data. An authoritative-zone compromise requires investigation of the DNS provider, registrar, or zone-management path. For the broader threat model, see [how DNS poisoning works and how teams can defend against it](/learning/whatisdnspoisoning). DNSSEC addresses the authenticity problem for signed DNS data. [RFC 4033 defines DNSSEC's security goal](https://datatracker.ietf.org/doc/html/rfc4033) as allowing resolvers to authenticate DNS data and identify modifications. A resolver must validate DNSSEC for that protection to apply. A signed zone alone does not make a non-validating resolver reject forged unsigned or invalid data. ![Decision flow for identifying whether a suspicious DNS answer came from a resolver cache, an authoritative zone, or a local endpoint configuration](/images/editorial/dns-poisoning-redirects-prevention/dns-poisoning-redirect-paths.webp "1200x676") *Source: Palisade.* ## When DNS poisoning is the likely explanation Unexpected redirects and certificate warnings are signals to investigate, but they do not prove cache poisoning by themselves. A certificate warning can result from an expired certificate, a proxy, a captive portal, a misconfigured application, or an attacker-controlled destination. Use this decision rule: - If the authoritative name server returns the approved address but one recursive resolver returns another address, suspect the resolver path or an intermediary cache. - If authoritative name servers return an unapproved address, treat the event as an authoritative DNS or DNS-management incident until evidence shows otherwise. - If DNS answers match across authoritative and recursive checks but one endpoint still connects elsewhere, inspect the endpoint's hosts file, proxy settings, VPN, security software, and local network path. - If a DNSSEC-validating resolver reports validation failure for a signed name, do not bypass that failure without determining whether the zone, delegation, or resolver configuration is broken. > Do not clear a resolver cache and assume the incident is resolved. If the resolver can still accept forged data, or an upstream source remains compromised, the false answer can return. Restricting recursion is another direct control. [RFC 5358's resolver-operation guidance](https://datatracker.ietf.org/doc/html/rfc5358) recommends limiting recursive service to intended clients because open recursive resolvers create operational and security risks. Keep resolver software patched, restrict administrative access, log resolver behavior, and use DNSSEC validation where the environment supports it. For a wider set of practical controls around domains and mail infrastructure, use the [email security learning hub](/learning). ## Worked DNS comparison Compare an authoritative answer with the answer returned by the resolver used by the affected client. The following commands are illustrative only. Replace `yourdomain.com`, `ns1.example-dns.net`, and the resolver address with values from your own DNS delegation and incident evidence. ```bash # Illustrative only: query an authoritative name server directly dig @ns1.example-dns.net yourdomain.com A +noall +answer # Illustrative only: query the resolver used by the affected network dig @192.0.2.53 yourdomain.com A +noall +answer +comments ``` A meaningful comparison records the queried name, record type, resolver or authoritative server, timestamp, answer, TTL, and DNSSEC status where available. If the answers differ, preserve the outputs and resolver logs before flushing caches or changing DNS records. For example, if the authoritative server returns the approved address but an affected resolver returns an unapproved address, the evidence supports investigation of that resolver's cache and upstream query path. It does not identify the attacker, prove the first point of compromise, or establish that every client received the false answer. DNS checks are also useful after a suspected incident affects email records. A domain's published DMARC, SPF, and DKIM records can be inspected with an [email security score check](/tools/email-security-score). That check reads public DNS data. It cannot inspect an internal resolver's cache, prove a production message path, or determine why a recipient made a delivery decision. ## What to do with the evidence you have If you have a browser warning or a user report, collect the exact domain, time, network, resolver address, and displayed certificate details. Compare the resolver answer with authoritative DNS before making a broad DNS change. If you have inconsistent DNS answers, isolate the affected resolver or network segment, preserve logs, and clear affected caches only after recording evidence. Confirm recursive service is restricted to approved clients, review recent resolver and DNS-management changes, and verify that resolver software and DNSSEC-validation settings follow your approved configuration. If authoritative records are wrong, treat the situation as a zone or account incident. Review registrar and DNS-provider access, recent changes, delegation records, and DNSSEC delegation data. Restore only a known approved record set, then validate through the authoritative server and at least one independent public resolver. If email authentication may have been affected, send a message through the exact production system and inspect its delivered headers. [RFC 8601 defines the `Authentication-Results` header field](https://www.rfc-editor.org/rfc/rfc8601.html), which can show the authentication results applied by the receiving system. After reports accumulate, use DMARC aggregate-report data to identify sources and alignment issues. A correct public record is not proof that the production application signs mail correctly or uses the expected return path. ## Keep DMARC evidence after a DNS incident A public record check can confirm the DMARC, SPF, and DKIM data currently visible to the resolver you query. The remaining operational question is which real sending sources still authenticate and align after the incident. Palisade is agentic DMARC software that analyzes DMARC aggregate-report data, identifies sending sources and authentication or alignment issues, and creates prioritized remediation tickets. It can propose the next policy step when evidence supports it, while a human reviews the evidence and applies the change. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=email_security&utm_content=dns-poisoning-redirects-prevention) Palisade does not stop DNS poisoning, change a DMARC policy on its own, or prove that every future message will authenticate. ## Sources and further reading - [RFC 5452: Measures for Making DNS More Resilient against Forged Answers](https://datatracker.ietf.org/doc/html/rfc5452) - [RFC 4033: DNS Security Introduction and Requirements](https://datatracker.ietf.org/doc/html/rfc4033) - [RFC 5358: Preventing Use of Recursive Nameservers in Reflector Attacks](https://datatracker.ietf.org/doc/html/rfc5358) - [RFC 8601: Authentication-Results header field](https://www.rfc-editor.org/rfc/rfc8601.html) ## Frequently asked questions ### Can DNS poisoning redirect HTTPS traffic? Yes. A poisoned DNS answer can direct a browser to a different IP address. HTTPS certificate validation should warn or fail when the destination cannot present a certificate valid for the requested domain, but users should treat unexpected certificate warnings as an incident signal rather than bypassing them. ### Does DNSSEC stop every form of DNS redirection? No. DNSSEC helps validating resolvers detect unauthenticated modifications to signed DNS data. It does not protect against every endpoint compromise, malicious local configuration, compromised credentials, or an authorized but malicious DNS-zone change. ### Is an unexpected DNS answer proof of cache poisoning? No. It may indicate a stale record, split-horizon DNS, a local hosts-file override, a proxy, an authoritative-zone error, or a poisoned resolver cache. Compare the affected resolver with authoritative answers and preserve the results before remediation. ### Should an organization flush all DNS caches after a suspected attack? Only after preserving evidence and identifying the affected scope. Cache flushing removes stored answers, but it does not repair a vulnerable resolver, compromised authoritative zone, or unsafe DNS-management account. ### Can DNS poisoning affect DMARC? Yes. DMARC relies on DNS-published policy records, and SPF and DKIM also rely on DNS data. A public lookup can check the records visible to that lookup, while delivered-message headers and DMARC aggregate reports provide separate evidence about real mail flows. --- # What DNS records does a business email domain need? Canonical: https://www.palisade.email/learning/dns-records-for-business-email > DNS records for business email include MX for receiving mail, plus SPF, DKIM, and DMARC to authenticate the domain's outgoing messages and DMARC policy. A business email domain normally needs an MX record to receive mail, plus SPF, DKIM, and DMARC records to authenticate mail sent with that domain. MX publishes where receiving servers should deliver messages. SPF, DKIM, and DMARC address different parts of sender authentication. The exact MX and DKIM values come from the mail provider or sending service that operates the relevant mail path. ## Quick takeaways - An MX record identifies the hostnames that accept inbound mail for a domain. - SPF is a DNS TXT record that authorizes sending hosts for the envelope domain. - DKIM publishes a public key or provider-managed key reference for a specific selector. - DMARC publishes a policy and reporting instructions for mail using the visible From domain. - A domain can have multiple DKIM selectors, especially when it uses more than one sending service. - A public DNS lookup shows published records, but it does not prove that a production application sends or signs mail correctly. ## How the four main business email DNS records work An [MX record defined by RFC 1035](https://datatracker.ietf.org/doc/html/rfc1035) tells other mail systems which hosts handle mail addressed to the domain. MX records use a preference value. Sending systems generally try the lowest numerical preference first. SPF is defined in [RFC 7208](https://datatracker.ietf.org/doc/html/rfc7208). It is normally published as a TXT record at the sending domain and begins with `v=spf1`. SPF evaluates the SMTP envelope sender domain, which can differ from the visible From domain that recipients see. DKIM is defined in [RFC 6376](https://www.rfc-editor.org/rfc/rfc6376.html). A sending service adds a DKIM signature to a message, and receivers retrieve the corresponding public key through a DNS name that includes a selector. Your provider may ask for a TXT record with the public key or a CNAME record that delegates the lookup to the provider. Use the exact selector and value the provider generates. DMARC, defined in [RFC 9989](https://www.rfc-editor.org/rfc/rfc9989.html), evaluates whether SPF or DKIM passes with an identifier aligned to the visible From domain. Its DNS TXT record is normally published at `_dmarc.yourdomain.com`. DMARC can request aggregate reports through `rua` and state a requested policy for messages that fail evaluation. The four records have separate jobs. An MX record does not authorize outgoing mail. An SPF record does not route inbound mail. A DKIM key in DNS does not prove that an application is signing messages. A DMARC record does not make a failing SPF or DKIM result pass. For broader context, the [Palisade learning center](/learning) covers the surrounding DNS and email-authentication topics. ## When the answer changes The required record set changes with the mail services your domain actually uses. If the domain receives mail, publish the MX records supplied by the service receiving that mail. If the domain sends mail through one or more platforms, include each legitimate sending path in the SPF design and enable DKIM for each platform where available. A marketing platform, support system, transactional sender, and employee mailbox service can each use different authorization and DKIM settings. A domain that never receives mail may not need MX records for that domain. It can still need SPF, DKIM, and DMARC if it sends mail or if the organization wants to publish DMARC policy for the visible From domain. Use this decision rule: - Mail addressed to `person@yourdomain.com` must arrive: publish the receiving provider's MX records. - A service sends with `yourdomain.com` in the SMTP envelope: account for that service in the single SPF record for that domain. - A service signs mail with `yourdomain.com` or an aligned subdomain: publish the provider-generated DKIM selector record. - Recipients see `yourdomain.com` in the From field: publish and maintain a DMARC record for that domain. > Do not copy MX, DKIM, CNAME, or SPF values from another organization. Provider-generated values can be tenant-specific, and an incorrect record can interrupt mail delivery or authentication. A DNS change also has a timing component. The published answer can differ across resolvers until cached data expires. See [how long DNS propagation takes for email records](/learning/how-long-does-dns-propagation-take-for-email-records) before judging a newly published record as missing. ## Worked business email DNS record set The following is illustrative only. It shows record shapes, not values to publish. Obtain your real MX destinations, DKIM selector, DKIM target or public key, and SPF includes from the providers that send or receive mail for your domain. ```text yourdomain.com. MX 10 inbound.mail-provider.example yourdomain.com. TXT "v=spf1 include:spf.sender-provider.example -all" selector1._domainkey.yourdomain.com. CNAME selector1.provider.example _dmarc.yourdomain.com. TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com" ``` In this example, the MX record identifies one inbound destination. The SPF record has one `v=spf1` policy. RFC 7208 specifies that multiple SPF records at the same domain create an SPF permanent error, so combine authorized mechanisms into one SPF policy rather than publishing separate records for each service. The DKIM hostname contains `selector1._domainkey`. A selector lets a domain publish multiple DKIM keys. The actual selector comes from the service that signs the message. The DMARC record is at `_dmarc.yourdomain.com`, not at the bare domain. ![Record map showing illustrative MX, SPF, DKIM, and DMARC DNS hostnames for a business email domain](/images/editorial/dns-records-for-business-email/dns-records-for-business-email-record-map.webp "1200x600") *Source: Palisade.* DMARC policy choice is separate from record publication. A `p=none` record requests reporting without a handling preference for DMARC failures. Before requesting `quarantine` or `reject`, identify legitimate sources and confirm that important production messages achieve aligned SPF or DKIM authentication. [How a DMARC record protects a domain and supports email delivery](/learning/how-does-a-dmarc-record-protect-my-domain-and-improve-email-delivery) explains that relationship in more detail. ## What to check after publishing the records Start with the evidence you have. If you have only a domain name, use a public DNS lookup to inspect the published MX, TXT, CNAME, and DMARC records. [Look up the domain's DNS records](/tools/dns-lookup) and compare the response with the provider instructions and your approved DNS change. Public results do not prove which application sent a message, whether DKIM signing occurred, or how a receiver handled the mail. If the provider has a domain-authentication or verification page, confirm its current status after DNS has propagated. That status is provider-specific evidence, not a message-level result. Then send a real test message from each important production path and inspect the delivered message headers. The `Authentication-Results` header is standardized by [RFC 8601](https://www.rfc-editor.org/rfc/rfc8601.html) and can show receiver-reported SPF, DKIM, and DMARC evaluation results. Check that the message came from the exact application, branded domain, and return-path configuration that matters. Finally, review DMARC aggregate reports after data accumulates. DNS confirms publication. Provider status confirms what that provider sees. A delivered message confirms one real mail path. Aggregate reports help reveal the sending sources and authentication results observed over time. Record length can also matter when providers issue long DKIM keys or layered SPF policies. The DNS record length limit for email records explains the DNS constraints that can affect how a value is published. ## Check the DNS records behind your business email Use a domain DNS lookup to compare the records visible on public DNS with the values your mail and sending providers instructed you to publish. Follow that with a provider-status check and a delivered-message header check for each production sending path. [Inspect business email DNS records](/tools/dns-lookup) A public lookup cannot prove that every sender is authorized, that a service is signing with the expected DKIM selector, or that a recipient will deliver a future message to the inbox. Palisade is agentic DMARC software that analyzes DMARC aggregate-report data, identifies sending sources and authentication or alignment issues, and proposes prioritized remediation work. A human reviews the evidence and applies any DNS or DMARC policy change. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=email_authentication&utm_content=dns-records-for-business-email) For a provider-specific implementation of these authentication checks, see [What is DANE and does your email need it?](/learning/what-is-dane). ## Sources and further reading - [RFC 1035: Domain names, implementation and specification](https://datatracker.ietf.org/doc/html/rfc1035) - [RFC 7208: Sender Policy Framework](https://datatracker.ietf.org/doc/html/rfc7208) - [RFC 6376: DomainKeys Identified Mail](https://www.rfc-editor.org/rfc/rfc6376.html) - [RFC 9989: Domain-based Message Authentication, Reporting, and Conformance](https://www.rfc-editor.org/rfc/rfc9989.html) - [RFC 8601: Authentication-Results header field](https://www.rfc-editor.org/rfc/rfc8601.html) ## Frequently asked questions ### Do I need an MX record to send business email? No. An MX record identifies where a domain receives mail. A sending-only domain can send mail without MX records, but it should still publish the appropriate SPF, DKIM, and DMARC records for its sending and visible From domains. ### Can a business domain have more than one DKIM record? Yes. DKIM records use selectors, so different email services can publish different selector records under the same domain. Each service must sign with the selector whose public key or CNAME record is published in DNS. ### Can I publish multiple SPF records for different email providers? No. RFC 7208 treats multiple SPF records at one domain as a permanent error. Publish one SPF record and combine the authorized sending mechanisms within that one policy. ### Does a DMARC record replace SPF and DKIM? No. DMARC relies on SPF and DKIM evaluation and alignment with the visible From domain. DMARC publishes policy and reporting instructions, while SPF and DKIM provide the underlying authentication signals. ### Does a correct DNS lookup prove that email will be delivered? No. A correct lookup confirms the public DNS response at that time. Validate the provider's status, inspect headers from a real message sent through the production path, and review DMARC aggregate reports as they become available. --- # Does DMARC stop phishing? Canonical: https://www.palisade.email/learning/does-dmarc-stop-phishing > Does DMARC stop phishing? It helps block spoofed email using your exact domain, but it cannot stop lookalikes, compromised accounts, or all phishing. Yes, DMARC can help stop phishing that spoofs a domain you control, but it does not stop phishing as a whole. DMARC checks whether an email using your visible From domain has an aligned SPF or DKIM pass. When a domain publishes an enforcement policy, receivers can apply that policy to failing impersonation attempts. It cannot control lookalike domains, compromised accounts, or messages sent from domains outside your control. ## Quick takeaways - DMARC protects against unauthorized use of the exact domain in an email's visible From field. - A DMARC pass requires aligned SPF or DKIM authentication. - `p=none` requests monitoring and does not request enforcement for DMARC failures. - `p=quarantine` and `p=reject` request stronger handling of messages that fail DMARC. - DMARC cannot stop phishing sent from a lookalike domain or a compromised legitimate account. - A passing DMARC result identifies authenticated domain use. It does not establish that a message is safe. ## How DMARC limits exact-domain phishing [DMARC is defined in RFC 9989](https://datatracker.ietf.org/doc/html/rfc9989) as a mechanism through which a domain owner publishes a DNS policy for mail that uses its domain in the visible From field. A receiver evaluates the message's SPF and DKIM results, then checks whether at least one passing identifier aligns with that From domain. That aligned authentication requirement matters in a phishing attempt. An attacker can place `billing@yourdomain.com` in a message header, but they cannot make the message pass DMARC for `yourdomain.com` unless they can send through an authorized path with aligned SPF or DKIM. The DMARC policy applies after DMARC fails: - `p=none` asks receivers to take no specific enforcement action and can request aggregate reports. - `p=quarantine` asks receivers to treat failing messages as suspicious. - `p=reject` asks receivers not to accept failing messages. The receiver makes the final delivery decision. A published `p=reject` policy is a strong request, not proof that every mailbox provider will handle every failing message identically. DMARC therefore helps remove a specific impersonation route: direct spoofing of a domain you own. For broader protocol context, visit the [Palisade learning center](/learning). ## When DMARC does not stop phishing DMARC does not give a domain owner control over every phishing message that a recipient might receive. The answer changes when the attacker does not need to forge your exact visible From domain. A lookalike domain, such as `yourdomain-support.com`, is a separate domain. Your DMARC record does not govern it. The attacker may publish SPF, DKIM, and DMARC records for that separate domain, and those records can authenticate mail for the attacker's domain. A display-name phishing message can show a familiar name while using an unrelated email address. DMARC evaluates domains and alignment, not whether a display name is misleading. A compromised account can also send authenticated mail. If an attacker sends through a legitimate account or authorized system, the message may pass authentication because it genuinely came through that domain's approved sending path. DMARC also does not assess the content, links, attachments, or intent of an email. Those decisions remain with receiving systems and other security controls. For phishing that uses credential capture, [phishing-resistant MFA](/learning/phishing-resistant-mfa) addresses a different part of the risk. A usable decision rule is: - If the message claims to be from a domain you own and fails aligned SPF and DKIM, DMARC enforcement can help receivers handle that forgery. - If the message uses another domain, a deceptive display name, or a compromised account, your domain's DMARC policy does not control it. ## Worked example: what DMARC can evaluate Consider an attacker who sends a message with `From: invoices@yourdomain.com` but has no authorized SPF or DKIM identity aligned with `yourdomain.com`. ```text Visible From domain: yourdomain.com SPF result: fail for an aligned yourdomain.com identity DKIM result: fail for an aligned yourdomain.com identity DMARC result: fail Published policy example, illustrative only: v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourdomain.com ``` In this example, the message fails DMARC. A receiver can use the published `p=reject` request when deciding how to handle it. Now compare a message sent from `yourdomain-support.com`. Even if the display name resembles your organization, the visible From domain is not `yourdomain.com`. Your DMARC policy has no authority over that other domain. ![Decision record showing that DMARC can apply to a failed spoof of yourdomain.com but does not govern a separate lookalike domain](/images/editorial/does-dmarc-stop-phishing/does-dmarc-stop-phishing-decision-record.webp "1200x466") *Source: Palisade.* Authentication results are normally recorded in the delivered message's `Authentication-Results` field. [RFC 8601 defines that field](https://www.rfc-editor.org/rfc/rfc8601.html), including how a receiving system can record authentication methods and results. A public DNS record alone cannot prove what happened to one message, and a delivered-message header alone cannot show every sending source that uses your domain. ## What to do next, based on the evidence you have If you have a domain name and need to know what it currently publishes, use the [DMARC checker](/tools/dmarc) to inspect the public record and its policy tags. Compare the result with the DNS record your team intended to publish. If you have a suspicious delivered message, inspect its full headers. Check the visible From domain and the receiver's `Authentication-Results` field. That evidence can show whether the message passed or failed DMARC for the domain it used. If you manage the sending domain, validate the result in four layers before treating enforcement as complete: - Check the DMARC TXT record with the authoritative DNS source and a public resolver. - Confirm the sending vendor's current authentication status for the exact production path. - Send a real message through that path and inspect its delivered headers. - Review DMARC aggregate reports after they accumulate to identify sources and alignment failures. > Do not move a production domain to `p=reject` based only on a DNS lookup. A valid record does not prove that every legitimate sender is aligned. For a separate social-engineering pattern that targets public replies and support conversations, see [what angler phishing is and how to stop it](/learning/what-is-angler-phishing-and-how-can-you-stop-it). ## Investigate the sending sources behind your DMARC policy A public lookup can show the DMARC policy currently published for a domain. It cannot identify every production sender that still fails alignment, confirm a receiver's final decision, or monitor later DNS changes. Palisade is agentic DMARC software that analyzes DMARC aggregate-report data, identifies sending sources and authentication or alignment issues, and creates prioritized remediation tickets. It can propose the next policy step when the evidence supports it, while your team reviews the evidence and applies DNS changes. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=email_authentication&utm_content=does-dmarc-stop-phishing) Palisade does not control lookalike domains, repair every sender automatically, or guarantee that future messages will authenticate or reach an inbox. For a provider-specific implementation of these authentication checks, see [What is quishing (QR code phishing) and how do you stop it?](/learning/what-is-quishing-qr-code-phishing). ## Sources and further reading - [RFC 9989: Domain-based Message Authentication, Reporting, and Conformance](https://datatracker.ietf.org/doc/html/rfc9989) - [RFC 8601: Message Header Field for Indicating Message Authentication Status](https://www.rfc-editor.org/rfc/rfc8601.html) - [Palisade DMARC checker](/tools/dmarc) ## Frequently asked questions ### Does DMARC stop all phishing emails? No. DMARC helps stop phishing that forges a domain you own and enforce. It does not stop phishing from lookalike domains, compromised accounts, unrelated domains, or other channels such as SMS and voice. ### Does `p=none` stop domain spoofing? No. `p=none` does not request enforcement for DMARC failures. It can support monitoring through aggregate reports, but `p=quarantine` or `p=reject` is needed for a domain owner to request stronger handling. ### Can phishing emails pass DMARC? Yes. A phishing message can pass DMARC when it is sent through an authenticated domain controlled by the attacker, or through a compromised legitimate account. DMARC validates domain authentication and alignment, not the honesty of the sender's message. ### Does `p=reject` guarantee that spoofed email is rejected? No. DMARC lets a domain owner request rejection after a DMARC failure, but receiving systems make their own final handling decisions under their local policies. ### Can a DMARC checker prove that phishing is blocked? No. A public DMARC lookup can show the record currently published in DNS. It cannot prove how a particular mailbox provider handled a message, whether all legitimate sending paths align, or how future mail will be treated. --- # Does PCI DSS 4.0 require DMARC? What requirement 5.4.1 means Canonical: https://www.palisade.email/learning/does-pci-dss-4-0-require-dmarc > PCI DSS 4.0 does not explicitly require DMARC. Requirement 5.4.1 requires automated anti-phishing controls, where DMARC can provide evidence. No. PCI DSS 4.0 requirement 5.4.1 does not name DMARC or require a particular DMARC policy. It requires processes and automated mechanisms to detect and protect personnel against phishing attacks, and it has been mandatory since March 31, 2025. PCI DSS v4.0 was retired on December 31, 2024; [PCI DSS v4.0.1 is the current version](https://www.pcisecuritystandards.org/document_library/). PCI SSC says that limited revision added and deleted no requirements, but an assessment should always use the current document and the assessor's scoped interpretation. ## Quick takeaways - PCI DSS v4.0 is retired; PCI DSS v4.0.1 is the current version to use for an assessment. - PCI DSS 4.0 requirement 5.4.1 requires automated mechanisms that detect and protect personnel against phishing attacks. - Requirement 5.4.1 was a future-dated best practice until March 31, 2025, and has been mandatory since. - The requirement does not prescribe DMARC, SPF, DKIM, a vendor, or `p=reject`. - Scope follows the assessed environment, and can reach systems that never touch cardholder data themselves. - DMARC helps receivers identify mail that impersonates a domain when authentication and identifier alignment fail. - DMARC is one anti-spoofing control, while phishing protection also needs controls for threats DMARC cannot evaluate. - Evidence for an assessment should connect the control design, its operating status, and the relevant mail flow. ## How requirement 5.4.1 and current PCI DSS relate to DMARC The [archived PCI DSS v4.0 text](https://www.pcisecuritystandards.org/documents/PCI-DSS-v4_0.pdf) for requirement 5.4.1 states that "Processes and automated mechanisms are in place to detect and protect personnel against phishing attacks." That wording defines an outcome. It does not name an email-authentication protocol or prescribe one implementation. DMARC, SPF, and DKIM appear alongside the requirement, but in the guidance column rather than the requirement itself: ![PCI DSS v4.0 requirement 5.4.1, with the Good Practice guidance highlighted where it names DMARC, SPF and DKIM as anti-spoofing controls that stop phishers spoofing an entity's domain.](/images/cms/67bdd16286560b3395a80cf2_02_19_25_18_36.png "979x639") *Source: PCI Security Standards Council, PCI DSS v4.0. Highlight added by Palisade.* Guidance explains intent and offers examples. It does not create a testable requirement, which is why an assessor tests whether automated anti-phishing mechanisms exist and operate, not whether a `_dmarc` record is published. PCI SSC identifies [PCI DSS v4.0.1 in its document library](https://www.pcisecuritystandards.org/document_library/) as the current standard. Its [v4.0.1 release announcement](https://blog.pcisecuritystandards.org/just-published-pci-dss-v4-0-1) says the limited revision made no additions or deletions to the requirements, while also confirming that v4.0 was retired. This article explains the v4.0 clause behind the query. For a current assessment, work from v4.0.1 and the evidence requirements your assessor applies to the environment in scope. DMARC is relevant because it lets a domain owner publish a policy for messages that use its visible From domain and fail DMARC evaluation. DMARC evaluation depends on an aligned pass for SPF or DKIM. A receiving system then considers the domain owner's requested policy alongside its own local handling rules. See the [Palisade learning center](/learning) for the broader email-security context. That dependency is why the three records are assessed together rather than one at a time: ![Three-step card headed How DMARC builds on SPF and DKIM: SPF defines which mail servers may send for the domain, DKIM adds a signature verifying messages were not altered, and DMARC ties both together so unauthorized email is monitored, quarantined or rejected.](/images/figures/pci-dss-v4-0-compliance-with-dmarc-fig1.webp "1200x589") *Source: Palisade. DMARC ties SPF and DKIM together to decide how unauthorized email is handled.* A DMARC record on a domain whose senders fail both SPF alignment and DKIM signing describes a policy that receivers will apply to legitimate mail. A DMARC policy at `p=quarantine` or `p=reject` can reduce successful exact-domain impersonation where receivers apply the policy. It does not inspect the content of a message, determine whether a link is malicious, or stop a message from an attacker-owned lookalike domain. That distinction matters because requirement 5.4.1 concerns phishing protection for personnel, not only protection of a company's own domain from spoofing. The PCI SSC [Phishing Resource Guide](https://www.pcisecuritystandards.org/documents/PCI_SSC_Phishing_Resource_Guide_v05.pdf) discusses phishing controls, including email authentication, in the wider context of phishing defense. Use it as supporting context rather than treating an example control as a literal DMARC mandate. ## Who requirement 5.4.1 applies to Requirement 5.4.1 was listed as a future-dated best practice in PCI DSS v4.0, so assessments before March 31, 2025 could leave it out. That date has passed, and it is now assessed like any other requirement. Scope follows the assessed environment rather than an industry label. It covers: - Any entity or service provider that stores, processes, or transmits cardholder data (CHD) or sensitive authentication data (SAD). - The people, processes, and system components involved in those flows. - System components with unrestricted connectivity to systems handling CHD or SAD, even when they never touch that data themselves. The third item is the one teams miss. A corporate mail platform used by staff who also administer in-scope systems can sit inside the assessment boundary, which is why an anti-phishing control aimed at personnel appears in a payment standard at all. Merchants, acquirers, issuers, processors, and their vendors are all covered when they meet those conditions. Your assessor sets the final boundary for the environment in scope. ## When the answer changes The answer remains no if the question is whether PCI DSS 4.0 explicitly requires a DMARC record, a specific tag, or a specific enforcement policy. None is specified in requirement 5.4.1. The operational answer changes when the question becomes whether DMARC is useful evidence for an anti-phishing control. In that case, DMARC can be relevant if the organization controls the From domain, publishes a valid record, and has verified that legitimate production senders authenticate with aligned SPF or DKIM. Use this decision rule: - If the goal is to show that a domain has published a DMARC policy, inspect the DNS record. - If the goal is to show that an application sends authenticated mail, inspect a real delivered message from that application and its `Authentication-Results` header. - If the goal is to show protection against phishing generally, include the automated inbound controls that detect and protect personnel, not only outbound domain authentication. - If the goal is an assessment conclusion, retain the evidence your assessor requires for the scoped environment. > A DNS result is not proof that a mail platform signs production messages, that receivers apply a requested policy, or that every phishing message is detected. Requirement 5.4.1 should also not be confused with an SMTP reply code containing `5.4.1`. The [Microsoft 550 5.4.1 recipient-address guide](/resources-post/how-to-fix-550-5-4-1-recipient-address-rejected-access-denied) and [Microsoft SMTP relay-error guide](/learning/how-do-you-fix-microsoft-smtp-5-4-1) concern message-delivery errors, not PCI DSS requirement numbering. ## Worked evidence example for DMARC A DMARC record is published as a DNS TXT record at the `_dmarc` name for the domain. This is illustrative only. Do not publish another organization's reporting address or reuse its values. ```text Host: _dmarc.yourdomain.com Type: TXT Value: v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@yourdomain.com ``` This example gives useful evidence about one narrow point: `yourdomain.com` requests quarantine handling for messages that fail DMARC, and it requests aggregate reports at the listed address. It does not establish that the reporting mailbox receives or processes reports. It also does not prove that each legitimate sender using `yourdomain.com` passes DMARC, that a receiver accepted the requested handling, or that inbound phishing defenses detect a lookalike domain. ![Illustrative DMARC evidence card showing the DNS record, delivered-message evidence, and anti-phishing control scope needed to assess PCI DSS requirement 5.4.1](/images/editorial/does-pci-dss-4-0-require-dmarc/does-pci-dss-4-0-require-dmarc-evidence-checklist.webp "1200x524") *Source: Palisade.* For a meaningful operating check, validate separate layers: - DNS: query the authoritative DNS server and a public resolver for the intended record. - Sending platform: confirm the platform's current domain-authentication status. - Message: send a test message through the exact production path and inspect its `Authentication-Results` fields. [RFC 8601](https://www.rfc-editor.org/rfc/rfc8601.html) defines this header field for communicating message-authentication results. - DMARC: review aggregate-report data after it has accumulated to identify sources and authentication or alignment failures. A green status in a sending platform does not replace the delivered-message check. Likewise, a valid DMARC record does not prove the full anti-phishing outcome required by requirement 5.4.1. ## Rolling out DMARC before an assessment DMARC becomes useful evidence only once legitimate senders authenticate. Publishing an enforcing policy on a domain whose senders are not aligned tells receivers to act against your own mail, which is a worse outcome than publishing nothing. Work through it in order: 1. Inventory the sending domains in scope and check what each one publishes today with the [DMARC checker](/tools/dmarc) and the [Email Security Score](/tools/email-security-score). 2. Publish `p=none` with a `rua` address. Mail flow is unchanged, and aggregate reports start naming the sources sending as your domain. 3. Read the reports until every legitimate source is accounted for, then fix the SPF and DKIM gaps that surface. Third-party platforms sending on your behalf are the usual source of failures. 4. Move to `p=quarantine` and watch for legitimate mail landing in spam folders. 5. Move to `p=reject` once report data stays clean. ![Five-step card headed DMARC rollout steps for PCI DSS v4.0: check your score, publish a DMARC record at policy none, monitor reports, move to quarantine, then enforce reject.](/images/figures/pci-dss-v4-0-compliance-with-dmarc-fig2.webp "1200x800") *Source: Palisade. Start at p=none for monitoring, then step up enforcement to quarantine and reject.* Steps 2 through 5 leave dated artifacts behind: the record as published, the report data behind each policy change, and the date each change took effect. That trail is more useful to an assessment than the record alone. [Moving from quarantine to reject](/resources-post/dmarc-reject-vs-quarantine-whats-the-difference) is the step to take slowly, and [reading aggregate reports](/resources-post/how-to-understand-dmarc-reports) is what tells you when to take it. ## What to do next Start with the evidence you have. If you only know the domain name, use the [DMARC checker](/tools/dmarc) to inspect the public DMARC record and its policy tags. Compare the result with the record your organization intended to publish. If you administer the sending path, send a controlled message through each important application, gateway, and provider. Preserve a redacted copy of the delivered headers and compare the visible From domain with SPF and DKIM results. If you are preparing PCI DSS evidence, document the automated controls that protect personnel from phishing, their owners, and the evidence that they are operating in the relevant environment. DMARC can support that record, but it should remain scoped as an anti-spoofing measure rather than the entire requirement. ## Check the DMARC record that supports your evidence Run the sending domain through Palisade's DMARC checker to inspect the record currently visible in public DNS before comparing it with message-level evidence and your wider anti-phishing controls. [Check the published DMARC record](/tools/dmarc) A public record check cannot prove that every production sender is aligned, repair a phishing-control gap, monitor future DNS changes, or establish a receiver's final message decision. For teams that need to inventory sending sources and work through DMARC remediation over time, [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=security&utm_content=does-pci-dss-4-0-require-dmarc). Palisade analyzes DMARC aggregate-report data and proposes prioritized remediation work, while a human reviews the evidence and applies any change. ## Sources and further reading - [PCI DSS v4.0.1 document library](https://www.pcisecuritystandards.org/document_library/) - [PCI SSC announcement for PCI DSS v4.0.1](https://blog.pcisecuritystandards.org/just-published-pci-dss-v4-0-1) - [Archived PCI DSS v4.0 standard](https://www.pcisecuritystandards.org/documents/PCI-DSS-v4_0.pdf) - [PCI SSC Phishing Resource Guide](https://www.pcisecuritystandards.org/documents/PCI_SSC_Phishing_Resource_Guide_v05.pdf) - [RFC 8601: Message Authentication Status](https://www.rfc-editor.org/rfc/rfc8601.html) - [Palisade DMARC checker](/tools/dmarc) ## Frequently asked questions ### Does PCI DSS 4.0 require `p=reject`? No. Requirement 5.4.1 does not prescribe DMARC or a specific DMARC policy value. A domain owner should validate legitimate sending sources before requesting stronger DMARC handling. ### Is a DMARC record enough to satisfy requirement 5.4.1? No. A DMARC record can support anti-spoofing controls, but requirement 5.4.1 concerns automated mechanisms that detect and protect personnel against phishing attacks. DMARC does not evaluate every phishing technique. ### Does DMARC protect against lookalike domains? No. DMARC evaluates mail using the visible From domain and its associated authentication results. It does not stop an attacker from sending from a separately registered lookalike domain. ### What evidence shows that DMARC works for a production sender? A public DNS lookup shows the published record. A delivered test message from the exact production path and its `Authentication-Results` header show whether that message authenticated. Aggregate reports provide later evidence about observed sending sources and DMARC outcomes. ### Is `p=none` enough to satisfy an assessment? A monitoring record shows the mechanism is published, but `p=none` requests no action on mail that fails DMARC. As an anti-spoofing measure it does less than `quarantine` or `reject`, both of which are worth reaching once legitimate senders are aligned. How the control is documented and scoped is what an assessment examines. ### Does requirement 5.4.1 still apply if a third party sends our mail? Yes. Scope follows the environment being assessed, not the operator of the mail platform. Confirm the provider can align [SPF](/tools/spf) with your domain and sign with [DKIM](/tools/dkim), then publish DMARC on the sending domain. ### What DMARC evidence would an assessor look at? The published `_dmarc` record, the policy in effect and the date it took effect, and aggregate-report data showing that authentication results are monitored. Pair those with a delivered-message check, because a DNS record on its own does not show that production mail authenticates. ### Is PCI DSS requirement 5.4.1 the same as SMTP 5.4.1? No. PCI DSS requirement 5.4.1 is an anti-phishing control requirement. SMTP 5.4.1 is part of message-delivery status-code terminology and has no connection to PCI DSS numbering. --- # Email bounce rate: how to calculate and investigate it Canonical: https://www.palisade.email/learning/email-bounce-rate > Email bounce rate is bounced messages divided by your ESP's stated denominator. Separate hard and soft bounces, inspect reasons, and retest. Email bounce rate is the percentage of messages your email service provider classifies as bounced during a stated send or time window. Calculate it from the provider's reported bounce count and denominator, then split the result into hard and soft bounces before changing list, sending, or authentication settings. The percentage identifies a trend. The underlying SMTP or provider reason identifies the repair. ## Quick takeaways - Email bounce rate is `bounces / the ESP's stated denominator × 100`. - Your ESP defines the denominator, event classifications, and suppression treatment used in its reporting. - A hard bounce and a soft bounce can produce the same total rate while requiring different next steps. - SMTP enhanced status codes separate permanent and persistent failure conditions from temporary conditions. - A bounce rate does not prove inbox placement, recipient engagement, or the cause of an individual rejection. - Export the underlying bounce events before changing DNS, retry settings, or suppression rules. ## What does the failure mean? A high email bounce rate means a larger share of the messages in the provider's reported cohort did not complete delivery as the provider expected. It is an aggregate symptom, not one SMTP failure. The first diagnostic task is to preserve the reported numerator, denominator, hard-bounce count, soft-bounce count, time window, list source, and top reason categories. Use this evidence shape in the incident record. Replace each bracketed value with the numbers from the campaign or sending-period export. ```text Campaign or sending window: <provider-reported period> Reported denominator: <sent, attempted, or provider-defined total> Total bounces: <count> Hard bounces: <count> Soft bounces: <count> List source: <import, signup form, CRM sync, or other source> Top provider or SMTP reason categories: <exact reported strings> ``` The calculation is: ```text email bounce rate = total bounces / provider-stated denominator × 100 ``` [Mailchimp distinguishes hard bounces from soft bounces](https://mailchimp.com/help/soft-vs-hard-bounces/) in its own reporting and handles addresses based on the event type. [Twilio SendGrid documents bounce and block classifications](https://www.twilio.com/docs/sendgrid/ui/analytics-and-reporting/bounce-and-block-classifications) separately. Do not assume those labels, denominators, or account actions map identically across providers. SMTP evidence can narrow the cause when it is available. [RFC 3463 defines enhanced mail-system status-code classes](https://www.rfc-editor.org/rfc/rfc3463.html): class `4` indicates persistent transient failure conditions, while class `5` indicates permanent failure conditions. A provider's dashboard label may summarize those codes, but preserve the exact response or delivery-status notification before treating a label as a root cause. ![Diagram showing the email bounce rate calculation, with total, hard, and soft bounces kept separate](/images/editorial/email-bounce-rate/email-bounce-rate-rate-anatomy.webp "1200x533") *Source: Palisade.* ## What usually causes it? ### Invalid or unavailable recipient addresses A permanent recipient-side failure can increase the hard-bounce component. The exact evidence may identify a nonexistent mailbox, an invalid domain, or another permanent destination condition. RFC 3463 classifies permanent failures in the `5.X.X` class, but the specific subcode and provider interpretation matter. If invalid addresses rise after an import, CRM synchronization, or list-source change, that timing is evidence worth investigating. It is an inference about list quality until the event export and source records confirm it. ### Temporary recipient or mailbox conditions A temporary condition can increase the soft-bounce component without proving that the address is unusable. RFC 3463 uses class `4.X.X` for persistent transient failures. Mailbox capacity, temporary server conditions, or provider throttling can appear in this category, depending on the provider and receiving system. Do not remove recipients based only on a single transient event. First confirm how the ESP retries, classifies, and suppresses that event type. ### Sender-side rejection or deferred traffic A rate increase can reflect a sender-side problem rather than recipient validity. Gmail's [sender guidelines for messages that bounce or defer](https://support.google.com/mail/answer/81126?hl=en) direct senders to identify and fix the issue that caused the response. Preserve the exact Gmail response, affected sending domain, IP, and route. A percentage alone cannot show whether the cause is authentication, message content, sending behavior, recipient policy, or another factor. Use raw SMTP or delivery-status evidence for that branch. The [bounce-back email guide](/learning/bounce-back-email) explains how to read an individual delivery failure. ### A provider reporting or classification change A changed denominator, campaign filter, suppression rule, or dashboard classification can alter the displayed rate without a comparable change in SMTP outcomes. This is an inference until the provider's export definitions or release documentation explain the difference. Compare like with like: the same provider-defined denominator, audience segment, sending path, and time window. A campaign sent to a newly imported list is not a useful comparison with a transactional stream sent to established recipients. ## How do I diagnose the failure? ### 1. Capture the reported numerator and denominator Export the campaign or sending-period report before rerunning, deleting, suppressing, or changing recipients. Record whether the provider uses attempted messages, accepted messages, sent messages, or another value as the denominator. Calculate total, hard, and soft rates separately when the provider exposes those counts. This stops one total percentage from concealing a concentrated permanent-failure or temporary-failure problem. The [email bounce rate calculator](/tools/deliverability-calculator) does that split for you from the counts in the export, and marks which of the resulting rates a provider publishes a threshold for. ### 2. Group bounce events by their exact reason Export the provider's exact SMTP responses, delivery-status notifications, or named reason categories. Group identical strings and count them. Keep raw evidence access-controlled because delivery records can contain recipient or message metadata. Start with the largest group. A single recurring response can explain most of the rate, while a long tail of unrelated events may require separate investigations. For an individual SMTP response, use the [common email bounce messages guide](/learning/bounce-back-email) to identify the evidence that matters. ### 3. Separate permanent and transient evidence Classify events according to the provider's documented treatment and the available SMTP status evidence. RFC 3463 class `5` events are permanent failure conditions, and class `4` events are persistent transient failure conditions. Do not overwrite the ESP's classifications with a generic hard-versus-soft rule if its documentation says otherwise. Record whether the provider retried each event, suppressed the address, or blocked the send before it reached the recipient. A provider block is not necessarily a remote mailbox rejection. ### 4. Compare the affected cohort with a stable cohort Compare the same metric definition across two cohorts. Useful dimensions include list source, acquisition date, sending domain, message type, ESP subaccount, recipient domain, and time window. A rise limited to a new import points toward a list-source investigation. A rise limited to one recipient provider or one sending route points toward that branch's raw SMTP evidence. These are diagnostic hypotheses, not documented receiver conclusions. ### 5. Check the exact production sending path For a sender-side response, capture a newly sent test through the same application, ESP account, sending domain, authentication path, and recipient-provider route. A test from a different mailbox or a different vendor path does not validate the failing route. If the event includes a DMARC-related rejection, diagnose the message authentication evidence separately with [email rejected per DMARC policy](/learning/email-rejected-per-dmarc-policy). Do not change the DMARC policy merely to reduce a percentage. That changes requested enforcement, not the failed message's authentication result. ![Flow for investigating an email bounce rate by preserving the denominator, grouping exact reasons, separating event classes, and retesting the affected path](/images/editorial/email-bounce-rate/email-bounce-rate-diagnostic-flow.webp "1200x829") *Source: Palisade.* ## How do I fix it? ### Remove or correct confirmed invalid addresses When the exact evidence and provider documentation support a permanent recipient-address failure, correct the address at its source or stop sending to it according to the provider's suppression process. Preserve the original event record so the change remains auditable. > Do not bulk-remove recipients from an aggregate rate alone. A total percentage cannot distinguish confirmed invalid addresses from temporary or sender-side failures. This repair changes list quality and recipient eligibility. It does not repair sender authentication or guarantee future delivery. ### Correct the list acquisition or synchronization process If a concentrated increase follows one import, form, or CRM synchronization, inspect that source's validation, mapping, consent, and update process. Test a corrected sample before applying a broad cleanup. Keep the original import and a reversible record of any correction. A list-source repair does not prove that every historic address is valid. ### Repair the specific sender-side failure When exact SMTP evidence identifies a sender-side issue, repair the narrowest confirmed cause. That may involve the sending application's configuration, a provider setting, an authentication failure, or a route-specific policy. Follow the receiving provider's published guidance where it exists. Do not present a domain setting as a universal repair for every bounce. A public domain check may show a current DNS record, but it cannot prove the production application used that record or explain a receiver's private decision. ### Preserve transient recipients for the documented retry path For temporary events, use the ESP's documented retry and suppression behavior. Do not convert transient failures into permanent removals without evidence that the provider's rules and repeated event history support that action. This repair affects retry handling or audience treatment. It does not change the receiving provider's capacity, filtering, or future policy. ## How do I validate the repair? Repeat the same sending path with a controlled cohort that matches the failed campaign's application, ESP account, sending domain, message type, and recipient-provider mix. Confirm the provider's current event classification, then inspect the received message or delivery-status evidence for the exact branch that failed. Validate at four layers where each applies: - Check DNS through the authoritative provider and a public resolver if the repair changed a sending-domain record. - Check the ESP's current authentication or delivery status if the provider exposes it. - Check a real message or delivery-status notification from the exact production path. - Review DMARC aggregate reports after data accumulates when the repair involved DMARC authentication or alignment. A lower rate in one small test does not prove a campaign-scale fix. Compare the repaired cohort using the same provider-defined denominator and reason categories, then watch for recurrence in the next representative sending window. ## Export the evidence behind the bounce rate Before using a domain-level assessment, export the campaign's denominator and exact bounce reasons. A rising email bounce rate can come from recipient data, temporary conditions, sender-side responses, or a reporting-definition change. The [email security score](/tools/email-security-score) can inspect public domain security signals after your evidence points to a domain-control question. It cannot accept a campaign export, verify recipient validity, explain an ESP's suppression behavior, or prove why a receiver rejected one message. For broader context on delivery signals beyond bounces, see the [email deliverability learning hub](/email-deliverability). ## Sources and further reading - [RFC 3463: Enhanced mail system status codes](https://www.rfc-editor.org/rfc/rfc3463.html) - [Gmail sender guidelines](https://support.google.com/mail/answer/81126?hl=en) - [Mailchimp: Soft bounces versus hard bounces](https://mailchimp.com/help/soft-vs-hard-bounces/) - [Twilio SendGrid: Bounce and block classifications](https://www.twilio.com/docs/sendgrid/ui/analytics-and-reporting/bounce-and-block-classifications) - [Palisade common email bounce messages guide](/learning/bounce-back-email) ## Frequently asked questions ### What is a good email bounce rate? A good email bounce rate is one that is measured against your ESP's stated denominator and has no unexplained increase in permanent or sender-side failures. There is no SMTP standard that defines one universal acceptable percentage. Compare similar campaigns, then investigate the exact reasons behind a material change. ### Is a 20% bounce rate good? No. A 20% email bounce rate warrants immediate investigation of the denominator, list source, and exact provider or SMTP reason categories. The percentage alone does not prove the cause, but it is too large to treat as routine variation without evidence. ### Is 48% bounce rate good? No. A 48% email bounce rate is a severe delivery symptom. Pause broad expansion of the affected cohort until you preserve the event export, identify the dominant reason category, and test the narrowest supported repair through the same sending path. ### Is 35% a good email open rate? Only as a comparison within the same measurement method, audience, message type, and time window. An open rate measures a different event from email bounce rate, and open tracking can be affected by recipient privacy and image-loading behavior. A 35% open rate does not explain why messages bounced. ### Can a bounce rate prove poor inbox placement? No. Bounce rate measures provider-reported delivery failures or classifications within a stated cohort. A message can avoid a bounce and still be filtered, delayed, or ignored. Review delivery evidence and recipient-provider data separately before drawing an inbox-placement conclusion. --- # Email security Proofpoint: what Core Email Protection covers Canonical: https://www.palisade.email/learning/email-security-proofpoint > Email security Proofpoint refers to Proofpoint's Core Email Protection, with API and secure email gateway options. Learn what evidence to request. Proofpoint email security commonly refers to Proofpoint Core Email Protection, a product family that Proofpoint describes as deployable through an API-connected model or a secure email gateway. That description establishes product scope, not what any particular tenant detects, blocks, or allows. For an evaluation, separate the selected deployment model and authorized tenant evidence from public sender-domain evidence such as DMARC. ## Quick takeaways - Proofpoint lists Core Email Protection separately from Email Fraud Defense and other products in its product directory. - Proofpoint publicly describes API-connected and secure email gateway deployment choices for Core Email Protection. - A product page does not show a specific tenant's policies, detections, false positives, or remediation results. - A secure email gateway and an API-connected service need different architecture and evaluation questions. - A public DMARC record can show a sender domain's published policy, but it cannot test an inbound Proofpoint deployment. - DMARC authenticates use of the visible From domain. It does not replace inbound threat controls. ## How Proofpoint Core Email Protection works [Proofpoint's Core Email Protection page](https://www.proofpoint.com/us/products/email-security-and-protection) describes email protection through two deployment approaches: an API-connected approach and a secure email gateway approach. The deployment choice changes where the security service participates in the mail environment and what an evaluator must validate. A secure email gateway is part of the inbound and outbound mail path. The gateway architecture matters because mail routing, accepted domains, TLS behavior, and failure handling can affect production delivery. See [what an email security gateway is](/learning/email-security-gateway) for the generic architecture rather than treating one vendor's marketing description as a universal gateway design. An API-connected model integrates with a supported mail environment through its API rather than placing the same kind of gateway in the SMTP path. The public product description can establish that this option exists. It cannot establish which tenant permissions were granted, which policies are enabled, or how a tenant handled a particular message. [Proofpoint's product directory](https://www.proofpoint.com/us/products) also separates Core Email Protection from Email Fraud Defense. That distinction matters when an evaluation involves sender-domain impersonation or DMARC. A claim about one named product should not be assumed to describe another Proofpoint product or service. ![Decision map separating Proofpoint API and secure email gateway deployment evidence from public DMARC sender-domain evidence](/images/editorial/email-security-proofpoint/email-security-proofpoint-evidence-map.webp "1200x676") *Source: Palisade.* ## When the answer changes The answer changes when the team can name the control it is evaluating and the evidence it can access. Use this decision rule: - If the question is about mail routing, SMTP-path inspection, or gateway failure behavior, evaluate the secure email gateway design with authorized tenant configuration and a controlled same-path message test. - If the question is about an API-connected deployment, confirm the supported mail environment, authorized access, selected integration scope, and evidence from the tenant's approved test scenarios. - If the question is about a domain's published DMARC policy, inspect public DNS and keep that result separate from inbound filtering evidence. - If the question is about fraud defense or DMARC operations, confirm that the evaluation names the relevant Proofpoint product. Core Email Protection and Email Fraud Defense are distinct entries in Proofpoint's public product catalog. A green status in a vendor tenant is not enough to prove that a real production message took the intended path. A public DNS lookup is also not proof of private tenant behavior. For wider product-category context, [email security](/learning/threats) covers the controls that work together around mail systems. ## Worked evidence plan for a Proofpoint evaluation Write down the deployment question before requesting results. The following is an illustrative evidence plan, not a vendor configuration. ```text Product scope: Proofpoint Core Email Protection Deployment question: API-connected service or secure email gateway? Tenant evidence owner: Security administrator Controlled test evidence: Approved message scenario and observed result Mail-path evidence: Routing or API integration evidence for the selected model Sender-domain evidence: Published DMARC record for yourdomain.com Decision boundary: Public DMARC DNS does not prove Proofpoint detection or policy state Rollback owner: Named change owner for any production routing or policy change ``` For a secure email gateway evaluation, collect evidence from the exact production or approved test path. Confirm the receiving environment, the gateway's role in mail flow, and what happens if the control is unavailable or a route is changed. A test sent through another path cannot prove the gateway's behavior. For an API-connected evaluation, record the supported mail environment and the approved integration scope. Then test only the scenarios the tenant owner authorizes. Do not infer a detection result, policy setting, or false-positive rate from the public product page. DMARC evidence has a different job. [RFC 9989](https://datatracker.ietf.org/doc/html/rfc9989) defines DMARC as a mechanism that evaluates SPF or DKIM authentication aligned with the visible From domain and applies the domain owner's published policy request after DMARC failure. It can help assess sender-domain authentication, but it does not inspect an inbound threat-control tenant. If evaluating a broader set of inbound controls, [anti-phishing software](/learning/anti-phishing-software) is the adjacent buyer task. It should not substitute for an architecture-specific evaluation of the selected Proofpoint deployment. ## How should you verify the scope? Start with the evidence you actually have. If you have only a public sending domain, use a DNS check to record its published DMARC policy. That is useful context for sender-domain authentication and does not require access to a Proofpoint tenant. If you have an authorized Proofpoint evaluation, request tenant-specific evidence from the selected deployment model, approved message scenarios, and the real mail path. For a production claim, validate at separate layers: - DNS: Query authoritative DNS and at least one public resolver for the sender domain's DMARC record. - Vendor: Obtain the authorized tenant's relevant integration and policy evidence. - Message: Review an actual delivered test message from the exact path, including its raw headers where appropriate. - DMARC: Review aggregate-report evidence after reports accumulate for the domain and sending paths in scope. These layers answer different questions. A passing DMARC record does not prove inbound-filter effectiveness. A tenant status does not prove that a particular production message authenticated with an aligned domain. ## Check the public DMARC policy beside the evaluation plan If the evaluation includes a domain you control, inspect its published policy before treating DMARC as part of the evidence plan. [Check the domain's DMARC record](/tools/dmarc) A public record check cannot inspect Proofpoint configuration, reproduce a detection, reveal private policy state, or prove inbound-filter effectiveness. ## Sources and further reading - [Proofpoint Core Email Protection](https://www.proofpoint.com/us/products/email-security-and-protection) - [Proofpoint product directory](https://www.proofpoint.com/us/products) - [Proofpoint Core Email Protection solution brief](https://www.proofpoint.com/sites/default/files/solution-briefs/pfpt-us-sb-core-email-protection.pdf) - [RFC 9989: Domain-based Message Authentication, Reporting, and Conformance](https://datatracker.ietf.org/doc/html/rfc9989) ## Frequently asked questions ### What is the most hacked email provider in the world? No authoritative public ranking establishes one email provider as "the most hacked" worldwide. Reported incidents use different definitions, populations, and time periods. Assess a provider or deployment using its current security controls, your tenant configuration, identity protections, and evidence from the actual mail path. ### Is Proofpoint a legit company? Yes. Proofpoint publicly maintains product documentation and a product directory that lists Core Email Protection and other email-security offerings. Legitimacy is different from product fit, so an evaluator should still verify the selected product scope, deployment approach, contract terms, and tenant-specific evidence. ### Who is Proofpoint's biggest competitor? No single competitor is universally Proofpoint's biggest competitor because the answer depends on the product category, deployment model, geography, and buyer requirements. Define the exact task first, such as secure email gateway protection, API-connected email security, or DMARC operations, then compare products that address that task under the same evidence requirements. ### Does Outlook use Proofpoint? No. Outlook is a Microsoft email client and service family, while Proofpoint is a separate security vendor. An organization can deploy Proofpoint with a Microsoft mail environment if the selected Proofpoint product and deployment model support that environment, but Outlook does not inherently use Proofpoint. ### Can a DMARC record prove that Proofpoint is protecting inbound email? No. A DMARC record shows a domain owner's published sender-domain policy. It does not expose private Proofpoint configuration, show message detections, or test whether an inbound control handled a message as intended. --- # Email security protocols Canonical: https://www.palisade.email/learning/email-security-protocols > Email security protocols protect different parts of email: transport, mailbox access, and domain authentication. See how TLS, SMTP, SPF, DKIM, and DMARC. Email security protocols are standards and controls that protect different parts of email rather than one single security feature. SMTP transports mail, TLS protects eligible connections, and SPF, DKIM, and DMARC help receivers assess whether a message is authorized to use a domain. Their protections overlap, but none proves that every message is safe or will reach the inbox. ## Quick takeaways - SMTP is the Internet standard protocol for transporting email between mail systems. - TLS protects an email connection in transit when both endpoints negotiate and use it. - SPF, DKIM, and DMARC address domain authorization and authentication, not message confidentiality. - POP3 and IMAP are mailbox-access protocols, while SMTP handles submission and transport. - There is no universally "most secure" email protocol because transport, mailbox access, and sender authentication protect different functions. - A public domain check shows published controls, not the behavior of every production message path. ## How email security protocols work together The term "email security protocols" covers controls at different points in the message lifecycle. [RFC 5321 defines SMTP](https://datatracker.ietf.org/doc/html/rfc5321) as the basic protocol for Internet electronic-mail transport. SMTP moves a message between sending, relay, and receiving systems. It is still used because mail systems need a transport protocol, but SMTP alone does not establish that the visible From domain authorized the message. TLS addresses a different risk. [RFC 8314 specifies the use of TLS for email submission and access](https://datatracker.ietf.org/doc/html/rfc8314) and treats cleartext access as obsolete. TLS protects the connection between two participating endpoints. It does not establish that a sender is entitled to use a particular From domain, and it does not control what happens after a recipient system receives the message. Domain-authentication controls add that authorization layer: - [SPF](https://datatracker.ietf.org/doc/html/rfc7208) lets a domain publish which hosts are authorized to use the domain in an SMTP envelope identity. - [DKIM](https://datatracker.ietf.org/doc/html/rfc6376) attaches a cryptographic signature that a receiver can verify against a public key published in DNS. - [DMARC](https://datatracker.ietf.org/doc/html/rfc9989) builds on SPF and DKIM results and checks whether an authenticated identifier aligns with the visible From domain. It also lets a domain publish requested handling for DMARC failures and request aggregate feedback. These controls make more sense as a set of questions than as a ranked list. SMTP asks how the message travels. TLS asks whether a connection is protected. SPF and DKIM provide authentication signals. DMARC asks whether a qualifying authentication result aligns with the domain recipients see. ![Flow showing email transport, TLS connection protection, SPF and DKIM authentication, and DMARC alignment evaluation](/images/editorial/email-security-protocols/email-security-protocols-control-flow.webp "1200x829") *Source: Palisade.* For a wider look at the threats these controls help reduce, see [email security threats](/learning/threats). Authentication is useful against unauthorized use of a domain, but it does not make malicious content harmless or replace recipient-side filtering. ## When the answer changes The right protocol depends on the question you need to answer. Use this decision rule: ```text If the question is "How does mail move between systems?" Use SMTP. If the question is "Is the submission or mailbox-access connection protected?" Use TLS with the applicable email submission, POP3, or IMAP service. If the question is "Was this domain authorized to send this message?" Inspect SPF, DKIM, and DMARC results. If the question is "Did a user receive a malicious message?" Inspect the message, recipient-side controls, and the relevant security investigation evidence. ``` "TLS and SSL in email" often refers to encrypted connections for email submission or mailbox access. Current standards language uses TLS. SSL is an older name and protocol family, so a configuration that says "SSL/TLS" needs a closer look at the actual protocol and service configuration. [RFC 8314 recommends TLS 1.2 or later for email submission and access](https://datatracker.ietf.org/doc/html/rfc8314). "The three email protocols" is also context-dependent. In a mail-client context, it commonly means SMTP, POP3, and IMAP: SMTP submits or transports mail, while POP3 and IMAP access mailboxes. That grouping does not mean SPF, DKIM, and DMARC are less important. They solve a separate sender-authentication problem. There is no single most secure email protocol. A TLS-protected connection does not prove domain authorization. A valid DKIM signature does not encrypt the transport connection. A DMARC pass does not guarantee inbox placement, recipient trust, or protection from a compromised legitimate sender. Choose controls by the part of the email system that needs protection. ## A worked email security example Consider a message sent as `billing@yourdomain.com` through a legitimate service. ```text Illustrative message path and checks Visible From: billing@yourdomain.com SMTP: carries the message to the receiving system TLS: protects the connection when the sending and receiving systems use TLS SPF: checks whether the service is authorized for the relevant envelope domain DKIM: checks a signature against the sending domain's DNS public key DMARC: checks whether an SPF or DKIM pass aligns with yourdomain.com ``` This example is structural only. It does not show an actual record, signing selector, provider hostname, or message result. A useful interpretation is: - A successful TLS connection can protect the hop without proving the visible From domain is authorized. - An SPF or DKIM pass can authenticate an identifier that is different from the visible From domain. - DMARC adds the alignment test that connects an eligible authentication result to the visible From domain. - A DMARC pass still says nothing by itself about content safety or a receiver's final placement decision. DMARC reporting platforms can process aggregate reports to show pass and fail rates, sender sources, and authentication status. [DMARC Report describes monitoring SPF, DKIM, and DMARC](https://dmarcreport.com/) and alerting when records change, break, or need attention. That type of reporting helps identify authentication failures over time. It does not replace checking a real delivered message when you need evidence from one specific sending path. For an operational discussion of those authentication signals, see [whether DMARC failure reports are worth the trouble for email security](/learning/what-exactly-is-a-dmarc-failure-report-and-why-should-you-care). ## Choose the next check from the evidence you have Start with the evidence closest to the problem. If you only have a domain name, assess its public posture with the [Email Security Score tool](/tools/email-security-score). Treat the result as a point-in-time public check. It cannot prove which application sent a particular message, whether every production sender is aligned, or how a recipient privately evaluated a message. If you have a message that was delivered, inspect its raw headers and `Authentication-Results` fields. That evidence can show the receiver's recorded SPF, DKIM, and DMARC outcomes for that message. Compare those results with the visible From domain and the known sending service. If you are changing a production configuration, validate at separate layers: - Query authoritative DNS and at least one public resolver for the published record. - Confirm the sending provider's current authentication or verification status. - Send a real message through the exact production path and inspect its delivered headers. - Review DMARC aggregate reports after enough data has accumulated. A green DNS result is not proof that the application is signing mail or using the intended return path. ## Read the email security guide Use the [email security guide](/learning/threats) to place protocol controls alongside filtering, access controls, and operational response practices. That guide can help route the next investigation, but it cannot prove an individual message's production path, repair a sender configuration, or guarantee delivery. ## Sources and further reading - [RFC 5321: Simple Mail Transfer Protocol](https://datatracker.ietf.org/doc/html/rfc5321) - [RFC 8314: Use of TLS for Email Submission and Access](https://datatracker.ietf.org/doc/html/rfc8314) - [RFC 6376: DomainKeys Identified Mail Signatures](https://datatracker.ietf.org/doc/html/rfc6376) - [RFC 9989: Domain-based Message Authentication, Reporting, and Conformance](https://datatracker.ietf.org/doc/html/rfc9989) - [DMARC Report](https://dmarcreport.com/) ## Frequently asked questions ### What is TLS and SSL in email? TLS is the current protocol name for protecting email submission and mailbox-access connections. SSL is an older name and protocol family that still appears in product labels such as "SSL/TLS." For current email submission and access, RFC 8314 recommends TLS 1.2 or later. ### What are the three email protocols? There is no single official set called "the three email protocols." In a mail-client context, the phrase commonly refers to SMTP, POP3, and IMAP. SMTP handles submission and transport, while POP3 and IMAP provide mailbox access. SPF, DKIM, and DMARC are a separate set of domain-authentication controls. ### What is the most secure email protocol? No single email protocol is the most secure across every function. TLS protects eligible connections, SMTP transports mail, and SPF, DKIM, and DMARC provide different authentication and authorization signals. A secure email design uses the controls that match the risk under review. ### Is SMTP used anymore? Yes. SMTP remains the Internet standard protocol for electronic-mail transport. Modern email systems commonly pair SMTP with TLS and domain-authentication controls because SMTP transport alone does not establish visible From-domain authorization. ### Does DMARC encrypt email? No. DMARC evaluates domain-aligned SPF or DKIM authentication and lets a domain publish requested handling for failures. It does not encrypt message content or replace TLS for connection protection. --- # Email sender reputation Canonical: https://www.palisade.email/learning/email-sender-reputation > Email sender reputation is how mailbox providers may assess a sending IP address or domain as reputable or spam-related. Learn how to investigate it. Email sender reputation is an assessment of a sender's standing that is commonly associated with a sending IP address or domain. In practical terms, it asks whether mailbox providers may view that sender as reputable or as a spammer. It is one diagnostic signal in email delivery work, not a universal score or a complete explanation for why one message reached, missed, or was filtered by a recipient. ## Quick takeaways - Email sender reputation can be assessed for a sending IP address or domain. - A reputation result reflects an assessment, not a universal mailbox-provider verdict. - Blocklist status is a separate diagnostic signal from sender reputation. - A public IP or domain check cannot reveal every production sending path. - One reputation result does not prove inbox placement, future delivery, or a receiver's private decision. - Delivery investigations need to keep sender reputation separate from authentication, message, and recipient-side evidence. ## How email sender reputation works [Sender Score describes sender reputation as something to monitor](https://senderscore.org) and provides an IP lookup, framing the question as whether mailbox providers view a sender as reputable or as a spammer. That wording is useful because it keeps the subject narrow: sender reputation concerns how a sender is assessed, rather than a guarantee about the outcome of every message. The relevant sender identity may be an IP address or a domain. An IP address is the network address used by the sending system. A domain is the name associated with the sender's mail identity. A sender can use more than one of either, so a result for one IP or one domain may leave other production paths unexamined. Sender reputation also belongs within a broader [email deliverability](/email-deliverability) investigation. Delivery outcomes can involve the recipient's own filtering and handling decisions. A reputation assessment can help frame one part of the investigation, but it does not disclose a mailbox provider's private rules or show why a specific recipient received a specific result. Do not turn a reputation label into a protocol result. Reputation is distinct from evidence that a message authenticated, such as the message's own `Authentication-Results` header. It is also distinct from a DNS lookup that confirms a record is publicly published. Those checks answer different questions. ![Decision flow showing separate checks for a sending IP or domain, blocklist status, message evidence, and delivery outcome](/images/editorial/email-sender-reputation/email-sender-reputation-diagnostic-flow.webp "1200x980") *Source: Palisade.* ### How sender reputation works in email marketing Sender reputation in email marketing is the same assessment applied to a bulk-sending program, and the same separation of evidence streams applies to it. Sender Score presents [its reputation score, blocklist lookups, and bounce lookups](https://senderscore.org) as distinct tools, which is a useful reminder that a campaign problem has more than one evidence stream. A marketing program also produces one stream a transactional sender rarely has in volume: bounce messages from a single send. Preserve those bounces with the receiving domain, timestamp, and sending IP, and read them alongside the reputation result rather than in place of it. A reputation assessment can tell a team that its email marketing program needs review. It cannot show why one campaign was filtered. A warmup activity does not establish how mailbox providers will handle future campaigns either; [what AI email warmup can and cannot prove](/learning/ai-email-warmup) covers that separately. ## When the answer changes The answer changes with the evidence you have and the scope of the sending path you are investigating. Use this decision rule: - If you know the sending IP address, assess that IP address and record which production system uses it. - If you know the visible sending domain, assess the domain separately. For a domain-focused explanation, see [how to check and improve email domain reputation](/learning/how-can-you-check-and-improve-your-email-domain-reputation). - If you have a suspected blocklist issue, check blocklist status as a separate evidence stream. - If you have a delivered or rejected message, preserve the redacted headers and compare them with the IP or domain result. - If you only have a public result, treat it as a point-in-time observation. It does not prove the full sending path, a receiver's private decision, or future placement. Blocklist status is related operational evidence, but it is not the same thing as a reputation assessment. [Sender Score directs users to check the Return Path Blocklist separately](https://senderscore.org). MXToolbox also describes checking an MX-record IP address against DNS-based blacklists, which is an IP diagnostic rather than proof of sender reputation or a mailbox-provider decision. A mailbox provider may reach a conclusion that is not visible through a public checker. For that reason, avoid claims such as "a clear blocklist result means the sender has a good reputation" or "a reputation result explains every delivery problem." The available evidence does not support either statement. When a delivery problem includes an unauthenticated-sender notice, reputation is not enough to diagnose it. Follow the message-specific evidence and the provider's stated condition. For example, [Gmail's blocked sender is unauthenticated message](/email-deliverability/gmail-blocked-sender-is-unauthenticated) points to an authentication problem that requires its own investigation. ## Worked example: separating the evidence Assume an operations team notices that mail from `news.yourdomain.com` is receiving poor delivery feedback. The team knows the outbound platform's sending IP address but does not know whether the issue is reputation, a blocklist entry, message authentication, or a receiver-specific decision. The first pass should keep the evidence separate: ```text Sender identity under review Domain: news.yourdomain.com Sending IP: 192.0.2.25 Evidence to collect - **First:** IP or domain reputation-assessment result - **Second:** relevant IP blocklist result - **Third:** redacted headers from a message sent through this exact path - **Fourth:** recipient-side error or delivery evidence, if available Decision Do not explain the delivery outcome from only one result. ``` The IP address above is illustrative. Do not publish a customer IP address, recipient address, or unredacted headers in a public ticket. The IP address and domain assessment establish the identity being investigated. A separate blocklist check can reveal whether that IP appears on a relevant list. Message headers can establish which path was actually used for the message in question. A recipient-side error, where available, may identify a condition that public diagnostics cannot see. The team should not change sending practices merely because one public result looks concerning or reassuring. First establish whether the result applies to the IP or domain that sent the affected mail. Then compare it with the message evidence. This is also why an MX-based blacklist result needs careful interpretation. [MXToolbox describes its check as examining MX-record IP addresses against DNS-based blacklists](https://mxtoolbox.com). An MX record identifies mail-receiving infrastructure. It may not be the outbound IP address used for the sender under investigation. ## Practical next steps for a sender-reputation concern Start with the most direct evidence available. - If you have a sending IP address, use a reputation-assessment service for that IP and document the lookup time. - If you have the sending domain but no confirmed outbound IP, investigate the domain's role separately and identify the system that actually sends the affected mail. - If a blocklist is suspected, check its status independently and record the specific IP reviewed. - If a message was delivered, filtered, deferred, or rejected, retain redacted headers and any recipient error. They are evidence about the real mail path. - If you are reviewing delivery more broadly, use the [email deliverability learning hub](/email-deliverability) to separate reputation work from authentication, policy, and recipient-side issues. Public checks are useful for narrowing a question. They do not replace validation through the exact production path. For a complete investigation, confirm DNS through authoritative DNS and a public resolver where applicable, check the sending vendor's own status where available, inspect a real message's headers, and review DMARC aggregate-report data after it accumulates. ## Inspect the sender's public email-security posture If you are collecting initial evidence for a sending domain, open Palisade's Email Security Score alongside the IP or [domain reputation](/tools/domain-reputation) and blocklist checks. Use the results to identify what needs closer investigation, then compare them with evidence from the actual production message path. [Inspect the Email Security Score](/tools/email-security-score) A public diagnostic cannot prove a mailbox provider's private reputation decision, repair a sending issue, monitor every sender continuously, or guarantee inbox placement. For teams that need to review DMARC aggregate-report data across domains, Palisade is agentic DMARC software that identifies sending sources and authentication or alignment issues, then creates prioritized remediation tickets. It does not change DMARC policy or control a receiver's reputation decision. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=reputation_blocklists&utm_content=email-sender-reputation) ## Sources and further reading - [Sender Score sender reputation lookup](https://senderscore.org) - [MXToolbox blacklist checks](https://mxtoolbox.com) - [Palisade Email Security Score](/tools/email-security-score) - [Email deliverability](/email-deliverability) ## Frequently asked questions ### Is email sender reputation the same as domain reputation? No. Domain reputation is a domain-focused assessment, while email sender reputation can be discussed in relation to either a sending domain or a sending IP address. A result for one identity does not automatically establish a result for the other. ### Is a blocklist result the same as sender reputation? No. Blocklist status is a distinct diagnostic signal. Check it alongside an IP or domain reputation assessment, then compare both results with the real message path before drawing a conclusion. ### Can a public reputation check explain why one email went to spam? No. A public result does not reveal a mailbox provider's private handling decision or prove why one specific message was filtered. Message headers, recipient-side evidence, and the actual sending path are needed for that investigation. ### Does a clear blocklist check guarantee inbox placement? No. A clear blocklist result only addresses the list check performed for the identity reviewed. It does not guarantee delivery or inbox placement at any mailbox provider. ### Should I assess the sending IP address or the domain? Yes, assess the identity you can confirm for the affected mail. If you know the outbound IP address, assess that IP. If the concern is tied to a domain, assess the domain separately. When possible, collect both types of evidence and verify which path sent the message. ### Can I check sender reputation with only an IP address? Yes. Sender Score's lookup takes an IP address as its input. Record which production system uses that address, because a sender can use more than one, and a result for a single IP leaves the other sending paths unexamined. ### Should bounces be investigated separately from reputation? Yes. A bounce is evidence from one specific delivery attempt, while a reputation result is a point-in-time assessment of a sender identity. Preserve the bounce message, receiving domain, timestamp, and sending IP, then compare them with the reputation and blocklist results. ### Can sender reputation prove inbox placement for a campaign? No. A sender reputation result is a point-in-time assessment of a sender identity, not a prediction. It does not prove that a mailbox provider accepted any message, and it does not guarantee inbox placement for the next campaign sent from the same IP address or domain. --- # Generate DKIM keys Canonical: https://www.palisade.email/learning/generate-dkim-keys > Generate DKIM keys by creating a key pair in your sending system, keeping the private key there, and publishing its public key in DNS for receiver. Generate DKIM keys by creating a public-private key pair in the email system that will sign your mail. Keep the private key in that system and publish the matching public key where receivers can retrieve it through DNS. The provider or signing software determines the exact generation method and DNS record shape, so do not reuse another organization's selector, public key, or CNAME target. ## Quick takeaways - A DKIM key pair has a private signing key and a public verification key. - The sending system uses the private key to add a DKIM signature to each message. - Receiving systems retrieve the public key from DNS to verify that signature. - A selector identifies which public key a receiver should look up for a message. - A public DNS record does not prove that the production sender is signing mail correctly. - Microsoft 365 uses provider-generated CNAME records for custom-domain DKIM, not a customer-created TXT public-key record. ## How DKIM key generation works [DKIM](https://datatracker.ietf.org/doc/html/rfc6376) associates a signing domain with a cryptographic signature in an [email header](/tools/email-header-analyzer). A receiver retrieves the corresponding public key from the signing domain and uses it to check the signature. The protocol does not encrypt the message, and a successful DKIM verification does not require a receiver to accept or place the message in the inbox. The key pair has separate jobs: - The private key stays with the signer. It creates the signature before mail leaves that sender's administrative domain. - The public key is published for receivers. It lets a verifier test the signature without receiving the private key. - The selector is a label that helps the verifier choose the right public key. It is carried in the DKIM signature's `s=` tag. - The signing domain is carried in the DKIM signature's `d=` tag. Together, `s=` and `d=` identify the DNS location used for the key lookup. The usual DNS name has this shape: ```text <selector>._domainkey.<signing-domain> ``` For example, a signature with `s=selector1` and `d=yourdomain.com` leads a verifier to the public-key location `selector1._domainkey.yourdomain.com`. RFC 6376 specifies this selector and domain-based lookup model. For the broader role of DKIM beside SPF and DMARC, see [email authentication](/learning/dmarc). ![Flow showing a sending system retaining a DKIM private key, adding a signature with selector and domain values, and a receiver retrieving the matching public key through DNS](/images/editorial/generate-dkim-keys/generate-dkim-keys-key-publication-flow.webp "1200x676") *Source: Palisade.* ## When the generation method changes The protocol describes how receivers find and use a public key. It does not require every sender provider to expose the same key-generation control or DNS record type. Use this decision rule: - If your sending provider supplies DKIM values in its setup screen, use the provider's generated values and its documented record type. - If you operate the signing software yourself, generate the pair in that signing system and publish only its public key at the selector location it uses. Where the software expects you to supply a key rather than make one, the [DKIM record generator](/tools/dkim-generator) builds a 2048-bit pair in the browser and gives you both halves. - If a provider supplies CNAME records, publish those CNAME records rather than converting them into a TXT record. - If multiple systems send mail with the same visible From domain, verify each system's DKIM setup separately. A valid record for one selector does not prove that another sender signs with an aligned domain. Microsoft 365 is a clear provider-specific example. Its [DKIM configuration guidance](https://learn.microsoft.com/en-us/defender-office-365/email-authentication-dkim-configure) says that enabling DKIM for a custom domain generates two public-private key pairs. Microsoft keeps the private keys inaccessible and requires CNAME records that point to its DKIM infrastructure. Other senders may publish a TXT record containing public-key data, so a Microsoft 365 CNAME example is not a generic DKIM record. Do not publish, email, or paste a private key into DNS. A receiver needs the public key only. If the private key may have been exposed, follow the signing provider's replacement or rotation process. For the operational lifecycle after deployment, see [how often to rotate DKIM keys](/learning/dkim-key-rotation). ## Worked example: a public DKIM key location This is an illustrative DNS record shape for a system that publishes its own public key as TXT. It is not a value to publish. ```text Record type: TXT Host: selector1._domainkey.yourdomain.com Value: v=DKIM1; k=rsa; p=<base64-encoded-public-key> ``` > Do not publish this example or substitute a key from another domain. Generate the real selector and public-key value in the system that signs your mail. In this example: - `selector1` is a selector chosen or generated by the signing system. - `_domainkey` is the DKIM DNS namespace. - `yourdomain.com` is the signing domain. - `v=DKIM1` identifies the key-record version. - `k=rsa` identifies the key type in this example. - `p=` contains the public-key data. An empty `p=` value has revocation semantics under RFC 6376, so do not use an empty value in a live record. The example explains a TXT-based design only. Microsoft 365 custom domains use two CNAME records named `selector1._domainkey` and `selector2._domainkey`, each pointing to a Microsoft-generated target. Microsoft documents that the exact target includes an account-specific dynamic value. Copy the values from your own Microsoft 365 setup, not from a public example. ## What to check after generating the keys Start with the evidence you have. If you have the provider's setup values, publish the required DNS records exactly as supplied. Then check authoritative DNS and at least one public resolver. A public lookup can confirm that the selector record resolves, but it cannot show whether the provider has started signing the messages that matter. If you have a delivered message, inspect its raw headers for a `DKIM-Signature` header and the receiver-added authentication result. Compare the `d=` signing domain and `s=` selector with the DNS record you published. A message can carry more than one DKIM signature, so identify the one relevant to the visible From domain and your expected sending path. If you only have a domain and selector, use the [DKIM record checker](/tools/dkim) to inspect the public record. This can help catch a missing selector, an incorrect DNS hostname, or a record that does not resolve publicly. It does not prove that a production message is signed, that a receiver accepted the signature, or that future mail will continue to authenticate. After mail has been flowing, check the sender provider's DKIM status and a real message from the exact production path. Then use DMARC aggregate reports to see whether important sources are producing aligned DKIM passes. [DKIM keys in Salesforce](/learning/dkim-keys-salesforce) covers the separate provider-specific workflow for Salesforce. ## Continue with the email-authentication checks A DKIM key record is one part of the sending path. Review [email authentication](/learning/dmarc) to place the DKIM result beside SPF and DMARC before changing a domain's policy. [Review email authentication](/learning/dmarc) An overview cannot prove that a particular provider generated the right key, that DNS has propagated everywhere, or that a real production message has a passing DKIM signature. ## Sources and further reading - [RFC 6376: DomainKeys Identified Mail (DKIM) Signatures](https://datatracker.ietf.org/doc/html/rfc6376) - [Microsoft Learn: configure DKIM for custom domains](https://learn.microsoft.com/en-us/defender-office-365/email-authentication-dkim-configure) - [Palisade DKIM record checker](/tools/dkim) ## Frequently asked questions ### How do I create a DKIM key in Microsoft? Microsoft 365 creates the key pairs when DKIM is enabled for a custom domain. Microsoft keeps the private keys inaccessible and instructs you to publish two CNAME records that point to its DKIM infrastructure. Get the exact CNAME targets from your Microsoft 365 tenant because part of each target is account-generated. ### What is an example of a DKIM key? A DKIM public-key record can have a TXT shape such as `v=DKIM1; k=rsa; p=<public-key-data>` at `selector._domainkey.yourdomain.com`. The selector and `p=` value must come from your own signing system. Do not copy a public key, selector, or CNAME target from another organization. ### How do I set up DKIM for my domain? Set up DKIM in the system that sends your mail, publish the provider's required public-key record or CNAME record in DNS, then send a real message and inspect its DKIM result. The precise setup depends on the sending provider, so follow that provider's current documentation for its generated values and activation process. ### What is the DKIM key? A DKIM key is one half of a cryptographic key pair used for email signing or verification. The private key signs mail in the sending system. The public key is published in DNS so receivers can verify signatures made with the matching private key. ### Can a DKIM DNS lookup prove that email is signed? No. A DKIM DNS lookup can show that a public selector record resolves. It cannot prove that the exact production sender is using the matching private key, that the delivered message has the expected `d=` and `s=` values, or that a receiver verified the signature. --- # How can retail brands use BIMI to boost email open rates? Canonical: https://www.palisade.email/learning/how-can-retail-brands-use-bimi-to-boost-email-open-rates > BIMI can help retail brands make authenticated email easier to recognize. Learn the requirements, rollout checks, and how to measure open-rate impact. Retail brands can use BIMI to make authenticated marketing and transactional email more recognizable in supporting inboxes by publishing a validated brand logo for the sending domain. BIMI does not increase open rates by itself, and logo display depends on each mailbox provider's requirements and rendering decisions. Treat it as a controlled brand-recognition test built on DMARC enforcement, then measure whether it changes results for your own audience. ## Quick takeaways - BIMI associates a domain's published brand indicator with email that passes the required authentication checks. - A retailer needs DMARC enforcement before pursuing BIMI, not only a `p=none` monitoring record. - A logo appearing in one mailbox provider does not guarantee that every provider or client will display it. - A BIMI record points to a logo file and can also reference a Verified Mark Certificate when required by a provider. - Retail teams should compare a stable pre-launch period with a stable post-launch period before attributing any open-rate change to BIMI. - Public DNS checks confirm published records, not the authentication result or placement of every production message. ## How BIMI can affect recognition before an open [BIMI](https://bimigroup.org/implementation-guide/) is an email specification that allows participating mailbox providers to display a brand-controlled logo beside an authenticated message. For a retailer, that can make a familiar sender easier to distinguish among promotions, receipts, delivery notices, and impersonation attempts. The mechanism is narrower than an open-rate promise. BIMI gives providers information they may use to display a logo after they apply their own requirements. The recipient, mail client, and mailbox provider still determine what appears in the inbox and whether the recipient opens the message. DMARC is the trust boundary underneath this process. The [BIMI Group's implementation guidance](https://bimigroup.org/implementation-guide/) says senders need a DMARC policy of `quarantine` or `reject` for BIMI eligibility. DMARC passes only when SPF or DKIM passes with alignment to the visible From domain. A retail domain with a logo file but unresolved alignment failures is not ready to treat BIMI as a production branding change. For the underlying controls, start with the [email authentication learning center](/learning). It covers the SPF, DKIM, and DMARC components that determine whether a message can satisfy DMARC. ## When BIMI is appropriate for a retail sender BIMI is most useful when a retail brand has a stable sending domain, a recognizable mark, and evidence that its legitimate email sources pass DMARC. It is less suitable as a shortcut around unfinished sender inventory or inconsistent authentication. Use this decision rule: - Proceed with a BIMI pilot when the retail domain publishes `p=quarantine` or `p=reject`, important production messages pass DMARC, and the team can keep the logo asset and DNS record under change control. - Pause when major systems such as ecommerce, customer support, shipping, loyalty, or marketing platforms still produce DMARC failures. Fix the authenticated sending path first. - Separate each customer-facing brand domain. BIMI, DMARC, SPF, and DKIM are evaluated against domains and message identifiers, so a parent company should not assume one brand's status proves another brand is ready. - Confirm the target mailbox providers' certificate requirements before purchasing a certificate. [Google's Gmail BIMI guidance](https://support.google.com/a/answer/10911320) documents Gmail's requirements, including a Verified Mark Certificate for BIMI logo display in Gmail. A Verified Mark Certificate is not a replacement for DMARC. It adds trademark-based verification for the logo under the relevant provider program. Certificate issuers document their own eligibility and issuance requirements, so verify those requirements directly before making a procurement decision. For example, [DigiCert's VMC documentation](https://www.digicert.com/tls-ssl/verified-mark-certificates) describes the trademark requirement for its VMC offering. ## A retail BIMI rollout measurement plan A BIMI record is a DNS TXT record at `default._bimi.<domain>`. Its `l` tag identifies the logo location. The `a` tag can identify the certificate location when your intended mailbox provider requires one. ```text Illustrative only. Do not publish this example unchanged. default._bimi.yourdomain.com TXT "v=BIMI1; l=https://assets.yourdomain.com/logo.svg; a=https://assets.yourdomain.com/vmc.pem" ``` Generate the real logo and certificate URLs from your approved asset and certificate process. The BIMI Group specifies requirements for the SVG logo profile and BIMI record construction in its [implementation guide](https://bimigroup.org/implementation-guide/). ![Retail BIMI rollout flow from DMARC enforcement through a controlled before-and-after measurement period](/images/editorial/how-can-retail-brands-use-bimi-to-boost-email-open-rates/how-can-retail-brands-use-bimi-to-boost-email-open-rates-rollout-measurement.webp "1200x829") *Source: Palisade.* Use a deterministic measurement plan: - Record a baseline for the same sending domain, mailbox-provider segment, audience type, and campaign type before the BIMI change. - Keep subject-line approach, send timing, audience selection, and other major campaign changes documented during the comparison period. - Publish the BIMI record only after validating its DNS response and the logo asset URL. - Send test mail through each real production path, including promotional and transactional systems. Inspect the delivered message's `Authentication-Results` header. [RFC 8601](https://www.rfc-editor.org/rfc/rfc8601.html) defines this header field for reporting authentication status. - Compare the post-launch period with the baseline by mailbox provider. Report the observed difference as a result of the test, not as proof that BIMI will produce the same outcome in future campaigns. The four checks answer different questions. Query authoritative DNS and a public resolver to confirm the record is published. Confirm the provider's own BIMI status where available. Inspect a delivered production message to verify its actual authentication result. Then use DMARC aggregate reports after they accumulate to identify sources that still fail alignment. A green DNS result cannot prove production-message authentication, future inbox placement, or a mailbox provider's private display decision. ## Check the domain and record before launch If you have the retail domain and want to inspect its public BIMI and DMARC publication, use the [Palisade BIMI checker](/tools/bimi). Compare the result with the exact domain used in the visible From address, then repeat the check for any distinct retail-brand domain. For an ongoing program, a public lookup leaves an important gap: it cannot inventory every production sender, show which real mail paths fail alignment, or monitor later changes in aggregate-report data. Palisade is agentic DMARC software that analyzes DMARC aggregate reports, identifies sending sources and authentication or alignment issues, and creates prioritized remediation tickets. It can propose the next DMARC policy stage, while your team reviews the evidence and applies any DNS change. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=email_authentication&utm_content=how-can-retail-brands-use-bimi-to-boost-email-open-rates) A public BIMI check and Palisade's DMARC analysis do not guarantee logo display, inbox placement, or future message authentication. For a separate discussion of reported BIMI engagement claims, read [the open-rate evidence in our BIMI guide](/learning/what-is-bimi). Any retail rollout should still use its own controlled measurement period. For a provider-specific implementation of these authentication checks, see [What is BIMI? Brand Indicators for Message Identification](/learning/what-is-bimi). ## Sources and further reading - [BIMI Group implementation guide](https://bimigroup.org/implementation-guide/) - [BIMI Group implementation guide](https://bimigroup.org/implementation-guide/) - [Google Workspace Admin Help: BIMI](https://support.google.com/a/answer/10911320) - [RFC 8601: Message Authentication Status header](https://www.rfc-editor.org/rfc/rfc8601.html) - [DigiCert Verified Mark Certificates](https://www.digicert.com/tls-ssl/verified-mark-certificates) ## Frequently asked questions ### Does BIMI guarantee that retail email open rates will rise? No. BIMI can make a recognized sender easier to identify where a mailbox provider displays the logo, but recipients and providers make the final open and presentation decisions. Measure a controlled before-and-after period for the retail domain. ### Does a retail brand need DMARC enforcement for BIMI? Yes. The BIMI Group's implementation guidance requires a DMARC policy of `quarantine` or `reject` for BIMI eligibility. A `p=none` record supports monitoring but is not sufficient for BIMI. ### Does a BIMI logo prove that every email from the retailer is legitimate? No. BIMI display is tied to the evaluated message and provider requirements. It does not prove every future message will authenticate, and it does not replace review of production `Authentication-Results` headers and DMARC aggregate reports. ### Can one company use the same BIMI setup for several retail brands? Only when those brands use the same authenticated sending domain and approved logo arrangement. Separate customer-facing domains need their own DNS and DMARC validation, and may need separate BIMI records and certificate decisions. ### Do retailers need a Verified Mark Certificate for BIMI? Only if the intended mailbox provider requires one. Gmail documents a Verified Mark Certificate requirement for BIMI logo display. Check each provider's current requirements before purchasing a certificate or planning the rollout. --- # How do you move from reactive to proactive email security? Canonical: https://www.palisade.email/learning/how-can-you-move-from-reactive-to-proactive-email-security-posture > How to move from reactive to proactive email security: establish an authenticated sending baseline, validate real mail, and review change evidence. Move from reactive to proactive email security by treating each sending domain as an operating system with a documented baseline: known senders, published authentication records, delivered-message evidence, and a review step before changes go live. The goal is not to predict every incident. It is to find unauthorized or misconfigured sending paths before a spoofing report, delivery complaint, or policy change forces an urgent response. ## Quick takeaways - A proactive posture starts with an inventory of every system that sends mail using the domain. - DNS records alone do not prove that a production application signs mail or uses the intended return path. - DMARC passes when aligned SPF or DKIM passes for the visible From domain. - A delivered message's `Authentication-Results` header gives evidence about that message's authentication evaluation. - DMARC aggregate reports help identify sending sources and recurring authentication or alignment failures over time. - Every material change needs a defined owner, validation evidence, and a rollback decision. ## How proactive email security works Reactive work begins after an observable failure: a suspicious message uses the brand, a customer reports a phishing email, or a business sender starts landing in junk. The immediate investigation may solve that one event, but it often leaves the wider question unanswered: which systems are authorized to send for the domain, and how would the team notice a new or failing source? A proactive process keeps that evidence current. It starts by listing each sending service, application, gateway, and business owner that uses the domain in the visible From address. For each path, record the expected From domain, envelope sender where applicable, DKIM signing domain, DNS records, and a test recipient that can receive a real production message. DMARC connects the visible From domain to SPF or DKIM alignment. [RFC 9989 defines DMARC](https://datatracker.ietf.org/doc/html/rfc9989) as a mechanism through which a domain owner publishes a policy and requests feedback. A DMARC policy does not make an unauthenticated application begin signing mail. It evaluates the authentication evidence that the actual message path produces. The message layer matters because DNS publication and sender behavior are separate facts. [RFC 8601 defines the `Authentication-Results` header field](https://www.rfc-editor.org/rfc/rfc8601.html), which receivers can use to record authentication assessment results. Inspect a message sent through the exact application or service under review, rather than relying on a generic test from another system. For broader context on authentication controls, visit the [Palisade learning center](/learning). If a recipient moves an accepted message later, see [why Outlook moves emails to junk after they arrive](/email-deliverability/why-does-outlook-move-emails-to-junk-after-they-arrive). Microsoft documents that filtering decision separately in its [anti-spam protection overview](https://learn.microsoft.com/en-us/defender-office-365/anti-spam-protection-about?view=o365-worldwide). Authentication is relevant evidence, but it does not guarantee inbox placement. ## When the answer changes The right next action depends on the evidence available. - If you only have a domain name, inspect the published DMARC record first. A public lookup can show what DNS publishes at that moment. - If you have a real message, inspect its raw headers and compare the visible From domain with the SPF and DKIM domains reported in `Authentication-Results`. - If you have recurring DMARC aggregate reports, use them to identify sources that appear over time and investigate unknown or failing sources before changing policy. - If you are adding a sender, do not treat the vendor's setup screen as final proof. Confirm DNS, the vendor's current status, and a real message from the production path. - If the concern is impersonation or an abnormal message, preserve the original evidence and follow the incident process. [Abnormal email security](/learning/abnormal-email-security) covers that wider security question. A usable decision rule is: do not raise a DMARC policy or approve a new sender until the team can identify the source, show its intended authentication design, and validate the production path. If any of those facts are missing, the work is discovery, not enforcement. > Do not remove or replace an existing SPF, DKIM, or DMARC record solely because a new sending service provides a suggested value. First establish the approved target state and a rollback path. A replacement can disrupt mail from other legitimate systems. ## A proactive evidence baseline Use one evidence record for each sending path. This is an illustrative format, not a DNS record to publish. ```text Sending source: your-email-platform Visible From domain: yourdomain.com Expected SPF identity: mail.yourdomain.com Expected DKIM d= domain: yourdomain.com DNS check: record present at the intended hostname Vendor check: current verification status recorded Message check: delivered test message retained with Authentication-Results DMARC check: aggregate-report source reviewed after reports accumulate Owner: named team or service owner Rollback: prior approved configuration and trigger documented ``` ![Checklist showing the evidence needed to move an email sender from unknown to validated](/images/editorial/how-can-you-move-from-reactive-to-proactive-email-security-posture/how-can-you-move-from-reactive-to-proactive-email-security-posture-evidence-baseline.webp "1200x639") *Source: Palisade.* This baseline applies the four separate validation layers that often get confused: - DNS confirms that an authoritative record is published and publicly resolvable. - Vendor evidence confirms the service's own current setup or verification state. - Message evidence confirms what one delivered message from the production path reports. - DMARC evidence adds the longer-term view once aggregate reports accumulate. None of these layers replaces the others. A passing public lookup does not identify every application that sends mail. A green vendor status does not prove that the visible From domain aligns. A successful test message does not show whether another source uses the same domain. DMARC failure reports can add forensic detail in some circumstances, but they are not a substitute for aggregate visibility and retained message evidence. See [whether DMARC failure reports are worth the trouble](/learning/what-exactly-is-a-dmarc-failure-report-and-why-should-you-care) before making them the center of an operational process. ## Take the next practical step Start with the evidence you have, then preserve the result with the sender's owner and intended configuration. If you have only the domain, use the [DMARC checker](/tools/dmarc) to inspect the currently published policy record. Compare the result with the approved DNS configuration before proposing any policy change. If you have a suspicious or failing message, retain the raw headers and inspect the `Authentication-Results` fields from the receiving system. Compare the visible From domain, SPF identity, and DKIM signing domain. Escalate to the sender owner when the actual path differs from the documented design. If aggregate reports show an unfamiliar source, identify whether it is a legitimate business system before adding it to an approved inventory. Do not authorize a source merely because it appears in a report. ## Track the sending paths that still need remediation A domain lookup is a useful baseline, but a proactive posture also needs a way to identify legitimate sources, review authentication or alignment issues, and decide when the domain appears ready for a stronger DMARC policy. Palisade is DMARC software that analyzes DMARC aggregate-report data, identifies sending sources and authentication or alignment issues, and creates prioritized remediation tickets. It can propose a next policy step when the evidence supports it. A human reviews the evidence and applies any DNS or policy change. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=existing_content_migration&utm_content=how-can-you-move-from-reactive-to-proactive-email-security-posture) Palisade does not autonomously change the DMARC policy, prove every future message will authenticate, or guarantee a receiver's delivery or inbox decision. ## Sources and further reading - [RFC 9989: Domain-based Message Authentication, Reporting, and Conformance](https://datatracker.ietf.org/doc/html/rfc9989) - [RFC 8601: Message Header Field for Indicating Message Authentication Status](https://www.rfc-editor.org/rfc/rfc8601.html) - [Microsoft: Anti-spam protection in Exchange Online Protection](https://learn.microsoft.com/en-us/defender-office-365/anti-spam-protection-about?view=o365-worldwide) - [Palisade DMARC checker](/tools/dmarc) ## Frequently asked questions ### Does a DMARC record make email security proactive? No. A DMARC record publishes a policy and can request feedback, but the operating process becomes proactive only when the team inventories senders, validates real messages, and reviews changes before they create an incident. ### Can a DNS check prove that an email platform is configured correctly? No. A DNS check can confirm a currently visible record. It cannot prove that the platform is using the intended return path, applying a DKIM signature, or sending through the expected production route. ### Should a team move to a stronger DMARC policy after one successful test? No. One successful delivered message is evidence about that path at that time. Before a policy change, validate the important production senders and review aggregate-report evidence as it accumulates. ### Do DMARC aggregate reports identify every security problem? No. Aggregate reports can help identify sending sources and authentication or alignment patterns. They do not replace message-header evidence, an incident investigation, or a receiver's private delivery decision. ### Can stronger authentication guarantee inbox placement? No. Stronger authentication supports trustworthy domain use, but receiving systems can also consider reputation, content, recipient signals, and local policy when handling mail. --- # How can you safely handle malicious email attachments? Canonical: https://www.palisade.email/learning/how-can-you-safely-handle-malicious-email-attachments > How can you safely handle malicious email attachments? Do not open them, verify the request separately, report it, preserve evidence, and stay safe. Yes, you can handle a suspected malicious email attachment safely by leaving it unopened, verifying the request through a separate trusted channel, reporting it through your organization's security process, and preserving the original message for review. A sender name, familiar logo, or expected-looking filename is not enough to establish trust. If you already opened the attachment, stop further interaction and follow your incident-response process promptly. ## Quick takeaways - Do not open, preview, download, reply to, or forward an attachment you did not expect. - Verify a request through a known phone number, chat account, or ticketing channel, not by replying to the suspicious email. - Report the original message using your email service or organization's reporting process before deleting it. - A malicious attachment can arrive in an email that looks like it came from a known person or business. - Email authentication can help identify unauthorized use of a domain, but it does not inspect an attachment for malware. - If an attachment was opened, preserve the message and contact the security team with the time, device, and actions taken. ## How safe attachment handling works Safe handling separates two questions: whether the message is genuinely expected, and whether the file is safe to open. A familiar display name or signature does not answer either question. The [Cybersecurity and Infrastructure Security Agency's phishing guidance](https://www.cisa.gov/secure-our-world/recognize-and-report-phishing) advises people to avoid clicking links or opening attachments in suspicious messages, then independently verify unexpected requests. The safest default is to treat an unexpected file as untrusted until its sender and business purpose are confirmed through a separate channel. That channel matters. Replying to the same message, calling a number in its signature, or using a link inside it may keep you in contact with the attacker. Your mail provider and endpoint protections may scan or quarantine files before they reach you, but those controls do not remove the need for verification. [Microsoft's guidance for responding to phishing](https://support.microsoft.com/en-us/windows/protect-yourself-from-phishing-0c7ea947-ba98-3bd9-7184-430e1f860a44) also recommends reporting suspicious messages rather than interacting with their content. Email authentication helps with a narrower trust signal. DMARC evaluates whether SPF or DKIM authenticated a message with alignment to the visible From domain. [RFC 9989 defines DMARC](https://www.rfc-editor.org/rfc/rfc9989.html) as a mechanism for domain owners to publish handling requests for authentication failures. It does not inspect attachment contents, prove that an attachment is harmless, or prevent a compromised legitimate mailbox from sending malware. For the authentication context behind that distinction, see the [email authentication learning center](/learning). ## When the response should change The immediate rule is straightforward: if the attachment is unexpected or the request cannot be verified independently, do not open it. The next action changes based on what happened. - **You have not opened the file:** Report the message through the approved reporting path. Keep it available for the security team if your policy asks users to preserve suspected phishing. - **You downloaded but did not open the file:** Do not move, rename, share, or upload it to unapproved services. Tell the security team where it was saved so they can advise on handling. - **You opened the file or enabled content:** Stop interacting with it. Disconnect only if your incident-response process instructs you to do so, then contact the security team immediately and preserve the message. - **The request appears to come from a known contact:** Verify the business request using contact details you already know. A real person's mailbox can be compromised, so a familiar sender is not sufficient evidence. - **You administer the sending domain:** Investigate whether the message authenticated and whether it was authorized to use your domain, while treating attachment analysis as a separate security-control task. > Do not forward a suspicious attachment to coworkers for a second opinion. Forwarding can spread the file and can remove evidence needed for investigation. A message may pass DMARC and still contain a malicious attachment if it came from an authorized but compromised sender. Conversely, a DMARC failure does not by itself prove that an attachment contains malware. Keep these findings separate in the incident record. ## A worked response checklist Use this checklist when an unexpected attachment arrives: Attachment received: invoice.zip from a known display name ### 1. Leave the file unopened. ### 2. Do not reply to the message or use its contact details. ### 3. Verify the request through the sender's known phone number, chat account, or ticket system. ### 4. Report the original email using the organization's security process. ### 5. Record whether the file was downloaded, opened, or whether content was enabled. ### 6. Preserve the message unless the security team tells you otherwise. ![Flow showing the safe response to an unexpected email attachment, from leaving it unopened through independent verification and incident reporting](/images/editorial/how-can-you-safely-handle-malicious-email-attachments/malicious-email-attachments-response-flow.webp "1200x829") *Source: Palisade.* The verification result determines the safe outcome: - If the known sender confirms the request and your organization's policy permits the file type, follow the approved scanning or file-transfer process before opening it. - If the sender cannot confirm the request, or you cannot reach them through an independent channel, report the message as suspicious. - If you already interacted with the file, report that fact clearly. It helps the security team decide what evidence to collect and what containment steps may be appropriate. File extensions, archives, and document formats can inform risk, but none supplies a reliable all-clear. Attackers can use misleading filenames, while legitimate business files can also be delivered as archives or documents. The expected context and independent verification are the decision points that matter. For broader employee guidance, see Palisade's tips for protecting yourself from malicious email attachments. ## What to check next, based on your evidence If you have the original message and need to understand its authentication signals, inspect the raw message headers. The [`Authentication-Results` header field defined by RFC 8601](https://www.rfc-editor.org/rfc/rfc8601.html) can show results such as SPF, DKIM, and DMARC that the receiving system recorded. Those results can help an administrator assess whether the visible From domain authenticated, but they do not identify malware in the attachment. If you only have the attachment, do not upload it to a public scanning service unless your organization's policy explicitly permits that. The file may contain confidential information, customer data, or evidence relevant to an investigation. Use your approved security team or endpoint-security workflow. If the message impersonates your organization, preserving the raw headers and attachment details can support investigation of the sending path. [How Palisade handles DMARC for inbound emails](/learning/how-does-palisade-handle-dmarc-for-inbound-emails) explains the boundary between inbound-message authentication evidence and domain-level DMARC operations. ## Inspect the suspicious message's authentication evidence When you have a redacted copy of the original message headers, use Palisade's header analyzer to inspect the authentication results before drawing conclusions about sender identity. [Analyze the email headers](/tools/email-header-analyzer) A header analysis cannot scan the attachment, prove that a sender's mailbox was not compromised, explain every mailbox provider decision, or replace your organization's incident-response process. For teams that need to identify legitimate sources using their own domains over time, Palisade is agentic DMARC software that analyzes DMARC aggregate-report data, identifies authentication and alignment issues, and creates prioritized remediation tickets. A human reviews the evidence and applies any DNS or DMARC policy change. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=existing_content_migration&utm_content=how-can-you-safely-handle-malicious-email-attachments) Palisade does not inspect inbound attachments, automatically repair every sender, or guarantee that future messages will authenticate or reach an inbox. ## Sources and further reading - [CISA: Recognize and report phishing](https://www.cisa.gov/secure-our-world/recognize-and-report-phishing) - [Microsoft Support: How to spot and report phishing emails](https://support.microsoft.com/en-us/windows/protect-yourself-from-phishing-0c7ea947-ba98-3bd9-7184-430e1f860a44) - [RFC 9989: Domain-based Message Authentication, Reporting, and Conformance](https://www.rfc-editor.org/rfc/rfc9989.html) - [RFC 8601: Message Authentication Status](https://www.rfc-editor.org/rfc/rfc8601.html) - [Palisade email header analyzer](/tools/email-header-analyzer) ## Frequently asked questions ### Should I open an attachment if it comes from someone I know? No. Verify an unexpected request through a separate trusted channel first. A known person's mailbox can be compromised, and a display name can be impersonated. ### Can antivirus scanning guarantee that an attachment is safe? No. Scanning is an important control, but it does not guarantee that a file is harmless. Follow your organization's process when a file is unexpected or cannot be independently verified. ### Should I delete a suspicious email attachment immediately? Only after following your organization's reporting and evidence-preservation process. Reporting the original message can help the security team investigate the sender, message headers, and affected recipients. ### Can DMARC block malicious attachments? No. DMARC helps receivers evaluate whether a message is authorized to use a domain in the visible From field. It does not inspect an attachment for malware, and it cannot stop a malicious file sent from a compromised authorized account. ### What should I tell the security team if I opened an attachment? State the message sender, the time you received it, whether you downloaded or opened the file, whether you enabled any content, and the device involved. Preserve the original message and follow the team's instructions. --- # How can you simplify the journey to DMARC enforcement? Canonical: https://www.palisade.email/learning/how-can-you-simplify-the-journey-to-dmarc-enforcement > How can you simplify the journey to DMARC enforcement? Inventory senders, verify alignment, test real mail, then change policy with evidence. Simplify the journey to DMARC enforcement by treating it as an evidence and ownership process, not a DNS switch. Publish a monitoring record, use aggregate reports to identify every observed sender, confirm which senders are legitimate, repair SPF or DKIM alignment, test real production mail, and only then request a stronger DMARC policy. The operator still approves sender status and changes the externally hosted DNS record. ## Quick takeaways - DMARC passes when SPF or DKIM passes with an identifier aligned to the visible From domain. - A `p=none` record requests reporting without asking receivers for quarantine or rejection. - Aggregate reports identify observed sources and authentication outcomes, but they do not prove that a source is business-authorized. - RFC 9989 makes the former `pct` tag historic and defines `t=y` for policy test mode. - A receiver can apply local policy beyond the domain owner's DMARC request. - A green DNS result or vendor status does not prove that the production application is signing and sending as intended. ## How the path to enforcement works [DMARC, defined in RFC 9989](https://www.rfc-editor.org/rfc/rfc9989.html), lets a domain owner publish a DNS TXT policy for messages that use the domain in the visible From field. A message can pass DMARC when either SPF or DKIM passes and the authenticated identifier aligns with that visible From domain. The receiver evaluates that result before considering the published DMARC policy. The main policy values have distinct jobs: - `p=none` asks for no specific handling of DMARC failures. It is commonly used while the domain owner gathers aggregate-report evidence. - `p=quarantine` asks receivers to treat failures as suspicious. - `p=reject` asks receivers not to accept messages that fail DMARC. These are requests, not guarantees. [RFC 9989's receiver requirements](https://www.rfc-editor.org/rfc/rfc9989.html#section-5.4) allow a receiver to consider other local signals and policy. The work becomes manageable when ownership follows the evidence. The messaging or security team reviews observed sources, application owners confirm legitimate services, and DNS owners approve the policy record. That avoids a common mistake: treating every source in a report as approved mail. For protocol context and related terminology, see the [Palisade DMARC learning hub](/learning/dmarc). ## When the answer changes The route needs extra care when mail changes identity in transit. [RFC 9989's interoperability guidance](https://www.rfc-editor.org/rfc/rfc9989.html#section-7.4) says general-purpose domains whose users send mail through Internet mailing lists should not publish `p=reject` without addressing the resulting interoperability risk. Forwarding and mailing-list flows can alter SPF and DKIM results, so validate those paths with delivered-message headers and report data before increasing policy. Use this decision rule: - If a source is recognized and has an aligned SPF or DKIM pass, keep monitoring its real production path. - If a source is recognized but fails alignment, repair the vendor configuration or sending-domain setup before enforcement. - If a source is unfamiliar, ask the relevant business owner to classify it. Do not authorize it from an IP address alone. - If a low-frequency sender has not appeared in recent reports, test it deliberately before moving policy. - If an indirect flow such as a mailing list matters to your domain, validate that flow separately and retain a rollback plan. > Do not publish two DMARC TXT records at the same `_dmarc` hostname. RFC 9989 treats multiple records at the same policy-domain name as a DMARC processing error, which can leave receivers without a usable policy. ## A worked monitoring-to-enforcement record A DMARC policy record is a TXT record at `_dmarc.<domain>` and begins with `v=DMARC1`, as specified in [RFC 9989's record format](https://www.rfc-editor.org/rfc/rfc9989.html#section-4.8). ```text Illustrative only. Do not publish this reporting address. Type: TXT Name: _dmarc.yourdomain.com Content: v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com TTL: Auto ``` `example.com` is a reserved example domain. Use a reporting address that your organization controls and that is authorized to receive the reports. A `rua` address gives the record a plausible shape but does not create monitoring. In Cloudflare, [create a DNS record from DNS Records, Add record, then choose the record type and complete the fields](https://developers.cloudflare.com/dns/manage-dns-records/how-to/create-dns-records/). Enter `TXT` as the type, `_dmarc` as the name for the zone's root domain, the complete DMARC value as content, and the TTL approved by your DNS change process. Confirm there is no existing DMARC TXT record first, then save only through the approved change path. After reports accumulate, use the reported source, aligned domain, authentication outcome, and message volume to create a sender inventory. Follow each source through four checks: - Query authoritative DNS and at least one public resolver to confirm the intended record is published. - Check the sending vendor's current authentication status. - Send a real message through the exact production application and inspect its `Authentication-Results` header. [RFC 8601 defines this header field](https://www.rfc-editor.org/rfc/rfc8601.html). - Review DMARC aggregate reports after enough data accumulates to cover the sending pattern. ![Decision flow for moving a domain from DMARC monitoring to quarantine or reject based on sender ownership, alignment, real-message testing, and aggregate-report evidence](/images/editorial/how-can-you-simplify-the-journey-to-dmarc-enforcement/how-can-you-simplify-the-journey-to-dmarc-enforcement-enforcement-decision-flow.webp "1200x829") *Source: Palisade.* When you are ready to test a stronger policy, use RFC 9989's current semantics. The [`pct` tag](/learning/glossary/dmarc-pct) is historic because intermediate percentages were implemented inconsistently. With `t=y`, `p=quarantine` requests an applied policy of `none`, while `p=reject` requests an applied policy of `quarantine`. [RFC 9989's testing tag definition](https://www.rfc-editor.org/rfc/rfc9989.html#section-4.7) describes that one-level reduction. ```text Illustrative only. v=DMARC1; p=quarantine; t=y; rua=mailto:dmarc-reports@yourdomain.com ``` Keep the previous record, the approved next record, a rollback trigger, and an owner for unresolved senders. After each change, repeat the DNS, vendor, message, and aggregate-report checks. A published record alone cannot show that every business-critical application is aligned. ## The practical next step Start with the evidence you have: - If you only have a domain name, [check the published DMARC record](/tools/dmarc) and compare it with your approved DNS change record. - If you have aggregate reports, turn them into a sender list, then assign each unfamiliar source to a business owner for classification. - If you have a known sender failure, inspect a delivered message from that production path before editing SPF, DKIM, or DMARC. - If the wider problem is organizational ownership and stalled approvals, read [why corporations struggle with DMARC enforcement](/learning/why-do-corporations-struggle-to-move-from-dmarc-awareness-to-enforcement). Palisade is agentic DMARC software that analyzes DMARC aggregate-report data, identifies observed sending sources and authentication or alignment issues, creates prioritized remediation tickets, and proposes a next policy milestone when the evidence appears ready. The human team reviews unfamiliar senders, remediation evidence, policy timing, and the DNS change. ## Continue the enforcement work with report evidence A DMARC record lookup can confirm what DNS publishes today, but it cannot inventory every production sender that later fails alignment or monitor new sending paths. Palisade organizes aggregate-report evidence and remediation work so the team can review a proposed move toward enforcement with the relevant sender context. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=dmarc_enforcement&utm_content=how-can-you-simplify-the-journey-to-dmarc-enforcement) Palisade does not autonomously change an externally hosted DMARC record, guarantee delivery or inbox placement, or replace business-owner approval for unfamiliar senders. ## Sources and further reading - [RFC 9989: Domain-based Message Authentication, Reporting, and Conformance](https://www.rfc-editor.org/rfc/rfc9989.html) - [RFC 8601: Message Header Field for Indicating Message Authentication Status](https://www.rfc-editor.org/rfc/rfc8601.html) - [Cloudflare: Create DNS records](https://developers.cloudflare.com/dns/manage-dns-records/how-to/create-dns-records/) - [Palisade domain overview documentation](https://docs.palisade.email/page-breakdowns/domain-overview) - [Palisade guide to fixing authentication issues](https://docs.palisade.email/guides/fixing-authentication-issues) ## Frequently asked questions ### Can I move directly from `p=none` to `p=reject`? Only if the domain owner has already inventoried legitimate senders, validated aligned authentication on their real production paths, and addressed relevant indirect-mail flows. A change to `p=reject` can affect legitimate mail that still fails DMARC. ### Does `p=none` stop spoofing? No. `p=none` asks for no specific receiver handling of DMARC failures. It can request aggregate reports through `rua`, which provides evidence for sender inventory and remediation. ### Does a DMARC aggregate report prove that a sender is legitimate? No. An aggregate report shows observed traffic and authentication results. Business owners still need to confirm whether an unfamiliar service is authorized to send using the domain. ### Should I use `pct` to stage DMARC enforcement? No. RFC 9989 marks `pct` historic. Use current policy testing semantics with `t=y` where appropriate, and validate how important receiving environments handle the policy. ### Does `p=reject` guarantee that spoofed mail never reaches recipients? No. `p=reject` is a strong request to receiving systems after DMARC failure. Receivers make their own final decisions, and DMARC does not guarantee delivery, inbox placement, or a uniform outcome at every receiver. --- # How do Exchange Online sending and receiving limits work? Canonical: https://www.palisade.email/learning/how-do-exchange-online-sending-and-receiving-limits-work > Exchange Online sending and receiving limits use separate recipient, message, mailbox, and tenant counters. See which limit applies and how to verify it. Exchange Online sending and receiving limits are separate service protections with different counters and time windows. A recipient can hit an hourly receiving threshold, a sender can hit per-message, per-minute, or rolling recipient limits, and a tenant can hit an external-recipient limit. Use the NDR, message trace, and Microsoft reporting to identify the exact counter before changing mail flow or assuming an authentication problem. ## Quick takeaways - Exchange Online does not use one universal sending quota. - The receiving limit and sender-recipient pair limit protect the destination mailbox, group, or public folder. - The recipient rate limit counts recipients, not messages, in a rolling 24-hour period. - A tenant can exceed its external-recipient allowance even when individual mailboxes remain below their own limits. - A temporary SMTP response is evidence of a retry condition, while an NDR or Microsoft report can identify a more specific service limit. - Public DNS and message-header checks cannot prove an Exchange Online tenant's current capacity or reset time. ## How Exchange Online limits work Microsoft documents Exchange Online limits by the object being protected: an individual recipient, a submitting mailbox, a single message, or the tenant. The current [Exchange Online limits service description](https://learn.microsoft.com/en-us/office365/servicedescriptions/exchange-online-service-description/exchange-online-limits) is the source of record for the applicable plan, scope, and current value. For the pre-send file-size question, see [the maximum email attachment size](/learning/max-size-for-email-attachment). That article separates raw file size, encoded message size, and the lowest enforced limit on the route. For receiving, Microsoft publishes an overall limit of 3,600 messages per hour for an Exchange Online recipient. The limit applies to users, groups, and public folders. Microsoft also publishes a sender-recipient pair limit of 33% of the overall receiving limit. That pair limit controls how much one sender can send to one recipient during the same period. For outbound mail, Microsoft separates several counters: - The recipient rate limit is 10,000 recipients per user in a rolling 24-hour period for the Exchange Online plans listed in Microsoft's current limits table. - The recipient limit controls the number of recipients on one message. Microsoft documents that it can be customized up to 1,000 recipients for a mailbox. - The message rate limit is 30 messages per minute. Microsoft says excess outbound volume can be throttled into later minutes. - The Tenant External Recipient Rate Limit, or TERRL, is a separate rolling 24-hour allowance for external recipients across the tenant. These values are not interchangeable. A mailbox sending one message to 500 addresses consumes 500 recipient units for its rolling recipient counter. A mailbox sending many separate messages to one address can instead trigger a message-rate or sender-recipient-pair condition. For wider mail-flow context, see the [email deliverability learning hub](/email-deliverability). ![Capacity evidence map showing Exchange Online limits grouped by recipient, mailbox, message, and tenant scope](/images/editorial/how-do-exchange-online-sending-and-receiving-limits-work/how-do-exchange-online-sending-and-receiving-limits-work-capacity-evidence.webp "1200x829") *Source: Palisade.* ## When the answer changes Start with the direction of the affected message, then identify what Exchange Online is counting. A recipient who stops receiving internet or on-premises mail after unusually high inbound volume may have reached the receiving limit. Microsoft states that internal messages still count toward the threshold, but the receiving limit does not block internal messages in the same way it blocks internet and on-premises delivery. A notification storm, mail loop, scanner, or ticketing system can create this pattern without indicating a DMARC failure. One sender failing only for one recipient points more narrowly to the sender-recipient pair limit or another sender-specific control. Microsoft’s [mailboxes exceeding receiving limits report](https://learn.microsoft.com/en-us/exchange/monitoring/mail-flow-reports/mailboxes-exceeding-receiving-limits-report) distinguishes overall receiving-limit events from sender-recipient pair events. Its Warm limit is a logging threshold, while its Hot limit indicates the mailbox exceeded the receiving threshold. For outbound mail, a submission NDR provides stronger evidence than a count inferred from sent items. Microsoft’s [submission quota troubleshooting guidance](https://learn.microsoft.com/en-us/troubleshoot/exchange/email-delivery/ndr/fix-error-for-submission-quota-exceeded-in-exchange-online) identifies the recipient rate limit when the NDR states: ```text The message can't be submitted because the sender's submission quota was exceeded ``` That condition is a rolling recipient-count problem. It does not mean the mailbox sent 10,000 separate messages, and it does not reset automatically at midnight. If the sender did not produce the observed volume, Microsoft advises investigating possible account compromise. A temporary SMTP response has a different meaning. A 421 response normally tells the sending system to retry later, subject to the SMTP server's response and the sender's retry policy. It does not, by itself, prove which Exchange Online counter was reached. See [what SMTP error 421 means and how to fix it](/learning/what-does-smtp-error-421-mean-and-how-to-fix-it) before treating a temporary response as a permanent block. > Do not raise connection concurrency or repeatedly resubmit the same message to work around a service limit. Retries can add volume to the same protected scope and make the evidence harder to interpret. ## Worked capacity-evidence example Use a short evidence record before choosing an operational response. This example is illustrative only. Replace every value with evidence from the affected Exchange Online tenant. ```text Direction: outbound Observed object: submitting mailbox Observed response: "The message can't be submitted because the sender's submission quota was exceeded" Counter to verify: rolling recipients addressed by that sender Time window: rolling 24 hours Additional evidence: message trace, sent-message recipient counts, delegate activity Do not infer: the tenant's TERRL state or a recipient's hourly receiving state ``` The next action follows the evidence available: - If an NDR identifies a submission quota, count recipients addressed by the actual submitting user. A personal contact list can expand into individual recipients, while a distribution group in the shared address book has different counting behavior under Microsoft’s documented rules. - If a recipient is missing inbound internet mail, review the receiving-limits report and compare timestamps with the recipient's inbound volume. Do not diagnose it from the sender's sent folder. - If many mailboxes fail when sending to external domains, check the tenant-level external-recipient evidence in the Microsoft 365 admin experience and Exchange reporting. A single mailbox's history cannot establish TERRL status. - If the sending system received a temporary SMTP response, preserve the exact response, timestamps, retry attempts, and source IP. Treat it as transport evidence until Microsoft reporting or the NDR narrows the cause. Sending through a shared mailbox does not necessarily move the recipient-rate counter to the visible From address. Microsoft documents that delegated sending is counted for the delegate who used the permission. That distinction matters for service accounts and operations teams that send as shared identities. ## Check the evidence before changing mail flow Collect the original NDR or SMTP response first. Then inspect the affected mailbox, recipient, or tenant at the scope the response names. Microsoft’s limits page establishes what the service can enforce, but it does not prove that a particular tenant reached a specific threshold. If you have a delivered message or an NDR with raw headers, use Palisade's [email header analyzer](/tools/email-header-analyzer) to inspect the message path and authentication results alongside the Exchange Online evidence. This can help separate a submission or delivery limit from a message-path authentication issue. [Inspect the message headers](/tools/email-header-analyzer) A header analysis cannot reveal Exchange Online's tenant counters, reset a quota, prove a receiver's private decision, or confirm that future messages will be accepted. If recurring mail-flow incidents expose unknown sending systems or SPF and DKIM alignment failures, [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=existing_content_migration&utm_content=how-do-exchange-online-sending-and-receiving-limits-work). Palisade analyzes DMARC aggregate-report data, identifies sending sources and authentication or alignment issues, and proposes prioritized remediation work for human review. It does not change Exchange Online limits, alter Microsoft tenant settings, or guarantee delivery. ## Sources and further reading - [Microsoft Exchange Online limits](https://learn.microsoft.com/en-us/office365/servicedescriptions/exchange-online-service-description/exchange-online-limits) - [Microsoft report for mailboxes exceeding receiving limits](https://learn.microsoft.com/en-us/exchange/monitoring/mail-flow-reports/mailboxes-exceeding-receiving-limits-report) - [Microsoft troubleshooting for sender submission quota exceeded](https://learn.microsoft.com/en-us/troubleshoot/exchange/email-delivery/ndr/fix-error-for-submission-quota-exceeded-in-exchange-online) - [Palisade email header analyzer](/tools/email-header-analyzer) ## Frequently asked questions ### Does the 10,000 Exchange Online recipient rate limit mean 10,000 messages? No. The recipient rate limit counts recipients addressed by a user in a rolling 24-hour period. One message addressed to 100 recipients counts as 100 recipients. ### Does the Exchange Online receiving limit block internal messages? No. Microsoft states that internal messages count toward the receiving threshold, but the receiving limit does not block internal messages in the same way it blocks messages from internet and on-premises senders. ### Can one sender be limited while other senders can still reach the same mailbox? Yes. Microsoft documents a sender-recipient pair limit that is separate from the recipient's overall hourly receiving limit. The receiving-limits report can help distinguish the two conditions. ### Does a 421 SMTP response prove that Exchange Online reached a quota? No. A 421 response is temporary SMTP evidence that the sending system should retry according to the response and its retry policy. Use the exact NDR, message trace, and Microsoft reporting to identify the applicable Exchange Online limit. ### Does a correct SPF or DKIM record increase Exchange Online sending limits? No. SPF and DKIM authenticate mail and can support deliverability, but they do not change Exchange Online recipient, message-rate, receiving, or tenant external-recipient limits. --- # How do you warm up a new sending domain safely? Canonical: https://www.palisade.email/learning/how-do-you-warm-up-a-new-sending-domain-safely > Warm up a new sending domain safely by authenticating mail first, increasing wanted mail gradually, and pausing when delivery signals worsen. Warm up a new sending domain safely by authenticating mail before sending, starting with recipients who expect and want the mail, then increasing volume only while provider feedback remains healthy. There is no universal daily schedule that proves a domain is ready. Google advises senders facing delivery problems to lower volume, test, and increase gradually after successful delivery. The safe pace depends on the exact sending path and recipient response. ## Quick takeaways - Publish SPF, DKIM, and DMARC before sending production mail from a new domain. - Start with mail that recipients expect, rather than adding inactive or unengaged addresses early. - Increase volume gradually and pause increases when deferrals, complaints, or bounces worsen. - Google asks senders to keep spam rates below 0.10% and avoid reaching 0.30%. - Check delivered-message authentication results, not only DNS records or an ESP status indicator. - A warmup supports reputation development but cannot guarantee inbox placement. ## How safe domain warmup works A sending domain earns delivery signals through the mail it sends and the response it receives. For Gmail, [Google's Email sender guidelines](https://support.google.com/a/answer/81126) require senders to authenticate mail with SPF or DKIM and recommend SPF, DKIM, and DMARC for all senders. Google also requires bulk senders to authenticate with SPF, DKIM, and DMARC, keep spam rates below its thresholds, and support one-click unsubscribe for subscribed marketing mail. Authentication establishes a verifiable identity for the message. It does not establish that recipients want the message. Send only mail your recipients expect, use clear consent and unsubscribe handling for marketing mail, and keep list quality under review. [Yahoo's sender best practices](https://senders.yahooinc.com/best-practices/) likewise ask senders to authenticate mail, keep complaint rates low, and make unsubscribing easy. A safe warmup therefore has two parts: - Technical identity: SPF and DKIM pass, and at least one passes with alignment to the visible From domain for DMARC. - Controlled audience expansion: volume grows only after the same sending path produces healthy delivery and complaint signals. For broader context on the outcome you are monitoring, see [email deliverability](/email-deliverability). ## When the answer changes The correct ramp changes with the traffic type and sending infrastructure. A domain sending transactional messages should begin with real, expected events such as password resets, receipts, or account notices. Do not create artificial messages solely to manufacture engagement. A marketing domain should begin with the people most likely to recognize the sender and expect the campaign, then add less-recently engaged segments only after results remain stable. A dedicated IP adds a separate reputation variable. Google explains that [IP reputation and domain reputation are distinct](https://support.google.com/mail/answer/81126), so successful history on one does not prove the other is ready. On a shared IP pool, the provider manages the shared IP reputation, but your new From domain still needs authenticated, wanted traffic. Use this decision rule: - If DNS, vendor status, and a delivered test message all show authentication passing, begin with a small production volume to expected recipients. - If a receiving provider defers mail or complaints increase, stop increasing volume. Reduce the next batch if the problem persists, then investigate the affected provider and sending path. - If authentication fails in delivered headers, fix authentication and alignment before raising volume. A healthy-looking DNS record alone is insufficient. - If the domain sends at bulk volume to Gmail, follow the [Gmail bulk sender requirements](https://support.google.com/a/answer/81126) for the entire sending program. > Do not move a production sending domain to a larger audience because an ESP dashboard is green. Validate the exact message path through a delivered message and provider feedback first. ## Worked warmup decision example This is an illustrative operating record, not an official provider schedule. Replace the volumes and observation window with values appropriate to your audience, ESP limits, and business-critical mail. The [email warmup calculator](/tools/warmup-calculator) lays out a day-by-day version between any starting and target volume, and checks the target against the daily sending limits Google Workspace and Microsoft 365 publish. ```text Sending domain: mail.yourdomain.com Audience for first batch: recipients who recently requested or expect this mail Authentication check: SPF pass, DKIM pass, DMARC pass in a delivered message Increase condition: no new provider deferrals and complaint rate remains below provider guidance Hold condition: rising complaints, hard bounces, or deferrals at a receiving provider Next action after a hold: keep volume flat or reduce it, inspect the exact sending path, then retest ``` The four layers matter during each increase: - DNS: query the authoritative DNS provider and a public resolver for the SPF, DKIM, and DMARC records. - Vendor: confirm the sending platform reports the domain as authenticated, using its current verification status. - Message: send a real test through the production application and inspect its headers. [RFC 8601 defines the `Authentication-Results` header field](https://www.rfc-editor.org/rfc/rfc8601.html), which can show the receiver's SPF, DKIM, and DMARC evaluation. - DMARC: review aggregate reports after they accumulate to find sending sources and alignment failures that a single test message may miss. ![Decision flow for safely increasing new-domain sending volume based on authentication, delivery feedback, and complaint signals](/images/editorial/how-do-you-warm-up-a-new-sending-domain-safely/how-do-you-warm-up-a-new-sending-domain-safely-warmup-flow.webp "1200x829") *Source: Palisade.* ## What to do next, based on the evidence you have If you only have the domain name, inspect the public DMARC record with the [Palisade DMARC checker](/tools/dmarc). Confirm that the record exists and compare it with the policy your team intended to publish. You can also use the [Palisade DKIM checker](/tools/dkim) to inspect the signing record for a selected selector. If you have access to the sending platform, verify its current authentication status and send a real message through the same application, return path, and From domain that production mail will use. Review the delivered message's `Authentication-Results` values. A provider dashboard can confirm its setup state, while the delivered message shows what the receiving system evaluated. If volume is already increasing, use provider feedback to decide whether to hold or expand. [Google Postmaster Tools](https://support.google.com/mail/answer/9981691) provides Gmail-specific data for eligible domains, including spam rate and [domain reputation](/tools/domain-reputation). Check the provider where signals are degrading rather than assuming Gmail results apply to every mailbox provider. After enough DMARC aggregate-report data exists, compare every observed source with the intended sending inventory. Palisade autonomously analyzes DMARC aggregate-report data, identifies sending sources and authentication or alignment issues, and creates prioritized remediation tickets. It can propose the next policy step when the evidence supports it, while your team reviews the evidence and applies any DNS change. ## Inspect the DMARC record before you raise volume A public DMARC lookup is a useful first check when the only evidence you have is the sending domain. Inspect the published record before increasing a new domain's audience, then compare it with a delivered production-path message. [Check the new domain's DMARC record](/tools/dmarc) A public-record check cannot prove that the sending platform signs every message, identify every production source, monitor future DNS changes, or guarantee a receiver's inbox placement. For ongoing DMARC-report analysis across your sending inventory, [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=email_deliverability&utm_content=how-do-you-warm-up-a-new-sending-domain-safely). ## Sources and further reading - [Google Email sender guidelines](https://support.google.com/a/answer/81126) - [Google Postmaster Tools help](https://support.google.com/mail/answer/9981691) - [Yahoo sender best practices](https://senders.yahooinc.com/best-practices/) - [RFC 8601: Authentication-Results header field](https://www.rfc-editor.org/rfc/rfc8601.html) - [Palisade DMARC checker](/tools/dmarc) ## Frequently asked questions ### How long does it take to warm up a new sending domain? There is no official universal duration. Increase only as fast as the domain can send expected, authenticated mail without worsening complaints, bounces, or provider deferrals. Higher target volume and weaker recipient engagement usually require a longer observation period. ### Should I send test messages to coworkers first? Yes, sending a small number of real production-path tests to internal recipients can help validate authentication and message handling. Internal tests do not prove how external mailbox providers will treat larger production traffic, so continue validating with expected external recipients and provider feedback. ### Can I warm up a sending domain with artificial engagement? No. Artificial engagement does not validate whether your real recipients expect or want your mail. Use legitimate traffic tied to an actual recipient relationship and monitor the same sending path you intend to scale. ### Does SPF and DKIM passing mean the domain is warmed up? No. SPF and DKIM passing show authentication for that message. Warmup also depends on recipient response and provider delivery signals over time. DMARC aggregate reports can help identify sources that still fail alignment. ### Do I need DMARC before warming up a new sending domain? Yes, DMARC should be published before production sending begins. Google requires DMARC for bulk senders, and a DMARC record also provides a reporting and alignment framework for understanding authenticated sending sources. --- # How does a DMARC record protect my domain and improve email delivery? Canonical: https://www.palisade.email/learning/how-does-a-dmarc-record-protect-my-domain-and-improve-email-delivery > DMARC protects your domain by requesting handling for spoofed mail and supports delivery when legitimate mail passes aligned SPF or DKIM today. A DMARC record protects your domain by telling receiving mail systems how to handle messages that use your visible From domain but fail DMARC authentication. It supports email delivery when your legitimate mail has an aligned SPF or DKIM pass, because receivers can distinguish authorized mail from unauthenticated impersonation attempts. DMARC does not guarantee inbox placement or force every receiver to take the requested action. ## Quick takeaways - DMARC checks whether SPF or DKIM passed and aligned with the visible From domain. - A DMARC policy applies after DMARC failure, not to mail that passes DMARC. - `p=none` requests monitoring, while `p=quarantine` and `p=reject` request stronger handling. - A receiving mail system makes its own final delivery decision. - Legitimate senders need aligned SPF or DKIM before a domain moves to stronger DMARC enforcement. - DMARC supports deliverability, but reputation, content, and receiver policy still affect placement. ## How a DMARC record protects a domain [RFC 9989 defines DMARC](https://www.rfc-editor.org/rfc/rfc9989.html) as a mechanism that lets a domain owner publish a DNS policy for mail using that domain in the visible From field. A message passes DMARC when SPF or DKIM passes and the authenticated domain aligns with that visible From domain. That alignment matters because a message can contain a familiar From address while being sent through infrastructure the domain owner did not authorize. When neither aligned SPF nor aligned DKIM passes, the receiving system evaluates the published DMARC policy. The main policy tag is `p`: - `p=none` asks receivers to take no specific disposition action for DMARC failures. - `p=quarantine` asks receivers to treat failing mail as suspicious. - `p=reject` asks receivers not to accept failing mail. A receiver can apply local policy when deciding what to do with a failing message. A published `p=reject` record is therefore a strong domain-owner request, not proof that every receiver rejects every failing message. ![DMARC decision flow showing aligned SPF or DKIM passing legitimate mail, and the published policy applying after authentication failure](/images/editorial/how-does-a-dmarc-record-protect-my-domain-and-improve-email-delivery/how-does-a-dmarc-record-protect-my-domain-and-improve-email-delivery-dmarc-flow.webp "1200x676") *Source: Palisade.* For a broader explanation of the record and policy tags, visit the [DMARC learning hub](/learning/dmarc). ## When DMARC supports delivery, and when it does not DMARC supports delivery when a legitimate sending path produces an aligned SPF or DKIM pass. It gives receivers a standard authentication result for that message, while enforcement makes unauthorized use of the visible From domain harder. Google's [Email sender guidelines](https://support.google.com/a/answer/81126) require bulk senders to authenticate email with SPF or DKIM and require DMARC for messages sent from a domain that sends more than 5,000 messages per day to Gmail accounts. Those requirements show that authentication is part of current sender expectations. They do not mean that a DMARC pass guarantees inbox placement. Use this decision rule: - If a production message has an aligned SPF or DKIM pass, DMARC can pass for that message. - If neither identifier aligns, DMARC fails and the receiver can consider the published policy. - If the domain has no usable DMARC record, the receiver has no DMARC policy request from that domain. - If a public DNS lookup shows a correct record, it still does not prove that an application is signing mail, using the intended return path, or reaching the inbox. A domain's delivery outcome can also depend on receiver-specific reputation and local filtering. Check the [email domain reputation guidance](/learning/how-can-you-check-and-improve-your-email-domain-reputation) alongside authentication results, but do not treat reputation data as a DMARC pass or fail result. > Do not move to `p=quarantine` or `p=reject` until the legitimate production senders using the visible From domain have been identified and tested. An unknown sender that fails DMARC can lose mail when stronger enforcement begins. ## A worked DMARC record and message result This illustrative record requests aggregate reports while asking receivers to reject messages that fail DMARC: ```text v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourdomain.com ``` Do not publish this example unchanged. Use a report destination your organization controls and authorizes. [RFC 9989](https://www.rfc-editor.org/rfc/rfc9989.html) defines `rua` as the tag for aggregate report destinations. For a message from `billing@yourdomain.com`, the result that matters is an aligned pass. The `Authentication-Results` field is the standardized header field receivers use to report authentication assessments, as defined by [RFC 8601](https://www.rfc-editor.org/rfc/rfc8601.html). ```text Authentication-Results: receiver.example; dkim=pass header.d=yourdomain.com; spf=pass smtp.mailfrom=yourdomain.com; dmarc=pass header.from=yourdomain.com ``` This example shows both mechanisms aligned to `yourdomain.com`. Only one aligned SPF or DKIM pass is needed for DMARC to pass. A DNS record alone cannot establish this result. Inspect a real delivered message from the exact production path, then compare its authentication results with the record. Your domain may also need other DNS records for its sending infrastructure. The [business email DNS records guide](/learning/dns-records-for-business-email) covers the related record types without treating them as substitutes for delivered-message evidence. ## What to check next Start with the evidence you have: - If you only have a domain name, [check the published DMARC record](/tools/dmarc). Confirm the hostname, tags, and policy the public DNS response shows. - If you have a delivered message, inspect its raw headers for `Authentication-Results`. Compare `header.from` with the domain that passed SPF or DKIM. - If you administer the sending service, verify its current authentication status and the return-path or DKIM configuration in that service's documentation or interface. - After reports accumulate, review aggregate-report data to identify sources that fail authentication or alignment before changing the policy. A public DNS check is a useful first check, but it cannot prove a production sending path, continuous DNS state, a receiver's private decision, or future inbox placement. Validate at four layers: authoritative DNS and a public resolver, the sender's vendor status, a real delivered message, and DMARC aggregate reports after they accumulate. ## Use DMARC evidence to prepare for enforcement A record lookup can show what the domain publishes today. The remaining question is which legitimate senders still fail alignment, and whether the domain is ready for a stronger policy. Palisade is DMARC software that analyzes DMARC aggregate-report data, identifies sending sources and alignment issues, and creates prioritized remediation tickets. It can propose the next policy step when the evidence supports it, while a human reviews the evidence and applies the DNS change. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=email_authentication&utm_content=how-does-a-dmarc-record-protect-my-domain-and-improve-email-delivery) Palisade does not change your DMARC policy autonomously, guarantee inbox placement, or prove that every future message will authenticate. ## Sources and further reading - [RFC 9989: Domain-based Message Authentication, Reporting, and Conformance](https://www.rfc-editor.org/rfc/rfc9989.html) - [RFC 8601: Message Header Field for Indicating Message Authentication Status](https://www.rfc-editor.org/rfc/rfc8601.html) - [Google Email sender guidelines](https://support.google.com/a/answer/81126) - [Palisade DMARC checker](/tools/dmarc) ## Frequently asked questions ### Does DMARC stop all phishing that uses my brand? No. DMARC helps stop unauthorized mail that uses your exact visible From domain when receivers evaluate and apply the policy. It does not stop look-alike domains, compromised legitimate accounts, or every other phishing technique. ### Does a DMARC pass mean the message will reach the inbox? No. A DMARC pass confirms the required aligned SPF or DKIM authentication result for that message. The receiving system can also consider its own reputation signals, content filtering, and local policy. ### Can SPF pass while DMARC fails? Yes. SPF can pass for a domain that does not align with the visible From domain. DMARC requires an SPF pass with alignment, or a DKIM pass with alignment. ### Is `p=none` useful? Yes. `p=none` publishes a valid DMARC policy while requesting no specific handling for failures. When paired with `rua`, it can support aggregate-report collection while a team identifies legitimate senders and fixes alignment problems. ### Should I publish `p=reject` immediately? No. Publish stronger enforcement only after validating the legitimate sending paths that use the domain. Check DNS, sender configuration, real delivered-message headers, and aggregate-report results before requesting rejection. --- # Can Amazon SES and Palisade be used together for bulk sender compliance? Canonical: https://www.palisade.email/learning/how-does-the-amazon-ses-palisade-partnership-simplify-bulk-sender-compliance > Amazon SES and Palisade for bulk-sender compliance: authenticate SES mail, validate real messages, then use DMARC evidence for safe remediation. Amazon SES and Palisade can support the same bulk-sender compliance workflow, but they are separate products. Amazon SES provides the sending service and documents how to authenticate its mail. Palisade can then analyze DMARC aggregate-report data, identify sources and alignment issues, and propose prioritized remediation work. The public sources for this article do not establish a partnership, bundle, shared dashboard, integration, or Amazon quote involving the two products. ## Quick takeaways - Amazon SES authentication starts with verifying the identity that sends mail and configuring DKIM for that identity. - Amazon SES documentation recommends using a custom MAIL FROM domain when SPF alignment is required. - A DNS record or an SES verification status does not prove that production mail is using the intended authentication path. - A delivered message's `Authentication-Results` header provides message-level evidence for SPF, DKIM, and DMARC evaluation. - DMARC aggregate reports can reveal sources and alignment failures after mail has been sent. - Palisade is a separate DMARC-monitoring and remediation workflow, not an Amazon SES feature or integration. ## How the SES and DMARC workflow works [Amazon SES guidance for bulk-sender requirements](https://aws.amazon.com/blogs/messaging-and-targeting/navigate-bulk-sender-requirements-with-amazon-ses/) describes authentication as part of preparing SES mail for mailbox-provider requirements. For an SES identity, DKIM is configured through the identity's authentication settings. Amazon SES can use Easy DKIM, which generates the DNS records needed for SES to sign mail with DKIM, as described in the [Amazon SES DKIM documentation](https://docs.aws.amazon.com/ses/latest/dg/send-email-authentication-dkim.html). DMARC evaluates the visible From domain. A message can pass DMARC when SPF passes with an aligned authenticated domain, or when DKIM passes with an aligned `d=` domain. The [vendor email-authentication hub](/learning/esp-setup) has broader guidance for provider-specific authentication work. The practical split is straightforward: - Amazon SES sends the message and supplies the SES identity and DKIM configuration. - DNS publishes the authentication records that SES and receivers use. - The receiving mailbox provider evaluates the message and makes its own delivery decision. - DMARC reports provide later aggregate evidence about authentication outcomes. - Palisade can analyze those reports, identify sources and authentication or alignment issues, and create prioritized remediation tickets for human review. ![Flow showing the separate responsibilities of Amazon SES, DNS, receiving providers, DMARC reports, and Palisade](/images/editorial/how-does-the-amazon-ses-palisade-partnership-simplify-bulk-sender-compliance/how-does-the-amazon-ses-palisade-partnership-simplify-bulk-sender-compliance-responsibility-flow.webp "1200x906") *Source: Palisade.* This division matters because an SES configuration result is not a receiver decision, and a DMARC report does not prove future inbox placement. Strong authentication supports better deliverability, but mailbox providers retain their own filtering and delivery policies. ## When the answer changes The workflow changes according to the domain that appears in the visible From address and the evidence you have. If SES sends mail using `news.yourdomain.com` in the From address, validate the DKIM signing domain and the SPF-authenticated MAIL FROM domain against that exact visible domain. Amazon SES explains that a [custom MAIL FROM domain](https://aws.amazon.com/blogs/messaging-and-targeting/navigate-bulk-sender-requirements-with-amazon-ses/) is needed where SPF alignment is required. If DKIM aligns, an SPF alignment failure may not prevent a DMARC pass. It is still worth understanding because it can expose an unexpected sending path. Use this decision rule: - If you only have a domain name, inspect the published DMARC record and DNS authentication records. - If you have an SES identity status, confirm the identity and DKIM setup in SES, then send a real message through the production configuration. - If you have a delivered message, inspect its raw headers for authentication results from the receiving system. - If you have aggregate reports, review the sources, volume, and alignment outcomes before considering a stronger DMARC policy. > Do not move a production domain to a stricter DMARC policy solely because SES shows an identity as verified. Test mail sent through the actual application, configuration set, and visible From domain first. A [DMARC record check](/tools/dmarc) can inspect what DNS currently publishes. It cannot prove that SES is signing a message, that a particular application uses SES, or that a mailbox provider will accept future mail. ## Worked compliance evidence A useful evidence set ties the SES configuration to one real message and then to reporting data. The following is illustrative only. Do not copy domains or selectors from another account. Amazon SES generates the applicable DKIM values in the SES console or API for your verified identity. ```text Visible From: updates@yourdomain.com SES identity: yourdomain.com DKIM expectation: d=yourdomain.com Custom MAIL FROM expectation: bounce.yourdomain.com DMARC record location: _dmarc.yourdomain.com Message evidence to retain: Authentication-Results from a delivered test message ``` Check the four layers separately: - **DNS:** Query the authoritative DNS service and at least one public resolver for the SES-provided DKIM records, the custom MAIL FROM records where used, and `_dmarc.yourdomain.com`. - **Vendor:** Confirm that Amazon SES reports the sending identity and DKIM configuration as verified according to the [SES DKIM setup guidance](https://docs.aws.amazon.com/ses/latest/dg/send-email-authentication-dkim.html). - **Message:** Send a message from the real production path. Inspect the delivered message's `Authentication-Results` header. [RFC 8601 defines this header field](https://www.rfc-editor.org/rfc/rfc8601.html), but each receiver reports its own evaluation. - **DMARC:** Once aggregate reports accumulate, review the reported sources and outcomes. A report can show where to investigate, but it is not a replacement for the raw header from a business-critical message. This approach distinguishes a published record from a working sending path. It also avoids treating a passing result from one source as evidence for every application that uses the same visible From domain. ## What to do next with the evidence you have Start with the evidence closest to the problem. If DNS is missing or unexpected, compare it with the values generated for the verified SES identity before making a DNS change. If SES indicates that DKIM is not verified, use the current SES documentation to correct the identity configuration. If a real message has an unexpected `Authentication-Results` outcome, compare its visible From domain, DKIM `d=` domain, and SPF-authenticated domain with the intended SES setup. After you have DMARC aggregate reports, use them to inventory reported senders and find authentication or alignment failures that need follow-up. Palisade can analyze that report data, identify sending sources and issues, and propose a next policy step when the evidence indicates the domain may be ready. A human still reviews the evidence and applies any DNS or DMARC policy change. For ongoing review, Palisade's [email security score checker](/tools/email-security-score) provides another way to assess the domain's published email-security controls. For a broader implementation task, use the [vendor email-authentication guidance](/learning/esp-setup) alongside Amazon SES's documented setup path. ## Review the DMARC record behind your SES sending domain Check the visible From domain with Palisade's DMARC checker before comparing the published policy with SES configuration and delivered-message evidence. [Check the DMARC record](/tools/dmarc) A public DNS check does not prove that Amazon SES is signing production messages, identify every sender using the domain, monitor later changes, or predict a receiver's delivery decision. If DMARC reports show multiple SES configurations, applications, or domains that need ongoing review, [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=existing_content_migration&utm_content=how-does-the-amazon-ses-palisade-partnership-simplify-bulk-sender-compliance). Palisade can help prioritize report-based remediation, but it does not change your DMARC policy or guarantee inbox placement. ## Sources and further reading - [Amazon SES: Navigate bulk sender requirements with Amazon SES](https://aws.amazon.com/blogs/messaging-and-targeting/navigate-bulk-sender-requirements-with-amazon-ses/) - [Amazon SES Developer Guide: DKIM signing for Amazon SES](https://docs.aws.amazon.com/ses/latest/dg/send-email-authentication-dkim.html) - [RFC 8601: Authentication-Results header field](https://www.rfc-editor.org/rfc/rfc8601.html) - [Palisade DMARC checker](/tools/dmarc) ## Frequently asked questions ### Is Amazon SES integrated with Palisade? No. The public Amazon SES and Palisade materials supplied for this article do not establish a product integration, partnership, shared dashboard, or bundled service. They can be used in separate parts of one email-authentication workflow. ### Does Amazon SES DKIM verification prove DMARC passes? No. SES DKIM verification shows that the SES identity's DKIM setup is verified. DMARC also depends on the visible From domain and alignment in a real delivered message. ### Can SPF alignment matter when SES DKIM aligns? Yes. A DKIM-aligned pass can support DMARC even if SPF is not aligned. Reviewing the SPF path can still reveal an unexpected MAIL FROM configuration or sending source. ### Should I change DMARC to `p=reject` after SES verification? No. Verify DNS, SES status, and real message headers first. Then use aggregate-report evidence to identify legitimate senders and unresolved alignment issues before a human approves a policy change. ### Does a passing DMARC check guarantee inbox placement? No. A DMARC check can show the published record. Receiving providers make their own delivery decisions and may consider other signals beyond DMARC. --- # How to keep email authentication strong through multiple acquisitions Canonical: https://www.palisade.email/learning/how-dormakaba-keeps-email-security-strong-through-multiple-acquisitions > Email authentication stays strong through acquisitions when teams inventory domains and senders, assign ownership, validate mail, and phase DMARC. This is a general post-acquisition operating framework, not a substantiated Dormakaba case study. Keep email authentication strong by treating every acquired domain and sending service as an evidence-backed onboarding task: inventory it, assign an owner, validate SPF, DKIM, and DMARC on real mail, then move toward DMARC enforcement only after legitimate sources are known and aligned. ## Quick takeaways - An acquisition can introduce domains, mail platforms, and third-party senders that the central team does not yet control. - SPF evaluation has a limit of 10 DNS-triggering lookups, so inherited include chains need review before more services are added. - DKIM proves that a message carries a valid signature for the signing domain, but DMARC also requires alignment with the visible From domain. - A published DNS record does not prove that the production application is signing mail or using the intended return path. - DMARC aggregate reports help identify sources after mail begins flowing, but they do not replace delivered-message header checks. - Move to `quarantine` or `reject` only after the affected domain's legitimate mail paths have evidence of alignment. ## How post-acquisition email authentication works A newly acquired business can bring domains, subdomains, Microsoft 365 or Google Workspace tenants, transactional platforms, marketing services, support systems, and devices that send email. Each path can use different envelope domains, DKIM signing domains, and visible From domains. [SPF](https://www.rfc-editor.org/rfc/rfc7208.html) authorizes hosts through a DNS TXT record evaluated against the SMTP envelope sender or, when applicable, the HELO identity. SPF is not an unlimited list of services. RFC 7208 requires evaluators to stop after more than 10 terms that cause DNS lookups, producing a permanent error. [DKIM](https://www.rfc-editor.org/rfc/rfc6376.html) adds a cryptographic signature to a message. A receiver retrieves the public key from DNS using the selector and signing domain in the signature, then verifies the signed content. A valid DKIM signature can still be insufficient for DMARC if its `d=` domain does not align with the visible From domain. [DMARC](https://www.rfc-editor.org/rfc/rfc9989.html) evaluates SPF and DKIM results against that visible From domain. A message can pass DMARC when either SPF or DKIM passes with the required alignment. The domain's DMARC record also asks receivers to apply `none`, `quarantine`, or `reject` when DMARC fails. Receivers retain their own handling decisions. For broader context on spoofing controls and email threats, use Palisade's [email security learning hub](/learning). ## When the answer changes The workflow changes according to the evidence available for each acquired domain. - If the domain does not send mail, record that decision and protect it deliberately. Do not assume an unused-looking domain has no legacy application or forwarding path. - If a domain sends through one managed tenant, start with the tenant's current authentication evidence and the actual messages it produces. - If multiple providers send with the same visible From domain, each provider needs its own aligned SPF or DKIM path. Passing mail from one platform does not validate another. - If an acquired brand must remain separate, maintain a distinct domain inventory, business owner, technical owner, and change record. A shared parent company does not create DMARC alignment between unrelated domains. - If a domain has a DMARC policy of `none`, it is requesting monitoring treatment after failure, not proving that all legitimate mail is configured correctly. A usable decision rule is: do not strengthen a domain's DMARC policy until the domain owner can name every known production sender, the technical owner has checked its configuration, and a real delivered message from each important path shows an aligned SPF or DKIM pass. CISA's [DMARC implementation guidance](https://www.cisa.gov/sites/default/files/publications/cisa-dmarc.pdf) supports a staged approach: begin by gaining visibility, correct legitimate sources, then move toward stronger policy as the evidence supports it. ## A worked acquisition onboarding record Use one working record per domain, including subdomains that have their own visible From addresses. The following is illustrative only. Do not publish real selectors, provider targets, report addresses, or customer data in a shared tracker. ```text Domain: acquired-example.com Business owner: Acquired brand communications lead Technical owner: Central email security team Known sending paths: Workspace mail, billing platform, support platform SPF evidence: Public TXT lookup and evaluated lookup count DKIM evidence: Selector, signing domain, and delivered-message verification DMARC evidence: Published policy, aggregate-report destination, alignment results Message evidence: Redacted Authentication-Results header for each path Policy decision: Keep p=none until every important path is aligned Rollback record: Previous DNS value and approved change owner ``` This record separates configuration from proof. For example, an SPF record can look correct in DNS while a billing provider uses an envelope sender that the record does not cover. Likewise, a provider console can report DKIM configured while a delivered message has no valid signature. ![Workflow for onboarding an acquired domain: inventory senders, assign owners, validate DNS and real messages, review DMARC reports, and phase enforcement](/images/editorial/how-dormakaba-keeps-email-security-strong-through-multiple-acquisitions/how-dormakaba-keeps-email-security-strong-through-multiple-acquisitions-ma-workflow.webp "1200x980") *Source: Palisade.* ## Practical next steps for acquired domains Start with the evidence that is easiest to obtain, then move toward production evidence. ### 1. Build the domain and sender inventory List every acquired root domain, active sending subdomain, and visible From domain. For each, record the business purpose, known sending applications, DNS zone owner, and an accountable owner who can approve mail-flow changes. Include dormant domains and regional brands. The aim is not to change every domain immediately. It is to make unknown sending paths visible before policy changes affect them. ### 2. Inspect the public DNS records Check the exact domain that appears in the message's visible From field. Review the DMARC record at `_dmarc.yourdomain.com`, the SPF TXT record for the envelope-sending domain, and DKIM selector records supplied by the sending provider. Use the [DMARC checker](/tools/dmarc) and [DNS lookup tool](/tools/dns-lookup) to inspect public records before comparing them with the intended policy. A public lookup cannot prove the production sending path, continuous state, a receiver's private decision, or future placement. > Do not replace a crowded SPF record with a guessed include chain. A syntax-valid record can still remove authorization for a live sender and interrupt mail. ### 3. Validate real delivered messages Send a controlled message through every important production path. Retain redacted headers and inspect the receiver's `Authentication-Results` field. RFC 8601 defines this field as a receiver's authentication assessment, so record which receiver supplied it and the exact message path it observed. Confirm four layers independently: - DNS: query authoritative DNS and at least one public resolver after a change. - Vendor: confirm the provider's current authentication or domain-verification status. - Message: inspect a delivered message from the exact production path. - DMARC: review aggregate-report data after sufficient mail has accumulated. A green status in a provider interface is useful evidence, but it does not replace the message and DMARC layers. ### 4. Phase enforcement by domain Keep a domain at `p=none` while unresolved sources remain. Once legitimate senders are identified and aligned, establish a documented change, a rollback value, and an observation period before moving to `quarantine` or `reject`. RFC 9989 defines the DMARC policy values, while the receiving system determines final treatment. Stronger policy requests help control spoofed use of the domain, but they do not guarantee inbox placement for legitimate mail. ## Continue the acquisition inventory with Palisade After you have checked the public record, the remaining problem is knowing which production sources across acquired domains still fail alignment as mail changes over time. Palisade is DMARC software that analyzes DMARC aggregate-report data, identifies sending sources and authentication or alignment issues, and creates prioritized remediation tickets for human review. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=email_authentication&utm_content=how-dormakaba-keeps-email-security-strong-through-multiple-acquisitions) Palisade does not autonomously change a DMARC policy, prove every future message will authenticate, or control a receiver's delivery decision. A human reviews the evidence and applies any DNS or policy change. ## Sources and further reading - [RFC 7208: Sender Policy Framework](https://www.rfc-editor.org/rfc/rfc7208.html) - [RFC 6376: DomainKeys Identified Mail](https://www.rfc-editor.org/rfc/rfc6376.html) - [RFC 9989: Domain-based Message Authentication, Reporting, and Conformance](https://www.rfc-editor.org/rfc/rfc9989.html) - [CISA: DMARC implementation guidance](https://www.cisa.gov/sites/default/files/publications/cisa-dmarc.pdf) - [Palisade DMARC checker](/tools/dmarc) ## Frequently asked questions ### Should an acquired domain receive `p=reject` immediately? No. First identify legitimate sending paths and validate aligned SPF or DKIM on real delivered messages. A premature rejection policy can disrupt legitimate mail that has not yet been inventoried or configured. ### Does a valid SPF record prove all acquired applications are authorized? No. SPF is evaluated for the envelope sender or HELO identity used by a particular message. A DNS record can be valid while an application sends with an unexpected identity or exceeds SPF's DNS lookup limit. ### Can DKIM alone protect every acquired brand domain? Only when the valid DKIM signing domain aligns with the message's visible From domain for DMARC. DKIM can verify a signature, but DMARC evaluates both authentication and identifier alignment. ### Are DMARC aggregate reports enough to validate a migration? No. Aggregate reports identify reported authentication activity over time, but they do not replace a real delivered-message check from each important production path. Use both forms of evidence. ### Can a public DMARC lookup show why a receiver placed mail in spam? No. A public lookup shows the published DNS record. It cannot reveal a receiver's private reputation assessment, message content analysis, or final placement decision. --- # How secure is your email communication today? Canonical: https://www.palisade.email/learning/how-secure-is-your-email-communication-today > How secure is your email communication today? Check account access, message protection, authentication, real delivery evidence, and DMARC reports. Your email communication is secure only to the extent that the account, message, transport, and domain-authentication controls match the risk and work on the real sending path. A strong password or a published DMARC record answers only part of the question. Check provider account evidence, the protection appropriate for sensitive content, authentication results from a delivered message, and DMARC reporting over time. ## Quick takeaways - Account security controls who can enter a mailbox or its administration console. - Transport encryption protects a connection between mail systems, not necessarily every stored copy or recipient workflow. - SPF, DKIM, and DMARC help receivers assess whether a visible From domain is authorized. - A public DNS lookup does not prove how a particular delivered message authenticated. - A provider status indicator does not replace inspecting headers from the production sending path. - DMARC aggregate reports help identify sending sources and authentication or alignment issues after reports accumulate. ## How email communication security works Email security has separate layers, each with a different job. Account security concerns access to mailboxes and administrative settings. Review the sign-in methods, active sessions, recovery methods, privileged accounts, and alerts available in the provider that hosts your email. [Google Workspace security guidance](https://support.google.com/a/answer/7587183) recommends stronger account protections such as 2-Step Verification for administrator accounts. Those controls reduce the risk of unauthorized mailbox access, but they do not establish that a message received by a user is legitimate. Message protection concerns the information in the message and attachments. Before sending confidential material, use the protected-sharing process approved by both your organization and the recipient. Domain authentication does not encrypt message contents or decide whether ordinary email is suitable for the data. Transport security concerns the connection between mail systems. For example, [Google Workspace TLS guidance](https://support.google.com/a/answer/2520500) explains how TLS protects mail in transit when the sending and receiving systems support the connection. TLS for one delivery path does not prove end-to-end content protection, recipient access controls, or the treatment of copies after delivery. Domain authentication concerns mail using your domain in the visible From address. [RFC 9989 defines DMARC](https://www.rfc-editor.org/rfc/rfc9989.html) as a policy and reporting framework built on SPF and DKIM authentication with identifier alignment. DMARC can help a receiver assess unauthorized use of the From domain. It does not stop lookalike domains, compromised mailboxes, or every social-engineering attempt. For protocol-specific guidance, use the [email authentication learning hub](/learning). ## When the answer changes The best next check depends on the evidence and the risk. - If the concern is an unexpected sign-in or mailbox-rule change, begin in the email provider's sign-in and administrative audit views. Preserve the time, account, and activity details needed for your incident process. - If the concern is confidential content, begin with the approved sharing method and the recipient's workflow. Do not treat a DMARC pass as protection for the content itself. - If the concern is a suspicious message that appears to use your organization’s domain, preserve its raw headers. [RFC 8601 defines the Authentication-Results header field](https://www.rfc-editor.org/rfc/rfc8601.html), which records authentication assessments made by a receiving system. - If the concern is your domain's exposure to spoofing, inspect the published DNS records, then review DMARC aggregate-report data once it has accumulated. The sending application also changes the practical work. The provider-specific choices for [sending secure email using Outlook](/learning/how-can-i-send-secure-email-using-outlook) differ from [sending secure email in Gmail](/learning/how-do-i-send-a-secure-email-in-gmail). Follow the workflow for the service that sends the production message. > Do not change SPF, DKIM, or DMARC records solely because a checker reports a missing or weak result. Identify every legitimate sending path that uses the domain first. An incorrect DNS change can interrupt legitimate mail. ## A worked email-security review Use a recent non-sensitive test message sent through the same application, domain, and gateway used in production. Do not share private keys, tokens, recipient addresses, or unredacted headers in troubleshooting tickets. ```text Email communication review Account: - Confirm expected mailbox and administrator access methods. - Review recent sign-ins, active sessions, and access changes. Message: - Decide whether the content needs an approved protected-sharing workflow. - Confirm the intended sender, recipient, and sending application. Delivered message: - Obtain raw headers from the message delivered through the production path. - Record the visible From domain and Authentication-Results values. DNS: - Look up the SPF, DKIM, and DMARC records for the sending domain. - Compare them with the approved DNS configuration. DMARC: - Review aggregate-report data after reports arrive. - Identify legitimate sources and authentication or alignment failures before changing policy. ``` ![Decision flow for reviewing account access, sensitive content, message headers, DNS records, and DMARC reports](/images/editorial/how-secure-is-your-email-communication-today/how-secure-is-your-email-communication-today-security-review.webp "1200x829") *Source: Palisade.* Use four independent validation layers: - DNS: query authoritative DNS and at least one public resolver to establish what is published. - Vendor: inspect the current authentication or verification status in the service that sends the mail. - Message: inspect a real delivered message from the exact production path. - DMARC: review aggregate reports or monitoring after data accumulates. A green vendor indicator does not prove that the delivered message used the expected DKIM signature or SPF return path. A public DNS result does not prove a receiver's private filtering decision or future inbox placement. ## What to check next If you only have a domain name, use Palisade's [Email Security Score tool](/tools/email-security-score) to inspect public DNS signals. Compare the result with the DNS configuration your team intended to publish, then investigate differences through the responsible sender or DNS owner. If you have a suspicious delivered message, preserve its raw headers and compare the visible From domain with the `Authentication-Results` values. A domain lookup cannot explain that individual message by itself. If you administer several domains or several sending services, document each sending source, its owner, and the domain it uses. Then use aggregate reports to confirm whether those sources authenticate and align before proposing a DMARC policy change. ## Inspect the public authentication posture A public domain check is a useful starting point when the evidence you have is a domain name. It can reveal SPF, DKIM, and DMARC records that need review. It cannot show which production sources still fail alignment, whether a recipient accepted a specific message, or whether a later DNS change introduced a new sender. [Check the email security score](/tools/email-security-score) For ongoing DMARC work across domains or sending sources, Palisade is agentic DMARC software that analyzes DMARC aggregate-report data, identifies sending sources and authentication or alignment issues, and creates prioritized remediation tickets. It can propose the next policy step when the evidence supports it. A human reviews the evidence and applies any DNS or policy change. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=email&utm_content=how-secure-is-your-email-communication-today) Palisade does not prove every future message will authenticate, change the DMARC policy without human review, or guarantee delivery or inbox placement. ## Sources and further reading - [RFC 9989: Domain-based Message Authentication, Reporting, and Conformance](https://www.rfc-editor.org/rfc/rfc9989.html) - [RFC 8601: Message Header Field for Indicating Message Authentication Status](https://www.rfc-editor.org/rfc/rfc8601.html) - [Google Workspace security guidance](https://support.google.com/a/answer/7587183) - [Google Workspace TLS guidance](https://support.google.com/a/answer/2520500) - [Palisade Email Security Score tool](/tools/email-security-score) ## Frequently asked questions ### Is email secure enough for confidential information? Only when the sender and recipient use protections appropriate for the information and follow an approved sharing workflow. SPF, DKIM, and DMARC authenticate domain use. They do not encrypt message content or control access after delivery. ### Does a DMARC record make every email from a domain secure? No. DMARC helps receivers assess whether mail aligns with an authorized SPF or DKIM identity. It does not prevent mailbox compromise, protect message content, or guarantee that every receiver will deliver the message. ### Can a DNS checker prove that an email passed DMARC? No. A DNS checker can show the public record that a domain publishes. A delivered message's raw headers and `Authentication-Results` fields provide evidence about that message's authentication assessment. ### Does TLS mean that email is end-to-end encrypted? No. TLS can protect a connection between participating mail systems. It does not by itself establish end-to-end encryption, secure every stored copy, or determine the recipient's access controls. ### Should I move to `p=reject` as soon as I publish DMARC? No. First identify legitimate sending sources and validate that important production paths have aligned SPF or DKIM authentication. Review aggregate reports and keep a rollback plan before requesting stronger handling for DMARC failures. --- # How to get a DKIM record Canonical: https://www.palisade.email/learning/how-to-get-dkim-record > How to get a DKIM record: generate the selector and key with your sender, publish its exact DNS value, then verify a delivered message passes. To get a DKIM record, obtain the selector and DNS value from the email service that sends your mail, then publish that exact value at the selector's `_domainkey` hostname. The record is usually a TXT record containing a public key, but some services provide a CNAME instead. Publishing DNS alone does not prove the sender is signing mail. Send a fresh message through the production path and inspect its DKIM result. ## Quick takeaways - Your email sender generates the DKIM private key and tells you what public DNS record to publish. - A DKIM lookup needs both a selector and a signing domain, not only the visible From domain. - DKIM public keys are normally published at `<selector>._domainkey.<signing-domain>`. - Some providers use a CNAME record that points to provider-managed DKIM data instead of a TXT public key. - A public DNS result confirms publication, but a delivered message confirms whether the sender used the matching private key. - DKIM works with DMARC when the DKIM signing domain aligns with the visible From domain. ## How a DKIM record works [DKIM](https://www.rfc-editor.org/rfc/rfc6376.html) lets a sending system sign parts of an email with a private key. The receiving system reads the signature's `d=` signing domain and `s=` selector, then retrieves the matching public key through DNS. The selector scopes the lookup. For a message signed with `d=yourdomain.com` and `s=selector1`, the receiver looks for: ```text selector1._domainkey.yourdomain.com ``` The sender chooses or generates the selector through its account or configuration. There is no universal DKIM record that can be retrieved from a bare domain without knowing which selector the sender used. A traditional DKIM key record is a DNS TXT record with DKIM tags. [RFC 6376 section 3.6](https://www.rfc-editor.org/rfc/rfc6376.html#section-3.6) defines the key-record format and the selector-based lookup. Current DKIM guidance in [RFC 8301](https://www.rfc-editor.org/rfc/rfc8301.html) recommends RSA keys of at least 1024 bits and says verifiers must be able to support RSA keys from 1024 through 2048 bits. For the protocol context, see [what DKIM is](/learning/what-is-dkim). If you need to review the published value rather than create one, use the separate guide on [how to check a DKIM record](/tools/dkim). ## When the answer changes The way you get the record depends on who controls the sending service and DNS. - If your email provider generates DKIM keys, use its account-generated selector and record value. Do not copy a DKIM public key from another domain, tenant, or provider. - If the provider instructs you to create a TXT record, publish the full public-key value exactly as provided. - If the provider instructs you to create a CNAME record, publish the CNAME target exactly as provided. The provider may host or rotate the underlying key. - If you manage a mail server directly, your mail-signing software generates the key pair and selector. Publish only the public-key data in DNS. Keep the private key private. - If you have a delivered message, use its `s=` and `d=` values to identify the exact public record the receiver attempted to use. Google Workspace documents this same sequence: generate a DKIM record in the Admin console, add the generated TXT record at the domain host, turn on DKIM signing, then send a message and check that it passes. See [Google Workspace's DKIM setup instructions](https://knowledge.workspace.google.com/admin/security/set-up-dkim?rd=1&visit_id=639203581456186434-1681212591). > Do not replace an existing DKIM record until you know which sending systems use it. Removing a selector that an active sender still signs with can cause its DKIM validation to fail. ## Worked DKIM record example This is an illustrative TXT-record shape only. Your sender generates the actual selector and public-key value. Do not publish this example. ```text Host: selector1._domainkey.yourdomain.com Type: TXT Value: v=DKIM1; k=rsa; p=BASE64_PUBLIC_KEY_FROM_YOUR_SENDER ``` In this example: - `selector1` is the selector named by the sender's DKIM signature. - `_domainkey` is the DKIM DNS namespace. - `yourdomain.com` is the `d=` signing domain. - `v=DKIM1` identifies the record as a DKIM key record. - `k=rsa` identifies the key type. - `p=` contains the public key. The private key remains with the sending system. ![Flow showing a sender generating DKIM instructions, DNS publishing the selector record, and a delivered message verifying the signature](/images/editorial/how-to-get-dkim-record/how-to-get-dkim-record-dkim-flow.webp "1200x676") *Source: Palisade.* A CNAME-based setup has a different DNS shape: ```text Host: selector1._domainkey.yourdomain.com Type: CNAME Value: selector1.provider-example.net ``` Use only the hostname and record type supplied by your provider. A CNAME is not interchangeable with a TXT public-key record. Follow the sender's instructions for that selector. For more detail on the fields inside a TXT key record, see [DKIM DNS record examples](/learning/what-does-a-dkim-record-look-like). ## Get and validate the right DKIM record Start with the evidence you have. - If you are setting up a sender, open that sender's DKIM or domain-authentication settings and generate or retrieve its DNS instructions. Record the selector, signing domain, DNS record type, and exact value. - If you administer DNS, publish the supplied record at the full hostname. Query the authoritative DNS server and at least one public resolver after the change propagates. - If you have a delivered message, inspect its `DKIM-Signature` header for `d=` and `s=`. Then inspect the receiver's `Authentication-Results` header. [RFC 8601](https://www.rfc-editor.org/rfc/rfc8601.html) defines this header field for reporting authentication results. - If the message fails DKIM, compare the selector and signing domain in the message with the DNS record that is publicly available. A failure can involve DNS publication, the sender's signing configuration, or a mismatch between the key used to sign and the public key retrieved by the receiver. A green sender dashboard status is useful vendor evidence, but it is not the same as a fresh delivered-message check. Validate the exact production path, including any application, relay, or gateway that sends mail for the domain. After mail flows and reports accumulate, DMARC aggregate reports can show whether sources are authenticating and aligning at scale. For a broader operating model across SPF, DKIM, and DMARC, visit the [email authentication learning hub](/learning/dmarc). ## Check the published DKIM record Once you have the selector and signing domain, inspect the public record before troubleshooting signing or delivery. [Check the published DKIM record](/tools/dkim) A public DNS check cannot reveal the private key, enable signing in the sender, prove an unseen message passed DKIM, or guarantee delivery. ## Sources and further reading - [RFC 6376: DomainKeys Identified Mail Signatures](https://www.rfc-editor.org/rfc/rfc6376.html) - [RFC 8301: Cryptographic algorithm and key size update for DKIM](https://www.rfc-editor.org/rfc/rfc8301.html) - [RFC 8601: Authentication-Results header field](https://www.rfc-editor.org/rfc/rfc8601.html) - [Google Workspace: Set up DKIM](https://knowledge.workspace.google.com/admin/security/set-up-dkim?rd=1&visit_id=639203581456186434-1681212591) - [Palisade DKIM checker](/tools/dkim) ## Frequently asked questions ### Can I get a DKIM record from my domain registrar? Only if the registrar also operates the email sender or exposes the sender's DKIM setup. A DNS provider can publish the record, but the email service that signs messages supplies the selector and the public-key or CNAME value. ### Is a DKIM record always a TXT record? No. A traditional DKIM key record is a TXT record containing the public key, but some email providers instruct customers to publish CNAME records that point to provider-managed DKIM data. ### Can one domain have multiple DKIM records? Yes. A domain can publish multiple selectors, often because different email services sign mail for the same domain or because a sender is rotating keys. Each active sender must use its matching selector and public key. ### Does a published DKIM record mean DKIM is working? No. It proves only that a public DNS record is available at the name checked. A newly delivered message with a DKIM pass result is needed to show that the sender used a corresponding private key for that message. ### Can I copy a DKIM key from another domain? No. The public record must correspond to the private key used by your sender for your signing domain and selector. Obtain the values from the specific sender account or mail-signing system that will send your mail. --- # How do I set up DMARC, SPF, and DKIM on DreamHost? Canonical: https://www.palisade.email/learning/how-to-set-up-dmarc-spf-dkim-on-dreamhost > How to set up DMARC, SPF, and DKIM on DreamHost: add the required DNS records, validate the live sending path, and review DMARC reports safely. Set up DMARC, SPF, and DKIM on DreamHost by opening the domain's DNS settings, publishing the DMARC policy at `_dmarc.yourdomain.com`, and confirming the SPF and DKIM records used by each real sending service. DNS publication is only the first check. Confirm DreamHost's status where available, inspect a delivered production message, then review DMARC aggregate reports before requesting stricter DMARC handling. ## Quick takeaways - DMARC evaluates whether SPF or DKIM passes with alignment to the visible From domain. - A DMARC policy belongs at `_dmarc.yourdomain.com`, not at the root hostname. - Publish one SPF TXT record for a domain's authorized sending services. - Use the actual DKIM selector and key values generated by the sending service. - A DNS lookup confirms a public record, but it does not prove a production application is using it. - Validate DNS, the vendor's status, delivered-message headers, and DMARC reports separately. ## How DreamHost DNS fits into DMARC, SPF, and DKIM DreamHost provides a DNS Settings entry for domain management in its website-management interface. Its [instructions for adding custom DNS records](https://help.dreamhost.com/hc/en-us/articles/360035516812-Adding-custom-DNS-records) are the current provider reference for opening that area and adding a record. DMARC, SPF, and DKIM each use DNS, but they answer different questions: - SPF publishes which sending infrastructure is authorized to use the envelope sender domain. - DKIM publishes a public key for a selector so receiving systems can verify a message signature. - DMARC checks whether SPF or DKIM passes with the visible From domain aligned, then applies the domain owner's published handling request when DMARC fails. The record values must match your actual sending paths. DreamHost mailbox mail, website forms, transactional providers, and marketing platforms can use separate authentication settings. Do not copy a record from another account or domain. Obtain the provider-generated hostname and value from the service that sends the mail. ![DreamHost interface menu showing the DNS Settings entry used to manage a domain's DNS records](/images/editorial/how-to-set-up-dmarc-spf-dkim-on-dreamhost/dreamhost-dns-settings-entry.png "322x305") *Source: [Adding custom DNS records](https://help.dreamhost.com/hc/en-us/articles/360035516812-Adding-custom-DNS-records), checked 2026-08-11.* For broader protocol context, the [email authentication learning hub](/learning) collects related guidance. If Amazon SES, Brevo, or Customer.io sends any mail for the domain, use that provider's own setup values rather than treating DreamHost DNS as the source of the sending configuration. Palisade also has provider-specific guidance for [Amazon SES](/learning/how-do-i-set-up-spf-and-dkim-for-amazon-ses), [Brevo](/learning/how-do-i-set-up-spf-and-dkim-for-brevo), and [Customer.io](/learning/how-do-i-set-up-spf-and-dkim-for-customer-io). ## When the setup changes The DNS location is consistent, but the required values change with the mail path. Use this decision rule: - If DreamHost hosts DNS for the domain, publish the values generated by each sender in DreamHost DNS Settings. - If another provider is authoritative for DNS, publish the same provider-generated values at that authoritative DNS provider instead. - If more than one service sends with the domain, consolidate their SPF authorization into one SPF record and publish each service's separate DKIM records. - If a service sends with a different visible From domain or a different envelope sender domain, validate the exact production message. A record at the root domain does not prove alignment for every subdomain or return path. - If you do not know which service sent a message, inspect its raw headers before editing DNS. > Do not replace an existing SPF value with a single new provider include unless you have confirmed every authorized sender that must remain in the record. Removing an existing authorization can cause legitimate mail to fail SPF. DreamHost's [DMARC policy documentation](https://help.dreamhost.com/hc/en-us/articles/360022808632-Creating-a-DMARC-policy) shows the provider's DNS record editor for a DMARC TXT entry. Follow the current provider documentation for the form fields and save process, then compare the published result with the record your team approved. ![DreamHost TXT record editor showing the host and value fields for a DMARC policy record](/images/editorial/how-to-set-up-dmarc-spf-dkim-on-dreamhost/dreamhost-add-dmarc-record.png "1590x680") *Source: [Creating a DMARC policy](https://help.dreamhost.com/hc/en-us/articles/360022808632-Creating-a-DMARC-policy), checked 2026-08-11.* ## Worked DNS record example Use the following as a structural example only. Do not publish these values as-is. Replace the SPF mechanisms and DKIM selector value with those generated for your own sending services, and use a reporting address your organization controls. ```text DMARC host: _dmarc.yourdomain.com DMARC value: v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com SPF host: yourdomain.com SPF value: v=spf1 include:mail.example-sender.com -all DKIM host: selector1._domainkey.yourdomain.com DKIM value: v=DKIM1; k=rsa; p=provider-generated-public-key ``` The DMARC example begins with `p=none`, which requests monitoring rather than stronger handling for DMARC failures. That is appropriate only while the domain owner is collecting evidence about legitimate senders. The record does not make mail pass DMARC by itself. The SPF example is deliberately incomplete. It has one example sender because each domain needs its own reviewed set of authorizations. DKIM is also provider-specific: the selector and public key come from the service that signs the message. Never paste a public key, CNAME target, or verification token copied from another tenant. ![Record card showing illustrative DMARC, SPF, and DKIM DNS record shapes for yourdomain.com](/images/editorial/how-to-set-up-dmarc-spf-dkim-on-dreamhost/how-to-set-up-dmarc-spf-dkim-on-dreamhost-records.webp "1200x533") *Source: Palisade.* ## Validate the published configuration Start with the evidence you have. If you have only a domain name, use the [DMARC checker](/tools/dmarc) to inspect the publicly visible DMARC record. Confirm the hostname, policy tags, and reporting destination against the approved record. A public DNS check does not prove that a website, mailbox, or marketing platform is sending with the configuration. If you can access DreamHost or another sender's account, check that service's current domain-authentication status after DNS has updated. A green provider status is useful, but it still does not prove a message delivered through the exact production path. If you have a delivered test message, inspect its raw headers. Look for the receiver's `Authentication-Results` field and confirm whether SPF and DKIM passed, then compare the authenticated domains with the visible From domain. Test each important path separately, including mailbox mail, contact forms, transactional mail, and campaign mail. Finally, wait for DMARC aggregate reports to accumulate and review which sources are using the domain and which paths still fail alignment. This is the evidence needed before considering a move from `p=none` to a stricter DMARC policy. ## Check the DreamHost domain's published DMARC record After saving the DreamHost DNS entry, inspect the domain's public DMARC record and compare it with the value you intended to publish. [Check the published DMARC record](/tools/dmarc) A public record check cannot repair DNS, confirm a sender is signing messages, show every production sending source, or guarantee how a receiver will place future mail. Palisade is agentic DMARC software that analyzes DMARC aggregate-report data, identifies authentication and alignment issues, and proposes the next policy step for human review. It does not autonomously change your DMARC policy or guarantee delivery. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=existing_content_migration&utm_content=how-to-set-up-dmarc-spf-dkim-on-dreamhost) ## Sources and further reading - [DreamHost: Adding custom DNS records](https://help.dreamhost.com/hc/en-us/articles/360035516812-Adding-custom-DNS-records) - [DreamHost: Creating a DMARC policy](https://help.dreamhost.com/hc/en-us/articles/360022808632-Creating-a-DMARC-policy) - [Palisade DMARC checker](/tools/dmarc) - [RFC 9989: Domain-based Message Authentication, Reporting, and Conformance](https://www.rfc-editor.org/rfc/rfc9989.html) ## Frequently asked questions ### Do I add DMARC, SPF, and DKIM in the same DreamHost screen? Yes. When DreamHost is authoritative for the domain's DNS, the DNS Settings area is where you publish the required record types. The exact hostnames and values differ by protocol and by the service that sends the message. ### Can I use more than one SPF record? No. Publish one SPF record for the domain, then incorporate the authorized mechanisms required by the sending services you have verified. Review the complete value before replacing an existing SPF record. ### Does a DMARC record make DreamHost mail authenticate? No. A DMARC record publishes a policy and reporting request. It does not configure a mail application to use an authorized envelope sender or add a DKIM signature to outgoing mail. ### Should I set `p=reject` when I first publish DMARC? No. First identify legitimate sending sources and validate SPF or DKIM alignment on their real delivered messages. Review DMARC aggregate reports before requesting stronger handling for mail that fails DMARC. ### How do I confirm DKIM is working? Only a delivered message from the exact sending path can confirm that path is signing and that a receiver evaluated the signature. Check the raw message headers, then compare the DKIM selector and domain with the DNS record published for that sender. ### Does a DMARC checker prove inbox placement? No. A DMARC checker can inspect the public policy record. It cannot prove a receiver's private filtering decision, the state of every sender, or future inbox placement. --- # How does Palisade DMARC monitoring protect email deliverability? Canonical: https://www.palisade.email/learning/howcanpalisadedmarcmonitoringprotectemaildeliverability > Palisade DMARC monitoring helps protect email deliverability by finding unauthenticated sending sources before a stricter DMARC policy is requested. Palisade DMARC monitoring can protect email deliverability by turning DMARC aggregate-report data into an inventory of sending sources, authentication results, and alignment issues. That lets an IT team investigate legitimate mail that would fail DMARC before requesting a stricter policy. It supports safer enforcement, but it does not guarantee inbox placement or make a receiver accept a message. ## Quick takeaways - DMARC monitoring uses aggregate reports to show how mail using a domain is authenticating at participating receivers. - A DMARC pass requires an aligned SPF or DKIM pass for the visible From domain. - A public DMARC record check shows what DNS publishes now, not whether every production message passes. - Legitimate sources that fail alignment need investigation before a stronger DMARC policy can be safely requested. - Palisade analyzes aggregate-report data and creates prioritized remediation tickets, while a human reviews evidence and applies changes. - DMARC strengthens domain authentication, but mailbox providers still make their own delivery and placement decisions. ## How DMARC monitoring protects deliverability DMARC connects the visible From domain to SPF or DKIM authentication through identifier alignment. The current DMARC specification, [RFC 9989](https://datatracker.ietf.org/doc/html/rfc9989), defines the protocol's policy and discovery behavior, while [RFC 9990](https://www.rfc-editor.org/rfc/rfc9990.html) defines the aggregate reporting this article relies on. A monitoring policy commonly uses `p=none`. That policy does not request quarantine or rejection for a DMARC failure. It can still request aggregate reports through the `rua` tag. Those reports give the domain owner evidence about authentication outcomes and the sources observed sending mail that uses the domain. That evidence matters before a domain owner asks receivers to apply stronger handling to DMARC failures. If a business application sends mail with an unaligned SPF identity and no aligned DKIM signature, it may work while the domain is monitoring. The same path can become a delivery problem once the published policy asks receivers to quarantine or reject failures. Palisade is DMARC software that autonomously analyzes DMARC aggregate-report data, identifies sending sources and authentication or alignment issues, and creates prioritized remediation tickets. It can also detect when a domain appears ready for the next policy stage and propose a next policy step. The human team reviews the evidence and applies the DNS change. ![Flow showing DMARC aggregate reports identifying sources, revealing alignment failures, guiding remediation, and supporting a reviewed policy change](/images/editorial/howcanpalisadedmarcmonitoringprotectemaildeliverability/howcanpalisadedmarcmonitoringprotectemaildeliverability-monitoring-flow.webp "1200x676") *Source: Palisade.* A DMARC report does not contain the full message body. It is aggregate feedback. To validate a specific production message, inspect its delivered headers. [RFC 8601 defines the Authentication-Results header field](https://www.rfc-editor.org/rfc/rfc8601.html), which can show an evaluator's SPF, DKIM, and DMARC results for that message. For broader context on protocol behavior, see [how a DMARC record protects a domain and supports email delivery](/learning/how-does-a-dmarc-record-protect-my-domain-and-improve-email-delivery). ## When monitoring changes the next action Monitoring is most useful when the team has evidence of more than one sender, a planned policy increase, or an authentication failure that has not been tied to a specific source. Use this decision rule: - If DNS has no usable DMARC record, publish and validate a monitoring record before making an enforcement decision. - If aggregate reports show a legitimate source failing DMARC, identify the sender's SPF and DKIM configuration before changing policy. - If a source passes SPF or DKIM but fails alignment, compare the authenticated domain with the visible From domain. - If an unfamiliar source fails both SPF and DKIM, do not assume it is legitimate. Record the evidence and investigate the business owner, service, and sending path. - If known, important sources show aligned authentication over an appropriate observation period, review whether a stronger policy is suitable. A domain can publish `p=none` and still have delivery problems caused by reputation, content, recipient policy, or an application-specific sending configuration. Conversely, a passing DMARC result does not prove future mail will pass after a sender changes its return path, signing domain, or infrastructure. Do not treat a vendor status indicator as complete validation. A working result needs evidence at four layers: - DNS: query the authoritative DNS service and at least one public resolver. - Vendor: confirm the sender's current authentication status in its own interface. - Message: send a real message through the exact production path and inspect its headers. - DMARC: review aggregate reports after data has accumulated. ## A worked monitoring record and evidence check This illustrative record requests aggregate reports while publishing a monitoring policy: ```text v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com ``` Do not copy the reporting address without confirming that your reporting destination is authorized and able to receive the reports. The actual record must use your domain and your approved reporting workflow. The evidence sequence for `yourdomain.com` is: - Query `_dmarc.yourdomain.com` and confirm the published TXT value. - Send an email from each important production service using `@yourdomain.com` in the visible From address. - Inspect the delivered message's `Authentication-Results` header for `spf=`, `dkim=`, and `dmarc=`. - Compare the header result with the source's aggregate-report result once reports arrive. - Investigate any source that fails DMARC or authenticates with a domain that does not align with the visible From domain. An illustrative header result might look like this: ```text Authentication-Results: mx.example.net; dkim=pass header.d=yourdomain.com; spf=pass smtp.mailfrom=mail.yourdomain.com; dmarc=pass header.from=yourdomain.com ``` The exact syntax and properties are defined by [RFC 8601](https://www.rfc-editor.org/rfc/rfc8601.html). This example is evidence about one evaluated message. It does not establish the status of every mail stream or every receiver. ## What to do with the evidence you have If you only have a domain name, start with [Palisade's DMARC checker](/tools/dmarc) to inspect the public record. Compare the result with the DNS record your team intended to publish. If you have a delivered message, inspect its raw headers before changing DNS. The header can show whether the relevant receiver recorded a DMARC pass or failure for that one message. If you have aggregate reports, group the results by source and sending service. Confirm ownership for known sources, then prioritize paths that fail SPF or DKIM alignment. For the wider operating context, the [Palisade learning center](/learning) includes related email-authentication guidance, and the [email deliverability section](/email-deliverability) covers factors that sit outside DMARC. > Do not raise a DMARC policy based only on a public DNS lookup. A correct record in DNS does not prove that business-critical mail is using the intended SPF or DKIM identity. ## Continue from report evidence to a reviewed policy decision When reports show a recurring sender or alignment problem, Palisade can analyze the aggregate-report data, identify the affected source, and create a prioritized remediation ticket. After the evidence supports the next stage, it can propose a policy step for human review. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=existing_content_migration&utm_content=howcanpalisadedmarcmonitoringprotectemaildeliverability) Palisade does not automatically change the DMARC policy, repair every sender, guarantee inbox placement, or prove that future messages will authenticate. ## Sources and further reading - [RFC 9989: Domain-based Message Authentication, Reporting, and Conformance](https://datatracker.ietf.org/doc/html/rfc9989) - [RFC 8601: Message Header Field for Indicating Message Authentication Status](https://www.rfc-editor.org/rfc/rfc8601.html) - [Palisade documentation](https://docs.palisade.email/) - [Palisade DMARC checker](/tools/dmarc) ## Frequently asked questions ### Does DMARC monitoring improve inbox placement by itself? No. DMARC monitoring supplies evidence about sources and authentication outcomes. It can help a team prevent authentication failures from reaching a stricter policy stage, but it does not control a receiver's reputation, content assessment, or inbox-placement decision. ### Does `p=none` block failing email? No. A `p=none` policy does not request quarantine or rejection for DMARC failures. It can request aggregate reports that help the domain owner investigate those failures. ### Can a DMARC checker show whether an email passed? No. A public DMARC checker can inspect the domain's published DNS record. To validate an individual message, inspect the delivered message headers. To assess recurring traffic, use aggregate-report data. ### Does a DKIM pass always produce a DMARC pass? No. DKIM must pass with a domain aligned to the visible From domain for DKIM to satisfy DMARC. A valid signature using an unrelated domain may still leave the message without an aligned authentication pass. ### Should a domain move to `p=reject` after finding one passing sender? No. A domain owner should confirm its important legitimate sending paths before requesting stronger handling for failures. A single passing message does not prove that every application, regional sender, or transactional path is aligned. --- # Is DMARC the email security game-changer organizations need? Canonical: https://www.palisade.email/learning/is-dmarc-the-email-game-changer > DMARC is a major email security control for domain spoofing, but it needs aligned SPF or DKIM, careful validation, and ongoing review in practice. Yes, DMARC is a major email security control for organizations that need to reduce spoofing of their visible email domain. It tells receiving mail systems how to handle messages that fail DMARC after checking aligned SPF or DKIM authentication. DMARC is not a complete email-security program or a guarantee of inbox placement. Its value depends on identifying legitimate senders, validating their real message paths, and moving policy carefully. ## Quick takeaways - DMARC helps domain owners request handling for messages that fail aligned SPF and DKIM authentication. - A DMARC pass requires an aligned SPF or DKIM pass for the visible From domain. - `p=none` requests reporting without a handling preference, while `quarantine` and `reject` request stronger treatment for failures. - A published DMARC record does not prove that every legitimate application is authenticated correctly. - Receiving mail systems make their own final delivery and filtering decisions. - DMARC works best when teams use reports and message headers to identify every production sender before enforcement. ## How DMARC changes email-domain protection [DMARC, defined in RFC 9989](https://datatracker.ietf.org/doc/html/rfc9989), gives a domain owner a way to publish a DNS policy for mail that uses the domain in the visible From field. A receiver evaluates SPF and DKIM, checks whether either passing identifier aligns with that visible From domain, then applies the domain's requested DMARC policy after a failure. That alignment requirement is the part that makes DMARC more useful against straightforward domain spoofing than SPF or DKIM alone. A message can pass SPF for one domain or carry a DKIM signature for another domain without passing DMARC for the visible From domain. The policy has three familiar values: - `p=none` requests no specific handling for DMARC failures and can request aggregate reports. - `p=quarantine` asks receivers to treat failing messages as suspicious. - `p=reject` asks receivers not to accept failing messages. A receiving system retains the final decision. A `p=reject` record is a strong request, but it does not prove every receiver will reject every failing message. It also does not override a receiver's own spam, reputation, or local-policy decisions. ![DMARC decision flow showing aligned SPF or DKIM passing for the visible From domain, followed by the published policy when both fail](/images/editorial/is-dmarc-the-email-game-changer/is-dmarc-the-email-game-changer-dmarc-decision-flow.webp "1200x676") *Source: Palisade.* For broader protocol context, the [email authentication learning hub](/learning) covers the related roles of SPF, DKIM, and DMARC. ## When DMARC is the right answer, and when it is not enough DMARC is a strong answer when the problem is unauthorized mail that impersonates your domain in the visible From field. It gives receivers an authenticated policy signal and gives the domain owner aggregate feedback that can reveal sending sources using the domain. The answer changes when the organization has not yet mapped its real senders. Marketing platforms, support systems, billing applications, and older internal services may all send mail using the same domain. A policy change can affect legitimate mail if those paths do not produce an aligned SPF or DKIM pass. Use this decision rule: - If the concern is visible-domain spoofing, publish and mature DMARC. - If the concern is whether one specific message authenticated, inspect that message's raw headers and its `Authentication-Results` field. [RFC 8601](https://www.rfc-editor.org/rfc/rfc8601.html) defines this field for reporting authentication results. - If the concern is delivery or inbox placement, investigate the receiver's result and the actual message path. DMARC authentication supports trustworthy mail, but it does not guarantee inbox placement. - If the concern is a new sender, validate its configuration and a real delivered message before relying on the domain's enforcement policy. A DNS record alone cannot settle those questions. It shows what the domain publishes at that moment, not whether an application is using the expected return path, signing domain, or message configuration. ## A worked DMARC policy example This illustrative record asks for aggregate reports while the domain owner inventories senders: ```text v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com ``` Do not copy the reporting address into production until the reporting destination is authorized and owned by your organization. In this example: - `v=DMARC1` identifies the record as a DMARC policy record. - `p=none` requests no specific receiver handling for failures. - `rua` requests aggregate feedback at the listed destination. The record belongs at this DNS name: ```text _dmarc.yourdomain.com ``` The next evidence should come from four layers: - DNS: query the authoritative DNS service and at least one public resolver to confirm the intended record is published. - Vendor: confirm each sending service reports its configured authentication status. - Message: send a real message through each production path and inspect its `Authentication-Results` header. - DMARC: review aggregate reports after data accumulates to identify sources and authentication or alignment failures. A green status in a vendor interface is not proof that a real message passed DMARC. Likewise, a valid public DNS lookup does not prove that a particular application signs mail or uses the configured envelope sender. > Do not move to `p=quarantine` or `p=reject` until important production paths have been tested. An unverified sender can fail DMARC after enforcement and disrupt legitimate mail. [Are DMARC failure reports worth the trouble for email security?](/learning/what-exactly-is-a-dmarc-failure-report-and-why-should-you-care) explains why aggregate data matters after publication. ## Take the next practical step from the evidence you have If you have only a domain name, inspect its public DMARC record first. Use the [Palisade DMARC checker](/tools/dmarc) to check the currently published policy and tags, then compare the result with the DNS change your team intended to deploy. If you have a message that failed or was filtered, start with its raw headers instead. Look for `Authentication-Results` and compare the visible From domain with the SPF and DKIM identifiers reported by the receiving system. A public-record check cannot explain an individual receiver decision. If the record is present but your organization cannot account for every sender, keep the policy transition under review until reports and delivered-message tests identify the remaining paths. The case for DMARC is strongest when it becomes an operating process, not a one-time DNS edit. ## Continue the DMARC review after the record check A record lookup can confirm the public policy, but it cannot show which production systems still fail alignment or whether a later sender change will introduce a new gap. When that ongoing review needs a defined owner, start a Palisade account to continue the work with your domain evidence and approval process. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=existing_content_migration&utm_content=is-dmarc-the-email-game-changer) Palisade does not replace message-header testing, change your DMARC policy without human review, or guarantee delivery or inbox placement. For the business case around that work, see [how to win over execs to invest in DMARC and email security](/learning/how-can-you-win-over-execs-to-invest-in-dmarc-and-email-security). ## Sources and further reading - [RFC 9989: Domain-based Message Authentication, Reporting, and Conformance](https://datatracker.ietf.org/doc/html/rfc9989) - [RFC 8601: Message Header Field for Indicating Message Authentication Status](https://www.rfc-editor.org/rfc/rfc8601.html) - [Palisade DMARC checker](/tools/dmarc) ## Frequently asked questions ### Does DMARC stop all phishing? No. DMARC addresses unauthorized use of a domain in the visible From field when receivers evaluate and apply the domain's policy. Attackers can use unrelated domains, compromised accounts, or other techniques that DMARC does not prevent. ### Does DMARC require both SPF and DKIM to pass? No. DMARC can pass when either SPF or DKIM passes and the passing identifier aligns with the visible From domain. Using both authentication methods can provide useful resilience across different sending paths. ### Can a domain use DMARC with `p=none`? Yes. `p=none` is a valid DMARC policy that requests no particular handling for failures. It can be used with aggregate reporting while the organization identifies legitimate senders and fixes alignment issues. ### Does `p=reject` guarantee that spoofed mail is rejected? No. `p=reject` asks receivers to reject messages that fail DMARC, but each receiver makes its own final handling decision under its local policies. ### Should an organization check headers after publishing DMARC? Yes. A real delivered message's `Authentication-Results` field provides evidence about the exact sending path. DNS publication and vendor configuration indicators do not prove the authentication result of a delivered production message. --- # Paypal phishing scam email Canonical: https://www.palisade.email/learning/paypal-phishing-scam-email > Paypal phishing scam emails should be verified outside the message. Learn how to separate an impostor email from an unfamiliar PayPal request. A PayPal phishing scam email is a message that impersonates PayPal to pressure you to click a link, call a listed number, open an attachment, share information, or pay. Do not use the message to verify its claim. Open PayPal independently in your browser or app instead. If there is an unfamiliar invoice or money request in your account, do not pay it and use PayPal's reporting guidance for that request. ## Quick takeaways - Do not click links, call phone numbers, or download attachments in a suspected PayPal impostor message. - Open PayPal independently rather than through the email's buttons or instructions. - An email that claims a payment occurred and an unfamiliar in-account invoice are separate situations. - An unfamiliar invoice or money request is not a reason to pay or contact the number shown in the request. - In U.S. PayPal guidance, suspected impersonation emails can be forwarded to `phishing@paypal.com`. - A message that passes SPF or DKIM is not, by itself, proof that the payment claim or request is honest. ## How a PayPal phishing scam email works A PayPal-branded phishing message often tries to create urgency around a payment, account limitation, refund, security alert, or invoice. The attacker wants the recipient to act through a channel they control, such as a link, attachment, or phone number in the message. [PayPal's guidance for reporting suspicious messages](https://www.paypal.com/us/security/report-suspicious-messages?locale=us) says not to click links, call phone numbers, or download attachments in messages from PayPal imposters. That advice matters because a convincing logo, sender display name, or payment-related wording does not establish who controls the destination behind a link or number. The safe decision starts outside the message. Type the PayPal address into your browser yourself, or open the PayPal app directly. Then compare the message's claim with activity visible in your account. This is a PayPal-specific application of the broader checks in [Palisade's phishing email example guide](/learning/phishing-scam-email-example). ![Decision flow for a suspicious PayPal email, separating an unmatched email claim from an unexpected PayPal invoice or money request](/images/editorial/paypal-phishing-scam-email/paypal-phishing-scam-email-decision-flow.webp "1200x676") *Source: Palisade.* ## When the answer changes The key distinction is whether you are looking at a suspicious email claim or an actual unfamiliar invoice or money request visible after you opened PayPal independently. If you cannot find matching activity in PayPal, treat the email as a suspected impersonation message. Do not reply to it, use its links, or call its phone number. Use PayPal's suspicious-message reporting guidance instead. If you do find an unfamiliar invoice or money request in PayPal, do not assume that its presence makes it legitimate. [PayPal's invoice and money request scam guidance](https://pep.paypal.com/us/cshelp/article/what-are-invoice-scams-and-money-request-scams-on-paypal-help1059) says to verify through the PayPal website or app, not pay an unfamiliar request, and not use phone numbers or links in the request. Neither branch is a private fraud determination. A message can make a false claim about an activity that does not exist, while a real request can still be unwanted or suspicious. The decision rule is about choosing a safe verification and reporting path before you disclose information or send money. For the wider threat category, see Palisade's [email security learning hub](/learning/threats) and [threats and impersonation guidance](/learning/threats). ## A worked PayPal phishing decision rule Use this decision rule when an email says that a PayPal payment, invoice, refund, account restriction, or security event needs your attention. - **On receiving a suspicious PayPal-branded email:** do not click, call, reply, or download an attachment. - **Verify independently:** open PayPal through the app or a typed address, never the email's link. - **If no matching activity appears in PayPal:** report the suspected email through PayPal's applicable guidance. - **If an unexpected invoice or money request appears in PayPal:** do not pay it; report the request through PayPal. Do not publish, forward, or paste private account information, payment details, passwords, one-time codes, or full email headers into an untrusted channel while checking the message. A sender display name such as "PayPal" can be chosen by an attacker. The visible text of a link can also differ from its actual destination. Those clues can justify caution, but they do not replace independent verification in PayPal. Email authentication has a similar boundary. SPF and DKIM help receivers evaluate whether a message was authorized to use certain sending identities, but they do not prove that every message's business claim is genuine. [Why phishing emails can pass SPF and DKIM](/learning/why-do-phishing-emails-pass-spf-and-dkim) explains why authentication results must be interpreted within their limits. ## What to do with the evidence you have If you only have the email, leave its links, attachments, and phone numbers unused. Open PayPal independently and look for the transaction or account activity the message claims exists. If no matching activity appears, report the suspected email. PayPal's U.S. suspicious-message guidance directs users to forward suspicious emails to `phishing@paypal.com`. That address is stated in U.S. guidance, so do not assume it applies in every country or region. Use PayPal's local security or help resources when your account is outside that scope. If you find an unfamiliar invoice or money request after opening PayPal independently, do not pay it. [PayPal's instructions for cancelling or reporting a suspicious invoice or money request](https://securepayments.paypal.com/us/cshelp/article/how-do-i-cancel-or-report-a-suspicious-money-request-or-invoice-help995) document the reporting route through the PayPal website or app. > Do not contact a phone number supplied in an unfamiliar invoice or money request. Use PayPal independently to find support and reporting options. If you already clicked a link, entered credentials, shared a code, downloaded an attachment, or sent money, the pre-click decision is no longer enough. Follow the recovery-focused actions in [what to do after clicking a phishing link](/resources-post/what-to-do-if-you-clicked-on-a-phishing-link). ## Sources and further reading - [PayPal: Tell us about messages from PayPal imposters](https://www.paypal.com/us/security/report-suspicious-messages?locale=us) - [PayPal: What are invoice scams and money request scams?](https://pep.paypal.com/us/cshelp/article/what-are-invoice-scams-and-money-request-scams-on-paypal-help1059) - [PayPal: Cancel or report a suspicious money request or invoice](https://securepayments.paypal.com/us/cshelp/article/how-do-i-cancel-or-report-a-suspicious-money-request-or-invoice-help995) - [RFC 8601: Message Header Field for Indicating Message Authentication Status](https://datatracker.ietf.org/doc/html/rfc8601) ## Frequently asked questions ### Can someone access your bank account through PayPal? Only if you provide access or payment information through a fraudulent process, or if an attacker gains access to an account connected to your bank. Do not enter bank details, PayPal credentials, or one-time codes after following an unexpected email link. Open PayPal independently and review the account activity first. ### What is an example of a PayPal scam email? An example is an email claiming that you must urgently call a number, click a link, or cancel a payment that you do not recognize. The safe response is the same even if the message looks convincing: do not use the email's contact details, then verify the claim through PayPal independently. ### Where do I report PayPal phishing emails? In the United States, PayPal's suspicious-message guidance says to forward suspected impersonation emails to `phishing@paypal.com`. For an unfamiliar invoice or money request found in PayPal, use PayPal's website or app reporting instructions for that request. Check local PayPal guidance if your account is outside the United States. ### How to spot fake PayPal payment notifications? Check whether the notification tries to make you use its own link, attachment, phone number, or urgent instruction. Then open PayPal independently and look for matching activity. An unmatched email claim should be reported as a suspected impostor message, while an unfamiliar request visible in PayPal should not be paid and should be reported in PayPal. ### Does a PayPal logo prove that an email is real? No. A logo, familiar wording, and a PayPal-looking sender name can be copied into a phishing email. Verify the claimed payment or account event only after opening PayPal independently. ### Can SPF or DKIM prove a PayPal email is safe? No. SPF and DKIM provide authentication evidence about parts of the email path, but they do not prove that an invoice, payment notice, or support request is honest. Use them as limited technical evidence, then verify payment-related claims in PayPal itself. --- # Where to report a phishing email and what each route does Canonical: https://www.palisade.email/learning/report-email-phishing-scams > Report email phishing scams to the route that can act: your mailbox provider, your workplace, the impersonated brand, or a US reporting body. Where to send a phishing email depends on what you need done. Send it through your mail provider's phishing control for filtering review, through your employer or school's security channel for internal investigation, and through the impersonated organization's published abuse route when it accepts reports. In the United States, the FTC accepts fraud reports and directs suspicious email to the Anti-Phishing Working Group. Financial loss, identity theft, or a business incident needs a separate recovery or law-enforcement route. ## Quick takeaways - Start with the mailbox or organization responsible for the account. - Use the impersonated brand's current official reporting instructions when available. - A provider report, employer report, fraud report, and police report do different jobs. - Preserve the original message when the receiving process requests it. - Do not forward attachments or sensitive data to an address you have not verified. - Begin recovery immediately after credentials, devices, identity data, or money are affected. ## Choose the destination by the outcome you need The word "report" hides several different outcomes. A mailbox provider can review a message for abuse and filtering. An employer can search its environment, protect accounts, and remove related mail. An impersonated company can investigate abuse of its name or service. A consumer-protection body can collect fraud reports. Law enforcement can receive a complaint about crime or loss. One destination rarely does all of those jobs. Sending a suspicious message to a brand does not notify your employer that a staff account may be exposed. Clicking a provider's Report phishing control does not contact your bank. Filing a fraud report does not remove the message from coworkers' inboxes. Use the closest responsible body first, then add another report only when it has a distinct role. Verify a route before you use it: prefer a control inside your mail client or a destination published by the organization itself, rather than an address quoted in the suspicious message. The rest of this page maps each destination to the action it can actually take. If you have already clicked, start with [what to do if you clicked on a phishing link](/resources-post/what-to-do-if-you-clicked-on-a-phishing-link) and come back to reporting once containment is done. ## Send it to your mail provider for message handling Use the phishing-report control in the mail service that received the message. That keeps the report attached to the provider's copy and the account context it understands. Do not use a "Report" graphic inside the message. Use the mail application's own toolbar, menu, or organization-deployed control. Provider reporting is the closest route when your immediate goal is to classify the message and improve how that mailbox service handles it. Do not assume it opens a case you can track, blocks the sender for everyone, removes related messages, or tells your employer. For Microsoft users, [how to report a phishing email in Outlook](/learning/how-to-report-a-phishing-email-in-outlook) covers the client mechanics. Other providers publish different controls, and mobile apps can place them in a different menu. Use current provider documentation rather than a remembered screenshot. ## Send work or school mail to the security team A message received through an employer, school, nonprofit, or managed service belongs in that organization's documented reporting process. The security team can connect one report with directory activity, sign-in events, endpoint alerts, other recipients, mail trace data, supplier workflows, and previous cases. Follow the organization's preservation rule. The original message may contain addresses, routing headers, link destinations, and attachment metadata that a screenshot omits. Do not forward it broadly, upload it to an unapproved public service, or send sensitive customer and employee content outside the approved route. Say what happened. "Received only," "clicked," "entered password," "approved prompt," "opened file," and "sent money" require different responses. A silent report button cannot supply that context unless the workflow explicitly asks. If the organization has no published route, contact the help desk or security owner through a known directory entry. Do not guess a forwarding address from a general article. ## Send brand impersonation to the brand's official route Some organizations publish a forwarding address or form for messages that misuse their name. Use the route on the organization's official help or security page. Type the site address yourself or reach it from an app you already trust. Do not use a reporting address, phone number, or form linked by the suspicious message. The brand report can help the organization investigate impersonation, an abused account, a malicious site, or a fake support channel. Its scope varies. It may not respond to each reporter, recover your account, reverse a payment, or coordinate with your employer. Preserve forwarding headers if the published instructions request them. If a message contains private account or payment information, follow the brand's guidance on what to include. Do not add passwords, one-time codes, full card numbers, government identifiers, or unrelated mailbox content. ## Use US consumer fraud and phishing routes The Federal Trade Commission accepts fraud reports at ReportFraud.ftc.gov and directs suspicious phishing email to the Anti-Phishing Working Group at `reportphishing@apwg.org` ([FTC phishing guidance](https://consumer.ftc.gov/articles/how-recognize-avoid-phishing-scams)). These are additional US reporting routes, not replacements for a mailbox or workplace report. Use ReportFraud.ftc.gov when you are reporting a scam or fraud experience to the FTC. Forwarding the suspicious email to APWG supplies the message to an anti-phishing reporting body. Follow the current FTC page because destinations and instructions can change. If you disclosed personal information, the FTC points people to IdentityTheft.gov for a recovery plan. Recovery is a separate task from forwarding the message. Change exposed credentials through the real service, contact financial institutions through known numbers, and preserve transaction details. ![Routing map connecting a phishing message to the mailbox provider, organization, impersonated brand, consumer body, or incident recovery path](/images/editorial/report-email-phishing-scams/report-email-phishing-scams-routing-map.svg "1200x676") *Source: Palisade deterministic routing map based on [FTC phishing guidance](https://consumer.ftc.gov/articles/how-recognize-avoid-phishing-scams) and [CISA phishing guidance](https://www.cisa.gov/secure-our-world/recognize-and-report-phishing).* ## Use organizational and law-enforcement routes for serious incidents CISA publishes phishing reporting guidance for organizations and points organizations toward its incident-reporting channels and the FBI's Internet Crime Complaint Center ([CISA phishing guidance](https://www.cisa.gov/secure-our-world/recognize-and-report-phishing)). The FBI's IC3 accepts internet-crime complaints through its official site ([FBI Internet Crime Complaint Center](https://www.ic3.gov/)). Use an incident or law-enforcement route when the facts fit its scope, especially for business email compromise, fraud, extortion, account intrusion, or financial loss. File complete, accurate information and keep the complaint confirmation. Do not delay a bank recall, account containment, or device response while waiting to submit a complaint. Outside the United States, use the national cyber, fraud, or police service responsible for your jurisdiction. This article does not invent a universal address. Government routes, reporting thresholds, and emergency channels vary, so confirm them on the authority's own site. ## Preserve useful evidence without spreading the threat The destination's instructions control what to send. Useful fields can include the original message, full sender and reply addresses, subject, delivery time, real link destination, attachment name, claimed transaction, report time, and a short account of any interaction. Forward as an attachment only when the verified instructions request it and your organization permits it. Ordinary forwarding can change headers and expose a live link or attachment to another person. A screenshot shows what you saw but may omit routing and destination evidence. Use a simple intake note: ```text Mailbox or organization: Message received at: Displayed sender and full address: Claimed person, brand, or transaction: Requested action: Interaction: none, clicked, signed in, opened, approved, or paid Reports already submitted: Recovery already started: ``` Redact the note before sharing it outside the authorized process. Never include a password, private key, full payment-card number, one-time code, or unneeded personal data. ## Do not confuse reporting with blocking or avoidance Reporting routes the evidence. Blocking changes how a mailbox handles later messages. Avoidance is the habit of verifying requests outside the message. Those are related actions, not duplicate names for one control. Use [how to block phishing emails](/learning/how-to-block-phishing-emails) for filters, rules, and sender blocks. Use [how to avoid phishing emails](/learning/how-to-avoid-phishing-emails) for recognition and verification habits. A person may need all three: avoid the unsafe action, report the evidence, then block a repeat pattern. If someone already interacted, recovery outranks tidy routing. Start the credential, endpoint, identity, or payment process, then send the report to each body that has a separate job. ## Sources and further reading - [FTC: How to recognize and avoid phishing scams](https://consumer.ftc.gov/articles/how-recognize-avoid-phishing-scams) - [CISA: Phishing guidance, stopping the attack cycle](https://www.cisa.gov/secure-our-world/recognize-and-report-phishing) - [FBI Internet Crime Complaint Center](https://www.ic3.gov/) ## Frequently asked questions ### Where should I forward a phishing email in the United States? Start with the mail provider or workplace reporting route. The FTC also directs suspicious phishing email to `reportphishing@apwg.org` and accepts fraud reports at ReportFraud.ftc.gov. Use IC3 when the facts fit an internet-crime complaint, especially after fraud or financial loss. ### Should I send phishing email to the company being impersonated? Only when the company publishes a current reporting address or form. Find it through the company's official site or app, not through the suspicious email. A brand report does not replace your mailbox, workplace, bank, or incident report. ### Is reporting to my email provider enough? No, not when the message affected a work environment, account, device, identity, or payment. Provider reporting handles the message channel. The responsible organization or service must handle containment and recovery. ### Can I forward the email to a coworker for advice? Not casually. Use the organization's approved security route. Forwarding can spread active links or attachments and may change useful headers. Send only the evidence the authorized process requests. ### Should I report before deleting the message? Yes, when a verified provider or organization process asks for the original. Preserve the message until that process captures the needed evidence. Afterward, follow its cleanup instruction rather than assuming deletion is always the next step. ### What if I already sent money or entered personal information? Start recovery immediately. Contact the bank or service through known information, secure exposed accounts, and use the identity-theft or incident process that matches the loss. Reporting the email remains useful, but it cannot reverse the action by itself. --- # Report a Social Security phishing email Canonical: https://www.palisade.email/learning/report-social-security-phishing-email > Report a Social Security phishing email safely: do not reply, pay, or share information. Verify any reporting destination is an official government site. If you receive a suspected Social Security phishing email, do not reply, send money, or share personal information. Keep the message available as evidence, then independently open an official government website before using any reporting option or sharing details. The Social Security Administration Office of the Inspector General, or SSA OIG, warns that impersonation attempts can arrive by email and that SSA and OIG will not demand payments or secrecy. ## Quick takeaways - A Social Security phishing email may impersonate SSA or the SSA OIG. - Do not transfer money, buy gift cards, send cryptocurrency, or share sensitive information in response to the email. - A request to keep a payment or communication secret conflicts with SSA OIG guidance. - Do not trust a reporting link or contact detail contained in the suspicious message. - Verify that any destination for sensitive information is an official federal government site. - Social Security impersonation is one type of [email threat](/learning/threats) that can target individuals and organizations. ## How Social Security phishing emails work A Social Security phishing email is an impersonation message that tries to make the recipient believe it came from the Social Security Administration or its Office of the Inspector General. The [SSA OIG scam warning](https://oig.ssa.gov/) tells the public: "Be on the lookout for fake calls, texts, emails, websites, messages on social media, or letters in the mail." The important safety decision is based on what the message asks you to do, not on a logo, sender display name, or urgent wording. The SSA OIG states: "SSA and OIG will never ask you to transfer money to protect it, meet you in person to exchange cash, gift cards, crypto currency, gold bars, or require you to keep information secret or confidential." Treat an email as untrusted when it asks for any of those actions. Do not use the reply button to challenge the sender or request confirmation. A reply can disclose that the mailbox is active, and the sender can continue the impersonation attempt. Do not rely on a link in the message to decide where to report it either. The SSA OIG advises: "Before sharing sensitive information, make sure you're on a federal government site." Open your browser separately and type or select a government destination independently. The same approach applies to other impersonation messages. [Reporting email phishing scams](/learning/report-email-phishing-scams) can help distinguish the immediate evidence-preservation task from broader account or organizational follow-up. ## When the reporting decision changes The supplied official guidance supports a clear safety rule, but it does not establish a specific email-forwarding address, web form, or mail-provider reporting path for Social Security phishing emails. Do not guess at an address, copy one from a suspicious email, or assume that an old forwarding address is still active. Use this decision rule: - If the email asks for money, gift cards, cryptocurrency, gold, cash exchange, or secrecy, stop interacting with it. - If the email asks for sensitive information, do not provide it until you have independently confirmed that the destination is an official federal government site. - If you need a government reporting channel, locate it directly from an official government site rather than from the email. - If the message reached a work mailbox, follow your organization's incident-reporting process in addition to preserving the message. A phishing attempt can be malicious even if it does not ask for payment. The official warning covers fake emails broadly. At the same time, the cited material does not document every possible scam pattern, so do not treat the listed red flags as the only reasons to be cautious. ![Decision flow for handling a suspected Social Security phishing email, from identifying payment or secrecy requests to independently finding an official reporting destination](/images/editorial/report-social-security-phishing-email/report-social-security-phishing-email-decision-rule.webp "1200x676") *Source: Palisade.* ## Worked example: apply the SSA OIG warning Suppose an email claims that your Social Security number is at risk and instructs you to buy gift cards or transfer cryptocurrency to protect your account. The stated payment method and request for secrecy match conduct the SSA OIG says SSA and OIG will never request. ```text Claimed sender: "Social Security Administration" Message request: "Transfer cryptocurrency immediately to protect your information. Do not discuss this matter with anyone." Decision: Do not reply, pay, or share information. Preserve the message. Independently open an official federal government website before using any reporting option or providing details. ``` This example is a decision rule, not a list of authentic Social Security email characteristics. The available official material confirms that scammers can use fake emails, but it does not establish when or how Social Security sends legitimate email. Do not approve a message because its sender name appears plausible. If you inspect the message for internal incident response, preserve the original safely according to your organization's process. Do not forward sensitive content broadly or publish personal data from the email. For a similar consumer-facing reporting scenario, see [how to report an Amazon phishing email](/learning/amazon-report-phishing-email). ## Take the next safe step Start with the evidence you have: - If you only have the suspicious email, stop interacting with it and independently locate an official government destination before reporting or sharing details. - If you have already replied, paid, or shared information, use independently located official channels and your organization's incident process. The cited guidance does not provide a specific remediation workflow. - If this type of message reached a business mailbox, assess whether the organization has clear phishing-reporting guidance and technical controls. [Email security guidance](/learning/threats) covers the broader practices that reduce exposure to malicious email. - If you manage a domain and want to review its public email-security posture, use the [Email security score tool](/tools/email-security-score). It can inspect public domain signals, but it cannot determine whether a specific Social Security email is fraudulent, report that message to a government agency, or prove how a recipient mailbox handled it. ## Review your organization's email-security posture A Social Security impersonation email is a reminder to check how staff identify and escalate suspicious messages. Review your email-security controls and reporting process alongside the evidence from the actual message. [Read the email security guide](/learning/threats) An email-security guide cannot validate a particular reporting destination, recover money, or establish whether Social Security sent a specific email. ## Sources and further reading - [Social Security Administration Office of the Inspector General scam warning](https://oig.ssa.gov/) - [Social Security Advisory Board information on government-imposter scams](https://ssab.gov/) - [Palisade email security guide](/learning/threats) - [Palisade Email security score tool](/tools/email-security-score) ## Frequently asked questions ### Where can I forward phishing emails to the government? The SSA OIG warning does not identify a specific forwarding address or reporting form for phishing emails. Do not use an address provided in the suspicious message. Independently open an official government website and confirm the destination before sending any details. ### How do I report an email as a phishing email? The available official material does not document a mail-provider "Report phishing" control or a specific SSA OIG reporting procedure. Preserve the email, stop interacting with it, and find a current reporting option through an independently opened official government website. ### Does Social Security send out emails? Not according to the available SSA OIG warning, which confirms that scammers may send fake emails but does not state when, whether, or how Social Security sends legitimate emails. Do not treat a familiar sender name or government branding as proof that an email is authentic. ### Should I reply to a suspected Social Security phishing email? No. Do not reply, send money, or provide personal information. The SSA OIG says SSA and OIG will never ask you to transfer money to protect information or require secrecy. ### What payment requests are red flags in a Social Security email? Requests to transfer money, exchange cash, buy gift cards, send cryptocurrency, or provide gold bars are red flags. The SSA OIG states that SSA and OIG will never make those requests. --- # SPF flattening tool Canonical: https://www.palisade.email/learning/spf-flattening-tool > SPF flattening tool guidance: check DNS lookup usage, understand the 10-lookup limit, assess flattening risk, and retest public SPF records. An SPF flattening tool replaces DNS-based SPF mechanisms with IP address ranges to reduce DNS lookups. Before using one, check the published SPF record and its lookup usage. The [Palisade SPF checker](/tools/spf) can inspect the public SPF record for a domain, but it does not generate, publish, or maintain a flattened record. A passing public lookup also does not prove the production sender uses the intended SPF policy. ## Quick takeaways - SPF evaluation permits no more than 10 DNS-querying terms during one check. - Exceeding the SPF lookup limit produces an SPF `permerror` under RFC 7208. - Flattening replaces some DNS indirection with IP ranges, which creates a maintenance obligation when providers change their infrastructure. - Do not flatten `include:spf.protection.outlook.com` unless Microsoft has approved a stable range arrangement and you can maintain it. - A public SPF check must be paired with a delivered-message check to confirm the production sending path. - DMARC aggregate reports show whether real traffic later passes SPF and aligns with the visible From domain. ## What this tool checks The [Palisade SPF checker](/tools/spf) accepts a domain and checks its publicly visible SPF DNS record. Use it to inspect the record before deciding whether lookup count is the problem. It is a diagnostic checker. For the hosted service that keeps a record under the limit permanently, see [SPF flattening](/features/spf-flattening). SPF records can cause further DNS work through mechanisms and modifiers such as `include`, `a`, `mx`, `ptr`, `exists`, and `redirect`. [RFC 7208 section 4.6.4](https://www.rfc-editor.org/rfc/rfc7208#section-4.6.4) limits an SPF evaluation to 10 DNS-querying terms. A receiver that needs to evaluate an eleventh term must return `permerror`. The checker cannot see: - The actual SPF identity a receiving server evaluated, such as the SMTP `MAIL FROM` domain or HELO domain. - Whether a sending application used the domain you checked. - Whether the receiver accepted, rejected, or spam-foldered a particular message. - Changes inside an external provider's sending infrastructure after the public check. - The current IP ranges that a separate flattening service may have generated. For the protocol context behind this diagnostic, see the [email authentication learning hub](/learning/dmarc). For a definition of the practice and its tradeoffs, read [What is SPF flattening?](/learning/email-questions/what-is-spf-flattening). ## How to run the check ### 1. Identify the envelope-sending domain Start with a recent delivered message from the affected production path. In the raw message source, find the receiver's `Authentication-Results` header and identify the SPF result and the domain associated with the evaluated SMTP identity. [RFC 8601 defines the Authentication-Results header field](https://www.rfc-editor.org/rfc/rfc8601). Do not assume the visible From domain is the domain whose SPF record the receiver evaluated. SPF normally evaluates the SMTP envelope sender, and DMARC later tests whether a passing SPF domain aligns with the visible From domain. ### 2. Inspect the published SPF record Enter the exact sending domain in the Palisade SPF checker. Record the returned SPF policy and the time of the check. If the domain has no SPF record, flattening is not the first task. First establish which system sends mail for that domain and obtain its approved SPF configuration. You can repeat the public DNS lookup independently: ```bash dig +short TXT yourdomain.com ``` If several TXT strings appear, identify the one beginning with `v=spf1`. DNS may return the parts of one long TXT record separately. Preserve their order when reviewing the full policy. > Do not publish a flattened record by copying IP ranges from another organization's DNS or documentation. Use only values generated and approved for your own sending services. ![Decision map for checking whether SPF lookup usage requires a repair](/images/editorial/spf-flattening-tool/spf-flattening-tool-decision-map.webp "1200x829") *Source: Palisade.* ### 3. Count terms that can trigger DNS lookups Read the policy recursively. Each `include` causes another SPF policy evaluation, and that nested policy can contain more DNS-querying terms. An `include` does not count as only one lookup if its target expands into additional DNS work. Count the terms that RFC 7208 identifies as capable of causing DNS queries: ```text Illustrative only v=spf1 include:mailer.yourdomain.com include:crm.yourdomain.com -all ``` The two visible `include` terms are only the start of the count. Query each included domain and count its DNS-querying mechanisms too. This is why a short-looking SPF record can still exceed the limit. ### 4. Separate a lookup problem from another SPF failure If a receiver reports `permerror`, confirm that the error relates to the lookup limit before changing the record. A missing record, malformed syntax, an incorrect envelope domain, and an authorization mismatch need different repairs. Keep four evidence layers separate: - DNS: Query the record from the authoritative DNS provider and a public resolver. - Vendor: Confirm the sending service's domain-authentication status in its current interface. - Message: Send a new message through the same production application and inspect its raw headers. - DMARC: Review aggregate-report data after reports accumulate to find sources that still fail SPF or fail alignment. A green status in a sender's interface is useful vendor evidence. It is not proof that a recipient received a message through the intended return path. ## How to interpret the results ### The SPF policy stays within the DNS lookup limit A record that stays within the 10 DNS-querying-term limit does not need flattening solely for lookup count. Continue with message evidence. A delivered message can still fail SPF because the sender uses a different envelope domain, an unauthorized IP address, or a different route than the one assumed from DNS. If SPF passes but DMARC fails, compare the SPF-authenticated domain to the visible From domain. SPF can pass without satisfying DMARC alignment. ### The SPF policy exceeds the DNS lookup limit An SPF evaluation that exceeds the limit returns `permerror` under [RFC 7208 section 4.6.4](https://www.rfc-editor.org/rfc/rfc7208#section-4.6.4). Reduce the recursive DNS-querying terms before treating the policy as reliable. Flattening can reduce queries by replacing selected dependencies with current IP ranges. That improvement has a cost: the range list must change when the provider changes its infrastructure. A stale flattened policy can exclude legitimate sending IPs or retain addresses that no longer belong in the authorization set. ### The SPF record is missing or does not match the sender A missing SPF record is not evidence that flattening will help. Identify the actual outbound service, then use that service's current domain-authentication instructions to publish the correct SPF authorization. If the public record looks correct but the message fails, inspect the message's evaluated SMTP identity and the connecting IP. The failure may be in the sender configuration or routing path rather than the visible DNS policy. ### The public record is valid but the message still fails Treat DNS and message results as separate facts. The record may authorize one provider while the failed message came from another source, subdomain, relay, or return path. Use the receiver-added `Authentication-Results` header to establish the SPF result for the delivered message. Then compare the evaluated domain with the record you checked. Do not infer message behavior from a public DNS result alone. ## How to act on the result If the recursive count exceeds 10, first remove obsolete services and duplicate authorization paths. Each retired sender should be removed only after confirming it no longer sends through the domain. For active services, prefer a provider-supported authorization method that keeps the policy maintainable. Flatten only the dependencies you can refresh from an approved source and validate after each provider-side change. Microsoft specifically warns administrators not to flatten `include:spf.protection.outlook.com` in ordinary Office 365 configurations. [Microsoft's SPF configuration guidance](https://learn.microsoft.com/en-us/defender-office-365/email-authentication-spf-configure) describes a narrow stable-range exception that requires ongoing maintenance. Do not substitute a copied address list for the published Microsoft include. If the issue is an SPF `permerror`, follow the repair process in [How to fix SPF PermError: too many DNS lookups](/learning/how-do-i-fix-spf-permerror-too-many-dns-lookups). If you need a checker-centered workflow for the existing public record, use the [SPF record checker](/tools/spf). ## How to retest Query the same domain again after the authoritative DNS answer changes. Then send a new message through the same application, sender address, relay, and recipient path that produced the original result. The expected DNS change is a public SPF record whose recursive DNS-querying terms stay at or below the RFC limit. The expected message change is an SPF result from the exact production path that no longer returns `permerror`. After message evidence is available, review DMARC aggregate reports. They reveal whether the domain has other production sources that were not represented in the single retest message. ## Check lookup usage before changing SPF Use the [Palisade SPF checker](/tools/spf) to inspect the current public SPF policy and identify whether the published record needs a closer lookup-count review before you change it. [Check the public SPF record](/tools/spf) A public SPF check cannot generate or safely maintain a flattened policy, prove the production sending path, or guarantee delivery at a receiving mailbox. ## Sources and further reading - [RFC 7208 section 4.6.4: SPF DNS lookup limits](https://www.rfc-editor.org/rfc/rfc7208#section-4.6.4) - [RFC 8601: Authentication-Results header field](https://www.rfc-editor.org/rfc/rfc8601) - [Microsoft SPF configuration guidance](https://learn.microsoft.com/en-us/defender-office-365/email-authentication-spf-configure) - [Palisade SPF checker](/tools/spf) - [What is SPF flattening?](/learning/email-questions/what-is-spf-flattening) ## Frequently asked questions ### Does an SPF flattening tool fix every SPF error? No. Flattening addresses DNS lookup depth for selected dependencies. It does not fix a missing SPF record, an unauthorized sending IP, an incorrect envelope sender, malformed syntax, or DMARC alignment. ### Can I flatten Microsoft 365 SPF records? Only under Microsoft's documented stable-range exception and with a process to maintain the ranges. Microsoft's normal guidance says not to flatten `include:spf.protection.outlook.com`. ### Does a public SPF check prove that SPF passes in production? No. It proves only what is publicly published at the checked domain and time. A real delivered message is needed to confirm the SMTP identity, connecting path, and receiver's SPF result. ### Why does SPF have a 10-lookup limit? RFC 7208 limits SPF evaluation to 10 DNS-querying terms to bound the DNS work required during message evaluation. Exceeding that limit returns `permerror`. ### Should I flatten every include in an SPF record? No. Flattening every include can create a record that becomes stale when providers change their sending ranges. Remove unused services first, then flatten only dependencies you can maintain and validate. --- # Does a subdomain need its own SPF record? Canonical: https://www.palisade.email/learning/spf-record-for-subdomains > Does a subdomain need its own SPF record? Yes, when it is the MAIL FROM or HELO domain SPF evaluates. Learn how to verify the exact identity. Yes, a subdomain needs its own SPF record when a sending system uses that subdomain as its MAIL FROM identity, or as its HELO identity when the reverse path is empty. SPF checks the exact SMTP identity presented by the message. A parent-domain SPF record does not automatically apply to a subdomain. A visible From address on a subdomain alone does not determine where SPF looks. ## Quick takeaways - SPF evaluates the MAIL FROM domain when available, then the HELO domain for a null reverse path. - SPF does not inherit a parent domain's DNS policy at a subdomain. - A subdomain used only in the visible From address may not need its own SPF record. - Each active SPF identity needs one valid SPF record at its exact DNS name. - DMARC relaxed alignment can accept related domains only after SPF passes. - Delivered-message headers show the identity SPF actually evaluated. ## How SPF selects a subdomain record [RFC 7208 defines the SPF evaluation identity](https://www.rfc-editor.org/rfc/rfc7208.html): a receiver normally evaluates the domain in the SMTP `MAIL FROM` command. If the message has a null reverse path, the receiver evaluates the `HELO` or `EHLO` domain instead. It then retrieves SPF policy for that identity's domain. For example, if a marketing platform sends with `bounce.news.yourdomain.com` as MAIL FROM, SPF looks for a TXT record at `bounce.news.yourdomain.com`. It does not look at `yourdomain.com` and extend that policy downward. If no SPF record exists at the evaluated subdomain, the SPF result is `none`. The presence of a valid record at the parent does not change that result. RFC 7208 also says a domain must not publish multiple SPF records that cause multiple applicable records to be selected. The visible From address has a separate role. A message can show `From: updates@news.yourdomain.com` while using `bounce.yourdomain.com` in MAIL FROM. SPF checks the latter identity. DMARC later compares an authenticated SPF identity with the visible From domain. For the wider protocol context, see [Palisade's email authentication learning center](/learning). ![Record map showing separate SPF TXT owner names for a parent domain and a sending subdomain](/images/editorial/spf-record-for-subdomains/spf-record-for-subdomains-spf-owner-names.webp "1200x533") *Source: Palisade.* ## When a subdomain needs a separate SPF record Use this decision rule for each production sending path: - If the subdomain appears as the actual MAIL FROM domain, publish and maintain SPF at that exact subdomain. - If a message has an empty MAIL FROM and the subdomain appears in HELO or EHLO, publish and maintain SPF at that HELO domain. - If the subdomain appears only in the visible From address, inspect the delivered message before adding SPF. The SPF identity may be different. - If the subdomain never appears as an SPF identity, a parent SPF record still does not cover it, but the subdomain may not need a sending authorization record. DMARC does not make SPF records inherit. [RFC 9989 defines DMARC SPF alignment](https://www.rfc-editor.org/rfc/rfc9989.html) as a comparison between an SPF-authenticated identifier and the RFC 5322 From domain. Under relaxed alignment, related subdomains can align with their organizational domain. Under strict alignment, the domains must match exactly. In either case, SPF must first pass for the domain it evaluated. A common example is a transactional sender that uses `mail.yourdomain.com` in the visible From address but a provider-managed return path under `bounce.yourdomain.com`. The relevant SPF record is the one at `bounce.yourdomain.com`, provided that is the MAIL FROM identity shown in the delivered message. Do not add an SPF record to `mail.yourdomain.com` based only on the visible From address. > Do not replace an existing SPF TXT record by adding a second one. Consolidate authorized mechanisms into the single SPF policy for that exact owner name, then verify the sending path before removing any existing authorization. ## Worked SPF record example The following is illustrative only. Do not publish this record unchanged. Use the sending provider's generated authorization values and confirm which MAIL FROM or HELO identity its production messages use. ```text bounce.yourdomain.com. IN TXT "v=spf1 include:spf.example-provider.com -all" ``` This example authorizes the provider named by the `include` mechanism to send mail using `bounce.yourdomain.com` as the evaluated SPF identity. It does not authorize the same provider for `yourdomain.com`, `news.yourdomain.com`, or any other sibling name. A practical evidence object starts with the delivered message. Look for fields such as: ```text Return-Path: <bounces@bounce.yourdomain.com> Authentication-Results: recipient.example; spf=pass smtp.mailfrom=bounce.yourdomain.com ``` The `Authentication-Results` header is generated by the receiving system and can show the SPF result and evaluated identity. [RFC 8601 specifies the Authentication-Results header field](https://www.rfc-editor.org/rfc/rfc8601.html). Header formatting and available properties can vary by receiver, so use the delivered message from the exact production route rather than copying a header from another sender. ## Verify the subdomain by the evidence you have If you have a delivered message, inspect its `Return-Path` and authentication results first. Record the `smtp.mailfrom` value when present. That is the strongest starting point for deciding which DNS name needs an SPF policy. If you have DNS access but no message evidence, list each sending platform and ask which custom return-path, envelope sender, or HELO identity it uses. A provider's configuration screen can show an intended identity, but it does not prove that the production message uses it. Then validate at four layers: - Query authoritative DNS and at least one public resolver for the exact evaluated domain, such as `bounce.yourdomain.com`. - Confirm the sending provider reports its authenticated domain or custom return path as verified, where that provider exposes a status. - Send a real message through that platform and inspect the resulting headers for an SPF pass at the expected identity. - Review DMARC aggregate reports after they accumulate to find sources or alignment failures that a single test message missed. For record-level inspection, use Palisade's [SPF checker](/tools/spf) with the exact parent or subdomain name. It can show the public DNS policy currently returned for that name. A public DNS result does not prove that the provider is using that return path, that a specific message passed SPF, or that receivers will make the same delivery decision. If the evidence shows that SPF passes but DMARC fails, compare the SPF-authenticated domain with the visible From domain and review DKIM setup for subdomains. DKIM can provide the aligned authentication result for a path where SPF uses a different domain. For a broader inventory of mail-related DNS records, see [what DNS records a business email domain needs](/learning/dns-records-for-business-email). ## Check the SPF record for the sending subdomain Start by checking the exact subdomain found in the delivered message, such as `bounce.yourdomain.com`. Compare the public SPF record with the identity the provider and production headers show. [Check the subdomain's SPF record](/tools/spf) A DNS check cannot prove that every production sender uses the checked subdomain, repair a failed sending path, or show a receiver's future placement decision. When multiple domains or sending sources need ongoing review, Palisade is agentic DMARC software that analyzes DMARC aggregate-report data, identifies sending sources and authentication or alignment issues, and creates prioritized remediation tickets. It can propose the next DMARC policy step for human review, but it does not change the DMARC policy or guarantee delivery. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=email_authentication&utm_content=spf-record-for-subdomains) ## Sources and further reading - [RFC 7208: Sender Policy Framework](https://www.rfc-editor.org/rfc/rfc7208.html) - [RFC 9989: Domain-based Message Authentication, Reporting, and Conformance](https://www.rfc-editor.org/rfc/rfc9989.html) - [RFC 8601: Authentication-Results header field](https://www.rfc-editor.org/rfc/rfc8601.html) - [Palisade SPF checker](/tools/spf) ## Frequently asked questions ### Does a visible From subdomain need its own SPF record? No. SPF normally evaluates the MAIL FROM domain, not the visible From domain. Check a delivered message's `Return-Path` and authentication results before deciding where an SPF record belongs. ### Can a parent SPF record authorize mail from every subdomain? No. SPF has no parent-domain inheritance rule. Each subdomain that SPF evaluates needs its own policy at that exact DNS owner name. ### Can two subdomains use the same SPF policy content? Yes. They can contain similar or identical mechanisms when the same services are authorized to send using each identity. Each subdomain still needs its own single SPF record. ### Does relaxed DMARC alignment remove the need for SPF on a sending subdomain? No. Relaxed alignment applies after SPF has passed. The receiver must first find and evaluate SPF policy for the actual MAIL FROM or HELO identity. ### What if a subdomain has no SPF record? If SPF evaluates that subdomain and finds no policy, the SPF result is `none`. A parent-domain SPF record does not supply a fallback policy for the missing subdomain record. --- # What causes SPF TempError? Canonical: https://www.palisade.email/learning/spf-temperror > SPF TempError means SPF evaluation hit a temporary DNS or processing failure. Find the evaluated domain, trace its lookups, and validate the sending path. SPF TempError means the receiving system could not complete SPF evaluation because it encountered a transient problem, usually a DNS error or timeout. A later evaluation can succeed without any record change. Repeated SPF TempError needs investigation because a failure in the evaluated domain or any SPF dependency can prevent an intended SPF pass and, where relevant, prevent DMARC from using SPF as aligned authentication. ## Quick takeaways - SPF TempError is a temporary evaluation failure, not an explicit SPF authorization failure. - DNS errors and timeouts during SPF processing can produce SPF TempError. - The failing DNS name may belong to an `include` or `redirect` dependency rather than your visible From domain. - An SPF processing-limit violation produces SPF PermError, which requires a different repair path. - A delivered message's `Authentication-Results` header identifies the SPF result and evaluated identity. - A successful public DNS lookup does not prove that the affected production message path is now reliable. ## How SPF TempError happens [RFC 7208 defines SPF TempError](https://www.rfc-editor.org/rfc/rfc7208.html) as a transient error during SPF processing. The RFC describes it as generally DNS-related, with the expectation that a later attempt may succeed without action by the DNS operator. This differs from SPF PermError, which indicates a condition that needs correction before SPF evaluation can succeed. SPF evaluates an SMTP identity, usually the envelope sender domain rather than the domain readers see in the From header. If those identities differ, review [what SPF is](/learning/what-is-spf) before assuming which domain failed. An SPF record can require DNS queries for mechanisms and modifiers such as `include`, `redirect`, `a`, `mx`, and `exists`. [RFC 7208's DNS lookup rules](https://www.rfc-editor.org/rfc/rfc7208.html#section-4.6.4) state that a DNS query error, including a timeout, during those operations can terminate evaluation with TempError. The same section recommends a limit on total SPF evaluation time. If a receiver reaches its time limit, the result can also be TempError. A receiving system decides how to handle the message after SPF evaluation under its local policy. SPF TempError itself does not prove that the sender is unauthorized, that a recipient rejected the message, or that a retry will succeed at every receiver. ## When SPF TempError means a different problem The practical cause depends on which DNS lookup failed and whether the issue repeats. - A timeout or server failure at the evaluated domain can cause SPF TempError. Intermittent authoritative DNS availability, incomplete delegation, or resolver reachability may affect some receiving systems while others use cached data. - A failure in an `include` or `redirect` target can propagate to the top-level evaluation. The published SPF record may be available, while a provider-managed dependency is temporarily unavailable. - Slow resolution across a large dependency chain can reach a receiver's overall SPF evaluation time limit. This is separate from the SPF DNS-querying-term limit. - Too many DNS-querying terms is not SPF TempError. RFC 7208 requires SPF PermError when evaluation exceeds the limit of ten DNS-querying mechanisms and modifiers. - Multiple SPF records, invalid syntax, or other permanent record defects also require a PermError investigation rather than a transient-DNS investigation. Use the exact result from the affected message. [RFC 8601 defines the `Authentication-Results` header field](https://www.rfc-editor.org/rfc/rfc8601.html), which can show the SPF result and an evaluated property such as `smtp.mailfrom`. That receiver-added evidence is more useful than guessing from the visible From address. ![Decision flow for tracing an SPF TempError from the evaluated SMTP identity through DNS dependencies and production-message validation](/images/editorial/spf-temperror/spf-temperror-temperror-decision-flow.webp "1200x829") *Source: Palisade.* ## Worked SPF TempError evidence example A delivered message may contain an authentication result shaped like this: ```text Authentication-Results: receiver.example; spf=temperror smtp.mailfrom=bounces.yourdomain.com ``` This is illustrative only. Do not publish full message headers because they can contain recipient addresses, message identifiers, routing details, and other private data. The example tells you to start at `bounces.yourdomain.com`, not automatically at the visible From domain. Resolve that domain's SPF TXT record, then trace each DNS-dependent branch that the receiving system could reach for the sending IP. Record each lookup with its time, resolver, response, and authoritative nameserver where available. Focus on observable failures: - A resolver returns `SERVFAIL`, times out, or returns no usable response where a DNS-dependent SPF step needs one. - Different resolvers produce inconsistent results. - A provider-owned SPF dependency repeatedly fails during the same periods as the affected messages. - The message path produces TempError again after DNS appears healthy in a one-time public check. > Do not replace an SPF provider `include` with copied IP ranges as a quick fix. That can leave authorized sending infrastructure stale when the provider changes its published SPF record. For an operator-facing definition of the result, see [what SPF TempError means](/learning/glossary/spf-temperror). The separate question of SPF record construction belongs in the [SPF checker](/tools/spf), which can inspect a public record but cannot replay a recipient's past DNS resolution. ## Validate the cause with the evidence you have Start with the message evidence. Preserve the result, time, connecting IP where available, and evaluated SPF identity from the receiver. If a bounce or provider dashboard reports a temporary SMTP response, preserve that text exactly as well. Next, query the evaluated domain and its referenced SPF domains through more than one public resolver. Compare those results with direct authoritative DNS checks if your operational access permits it. A passing cached answer is useful evidence, but it cannot disprove an intermittent authoritative DNS or network failure. Then send a controlled message through the same production application, relay, and envelope-sender path. Check the delivered message's `Authentication-Results` header rather than relying only on an ESP status indicator or DNS checker result. If SPF passes, check whether the passing `smtp.mailfrom` domain aligns with the visible From domain for DMARC. After the immediate repair, review DMARC aggregate reports once they accumulate. This layer can reveal whether a source still produces authentication failures at scale, but it does not replace the message-level evidence for the individual TempError. You can use Palisade's [SPF checker](/tools/spf) to inspect the public SPF record for the evaluated domain. It is a useful configuration check when you have the domain name. It does not prove the DNS response a particular receiver received, inspect a private provider decision, or monitor future DNS reliability. ## Track the sending sources that still need remediation After you isolate the DNS dependency, the remaining question is whether other production senders use the same domain or still fail authentication. Palisade is agentic DMARC software that analyzes DMARC aggregate-report data, identifies sending sources and authentication or alignment issues, and creates prioritized remediation tickets. It can propose the next DMARC policy step when the evidence supports it, while a human reviews the evidence and applies the change. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=existing_content_migration&utm_content=spf-temperror) Palisade cannot prove the cause of one historical SPF TempError, repair an unavailable third-party DNS dependency, or guarantee that every future message will authenticate. ## Sources and further reading - [RFC 7208: Sender Policy Framework](https://www.rfc-editor.org/rfc/rfc7208.html) - [RFC 7208 section 4.6.4: DNS lookup limits and void lookups](https://www.rfc-editor.org/rfc/rfc7208.html#section-4.6.4) - [RFC 8601: Authentication-Results header field](https://www.rfc-editor.org/rfc/rfc8601.html) - [RFC 9989: Domain-based Message Authentication, Reporting, and Conformance](https://www.rfc-editor.org/rfc/rfc9989.html) ## Frequently asked questions ### Is SPF TempError the same as SPF fail? No. SPF fail is an SPF result that states the sending IP is not authorized under the evaluated SPF policy. SPF TempError means the receiver could not complete SPF evaluation because of a transient condition. ### Can an SPF include cause TempError? Yes. SPF evaluation can query domains referenced through `include` or `redirect`. A DNS error or timeout in one of those dependencies can cause the top-level SPF evaluation to return TempError. ### Does exceeding ten SPF lookups cause TempError? No. RFC 7208 requires SPF PermError when SPF evaluation exceeds the DNS-querying-term limit. A slow lookup chain can still produce TempError if it reaches a receiver's overall processing time limit. ### Will retrying the message fix SPF TempError? Only sometimes. TempError indicates that a later evaluation may succeed, but the result depends on whether the underlying DNS or network condition has cleared and on the receiver's own retry and evaluation behavior. ### Does DMARC fix SPF TempError? No. DMARC uses SPF and DKIM results. It does not repair the DNS or processing problem that stopped SPF evaluation. A DKIM-aligned pass may still allow DMARC to pass when SPF returns TempError, depending on the message and DMARC alignment. --- # SSL vs TLS: what's the difference for email? Canonical: https://www.palisade.email/learning/ssl-vs-tls-whats-the-difference > SSL vs TLS for email: TLS is the modern protocol for SMTP encryption, while SSL is obsolete. Learn how to configure and validate TLS for email. SSL and TLS both describe encrypted network connections, but TLS is the current protocol and SSL is obsolete. For email, SMTP servers use TLS to encrypt a connection between mail systems or between a mail client and its submission server. TLS protects a transport hop. It does not authenticate the visible sender or provide end-to-end encryption of a message. ## Quick takeaways - SSL 2.0 and SSL 3.0 are obsolete protocols and should not be enabled for email services. - TLS 1.0 and TLS 1.1 are deprecated by [RFC 8996](https://datatracker.ietf.org/doc/html/rfc8996). - TLS 1.2 and TLS 1.3 are the current baseline versions for secure email transport. - SMTP can upgrade an existing connection to TLS with the `STARTTLS` command defined in [RFC 3207](https://datatracker.ietf.org/doc/html/rfc3207). - Opportunistic SMTP TLS does not require every sender to encrypt delivery to your domain. - MTA-STS can tell supporting sending servers to require authenticated TLS before delivering mail to your domain. ## Who is affected? This distinction affects any team operating an SMTP submission service, mail server, secure mail gateway, or application that sends email through SMTP. It also affects administrators publishing email transport controls for a domain. TLS is relevant in two different paths: - A mail client or application connects to its outbound submission service. - One SMTP server transfers a message to another SMTP server. The two paths have different operational controls. A submission service can require TLS from its users. Internet mail delivery has historically used opportunistic TLS, where a server can continue delivery without TLS when the receiving side does not advertise or complete the upgrade. TLS also has limits. It encrypts one network connection at a time. A message can be decrypted when a receiving mail server accepts it, then encrypted again on a later connection. TLS does not establish whether the visible `From` domain is authorized. That is a separate email-authentication task covered by SPF, DKIM, and DMARC. For related transport controls and records, use the [email transport security learning hub](/learning/infrastructure). ## What are the requirements? ### TLS 1.0 and TLS 1.1 must not be used [RFC 8996](https://datatracker.ietf.org/doc/html/rfc8996) formally deprecates TLS 1.0 and TLS 1.1. The RFC states that implementations "MUST NOT negotiate TLS version 1.0" and "MUST NOT negotiate TLS version 1.1." For new and maintained email services, disable SSL 2.0, SSL 3.0, TLS 1.0, and TLS 1.1. Support TLS 1.2, then enable TLS 1.3 where the mail software and operational dependencies support it. [RFC 9325](https://datatracker.ietf.org/doc/html/rfc9325) gives current TLS deployment guidance and recommends TLS 1.3. ```text Supported protocol baseline for a maintained SMTP service TLS 1.2: enabled TLS 1.3: enabled where supported TLS 1.1: disabled TLS 1.0: disabled SSL 3.0: disabled SSL 2.0: disabled ``` The label "SSL certificate" remains common, but it does not mean an endpoint should permit SSL. X.509 certificates can authenticate a TLS server. The protocol version is negotiated separately. ### SMTP uses STARTTLS to upgrade a connection [RFC 3207](https://datatracker.ietf.org/doc/html/rfc3207) defines the SMTP `STARTTLS` extension. An SMTP server that offers the extension advertises it in response to `EHLO`. The client then sends `STARTTLS` and begins the TLS handshake if the server accepts it. ```text S: 250-example.net S: 250-STARTTLS S: 250 SIZE 52428800 C: STARTTLS S: 220 Ready to start TLS ``` After a successful TLS negotiation, RFC 3207 requires the client to issue `EHLO` again. SMTP capabilities available before TLS are not assumed to remain available after the secure channel begins. `STARTTLS` is often opportunistic for server-to-server delivery. RFC 3207 allows a sending server to proceed without TLS when the receiving server does not offer it. That behavior improves encryption coverage, but it does not guarantee encryption for every delivery attempt. ![Email TLS decision flow showing STARTTLS negotiation and the extra policy check needed to require encrypted SMTP delivery](/images/editorial/ssl-vs-tls-whats-the-difference/ssl-vs-tls-email-transport-flow.webp "1200x829") *Source: Palisade.* ### MTA-STS can require authenticated TLS for a domain [RFC 8461](https://datatracker.ietf.org/doc/html/rfc8461) defines SMTP MTA Strict Transport Security, known as MTA-STS. A domain can publish an MTA-STS DNS record and host an HTTPS policy. A sending server that supports and successfully retrieves the policy can require TLS and validate the receiving server's certificate before delivery. An illustrative MTA-STS DNS record has this shape: ```text Illustrative only. Publish the version and identifier generated for your domain. _mta-sts.yourdomain.com. IN TXT "v=STSv1; id=20260811T120000" ``` > Do not publish a copied policy identifier or MX hostname from another organization. Your policy must name the receiving MX hosts for your own domain. MTA-STS is a domain-level control for inbound SMTP delivery. It does not turn every sender on the internet into an enforcing sender, and it does not secure submission traffic from your applications. A related [CNAME versus A record guide](/learning/cname-vs-a-record-whats-the-difference) can help when you are checking the DNS record type a provider asks you to publish. ## When does the requirement take effect? TLS 1.0 and TLS 1.1 were deprecated when RFC 8996 was published in March 2021. RFC 8996 updates RFC 5246 and RFC 4346, the specifications for TLS 1.2 and TLS 1.1 respectively. It is a final RFC, not an Internet-Draft. TLS 1.3 is specified by [RFC 8446](https://datatracker.ietf.org/doc/html/rfc8446), published in August 2018. RFC 8446 obsoletes RFC 5246 as the current TLS protocol specification. SMTP STARTTLS remains defined by RFC 3207, published in February 2002. MTA-STS is defined by RFC 8461, published in September 2018. These standards do not impose one universal migration deadline on every email domain. A mailbox provider, customer contract, or internal security policy can impose additional requirements with separate dates. ## How do I implement the requirement? ### 1. Inventory SMTP endpoints and dependencies List every SMTP submission endpoint, relay, gateway, appliance, printer, and application that sends through your mail environment. Record the hostname, port, supported TLS versions, certificate name, and whether the path is client submission or server-to-server delivery. Do not remove an old TLS version before identifying dependencies. A legacy device may stop sending when its only supported protocol is disabled. ### 2. Configure TLS 1.2 and TLS 1.3 Set each maintained SMTP service to permit TLS 1.2 and, where supported, TLS 1.3. Disable SSL 2.0, SSL 3.0, TLS 1.0, and TLS 1.1. Use a certificate whose presented hostname matches the hostname clients use. Confirm the service sends the full certificate chain required by its clients. RFC 9325 recommends current TLS configurations, but exact cipher and configuration settings depend on the SMTP software and operating system. ### 3. Confirm STARTTLS advertisement and policy Connect through the same hostname and port used in production, then inspect the `EHLO` response for `STARTTLS`. Test a real TLS negotiation and confirm the client sends a new `EHLO` after the upgrade. For inbound mail, decide whether opportunistic TLS is sufficient for the domain. If your domain needs supporting senders to require authenticated TLS, publish and maintain an MTA-STS policy under RFC 8461. Check DNS ownership and hostnames carefully. An incorrect policy can defer or prevent delivery from senders that enforce it. An [A record versus AAAA record guide](/learning/a-record-vs-aaaa-record-whats-the-difference) can help when a mail hostname resolves differently over IPv4 and IPv6. ### 4. Separate transport encryption from sender authentication Keep TLS configuration work separate from DMARC deployment. TLS encrypts the SMTP connection. SPF, DKIM, and DMARC evaluate sender authorization and alignment. A TLS-protected message can still fail DMARC, and a DMARC-aligned message can still cross an SMTP hop without enforced TLS. Both controls matter, but their evidence is different. ## How do I validate compliance? Start with DNS evidence. Query the MTA-STS TXT record from authoritative DNS and at least one public resolver, then retrieve the HTTPS policy URL specified by RFC 8461. Verify that the policy version, mode, maximum age, and MX patterns match the receiving infrastructure. Next, test the server path. Use an SMTP client or mail-server diagnostic that connects to the same hostname and port as the production sender. Confirm the offered protocol versions, certificate chain, certificate hostname, and `STARTTLS` negotiation. A public DNS check cannot prove that every SMTP endpoint presents the expected certificate or accepts the expected protocol version. Then send a real message through the production path and inspect its raw headers or mail-server logs. Record whether the actual submission or delivery connection used TLS. A successful test from one location does not prove that all sending applications, relays, or recipient paths behave the same way. Finally, validate the authentication layer after reports accumulate. DMARC aggregate reports can identify sources that are sending as the domain and show SPF or DKIM alignment outcomes. That evidence does not prove the TLS status of every SMTP hop. The [active versus passive monitoring guide](/learning/active-vs-passive-monitoring-whats-the-difference) explains why a point-in-time test and ongoing operational evidence answer different questions. ## Check the MTA-STS record before enforcing transport policy If you have a domain name and need to inspect its public MTA-STS DNS record, use the [MTA-STS checker](/tools/mta-sts) before changing your policy. Compare the result with the HTTPS policy and the SMTP certificate presented by your production MX hosts. [Check the MTA-STS record](/tools/mta-sts) A public record check cannot prove a specific SMTP delivery used TLS, validate every production mail path, or show a receiver's private enforcement decision. Once transport controls are in place, Palisade can analyze DMARC aggregate-report data, identify sending sources and alignment issues, and create prioritized remediation tickets. It does not change your MTA-STS policy or SMTP configuration for you. For an ongoing DMARC workflow across domains, [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=email_authentication&utm_content=ssl-vs-tls-whats-the-difference). ## Sources and further reading - [RFC 8996: Deprecating TLS 1.0 and TLS 1.1](https://datatracker.ietf.org/doc/html/rfc8996) - [RFC 8446: The Transport Layer Security Protocol Version 1.3](https://datatracker.ietf.org/doc/html/rfc8446) - [RFC 3207: SMTP Service Extension for Secure SMTP over Transport Layer Security](https://datatracker.ietf.org/doc/html/rfc3207) - [RFC 8461: SMTP MTA Strict Transport Security](https://datatracker.ietf.org/doc/html/rfc8461) - [RFC 9325: Recommendations for Secure Use of Transport Layer Security](https://datatracker.ietf.org/doc/html/rfc9325) ## Frequently asked questions ### Is SSL the same as TLS? No. TLS replaced SSL. "SSL" often remains in product labels and certificate terminology, but an actively maintained email service should negotiate TLS rather than SSL. ### Is TLS 1.2 still acceptable for email? Yes. TLS 1.2 remains a current protocol version. TLS 1.3 is the newer standard and is preferred where the mail software and connected systems support it. ### Does STARTTLS guarantee that email is encrypted? No. SMTP STARTTLS can be opportunistic, so a sender may deliver without TLS when it cannot negotiate the upgrade. MTA-STS can require authenticated TLS for supporting senders that retrieve and apply the policy. ### Does MTA-STS replace DMARC? No. MTA-STS addresses TLS protection for SMTP delivery to a domain. DMARC evaluates whether SPF or DKIM aligns with the visible `From` domain and tells receivers how to handle failures. ### Does TLS encrypt an email end to end? No. TLS encrypts a connection between two systems. Mail can be decrypted at a receiving server and encrypted again on a later hop. End-to-end message confidentiality requires a separate message-level encryption design. --- # What are the 3 types of email impersonation attacks? Canonical: https://www.palisade.email/learning/what-are-the-3-types-of-dangerous-email-impersonation-attacks-you-should-beware-of > Email impersonation attacks commonly use an exact domain, a lookalike domain, or a free-mail account. Learn how each type works. Learn what to verify. The three common types of email impersonation attacks are exact-domain spoofing, lookalike-domain impersonation, and free-mail impersonation. Exact-domain spoofing falsely uses a real organization's domain. Lookalike-domain attacks use a similar but separate domain. Free-mail attacks use an account from a legitimate provider while copying a trusted name. DMARC can help domain owners protect their own domain, but it cannot stop every lookalike or free-mail message. ## Quick takeaways - Exact-domain spoofing attempts to send mail that appears to use a legitimate domain without authorization. - Lookalike-domain impersonation uses a separately registered domain that resembles a trusted one. - Free-mail impersonation uses an address from a legitimate provider, often with a misleading display name. - DMARC evaluates whether SPF or DKIM authenticates and aligns with the visible From domain. - A message that passes its own provider's checks can still be an impersonation attempt if it uses a different domain. - Unusual payment, payroll, credential, or bank-detail requests need independent verification through a known channel. ## How the three email impersonation attack types work The three labels describe the sender identity an attacker puts in front of the recipient. They are useful for deciding what evidence to inspect and which controls can help. ### Exact-domain spoofing Exact-domain spoofing uses the organization's real domain in the visible From address. For example, an attacker might try to send a message that appears to be from `finance@yourdomain.com` without using an authorized sending service. [DMARC in RFC 9989](https://datatracker.ietf.org/doc/html/rfc9989) checks whether SPF or DKIM passes with an identifier aligned to the visible From domain. A domain owner can publish a DMARC policy requesting how receivers handle messages that fail this validation. A receiver still makes its own final delivery decision. This is the category where the domain owner has the most direct control. A domain with a properly deployed DMARC policy can make unauthorized use of its exact domain harder to accept at receiving systems. For the broader security context, see the [Palisade email security learning hub](/learning). ### Lookalike-domain impersonation Lookalike-domain impersonation uses a different domain that resembles a real one. The attacker may alter a character, add a word, substitute a similar-looking character, or use a domain that suggests a supplier or executive relationship. For example, `yourdoma1n.com` is separate from `yourdomain.com`, even if a recipient reads it as familiar. Microsoft describes spoofing as a message that uses a forged sender address or display name to make the sender appear to be someone else in its [spoof intelligence documentation](https://learn.microsoft.com/en-us/defender-office-365/anti-phishing-protection-spoofing-about). DMARC for `yourdomain.com` cannot control a DMARC record published by the owner of `yourdoma1n.com`. That message may authenticate for the attacker's separate domain. The practical check is the actual address and domain, not only the display name. ### Free-mail impersonation Free-mail impersonation uses an account from a legitimate email provider, such as an address created through a public mail service. The attacker may set a display name that matches an executive, colleague, customer, or vendor. The sending provider can authenticate the message for the attacker's free-mail account. That does not establish that the sender is the person named in the display name or that a payment request is genuine. The [Cybersecurity and Infrastructure Security Agency's business email compromise guidance](https://www.cisa.gov/topics/cyber-threats-and-advisories/malware-phishing-and-ransomware) recommends verifying requests to change payment information or transfer funds through a known phone number or in-person contact. ![Decision flow for classifying an impersonation message by the domain shown in its sender address](/images/editorial/what-are-the-3-types-of-dangerous-email-impersonation-attacks-you-should-beware-of/what-are-the-3-types-of-dangerous-email-impersonation-attacks-you-should-beware-of-attack-types.webp "1200x676") *Source: Palisade.* ## When the answer changes These categories can overlap. A message can use a copied display name and a lookalike domain at the same time. It can also use a compromised legitimate mailbox rather than a newly created address. In that case, the visible sender may be genuine, while the request or message content is unsafe. Use this decision rule: - If the visible From domain exactly matches the domain being protected, investigate whether the message has an aligned SPF or DKIM pass and whether the domain's DMARC policy applies. - If the visible From domain is similar but different, treat it as a separate-domain impersonation issue. Compare every character in the domain and verify the request outside email. - If the visible From address belongs to a public mail provider but claims to be a business contact, verify the relationship and request through a known contact method. - If the message came from a known address but requests an unusual action, do not assume authentication proves the request is authorized. Escalate through the organization's payment or incident process. A passing authentication result answers a narrower question: whether the sending system authenticated for a domain and met the relevant alignment test. It does not prove the sender's business identity, the safety of a linked destination, or the legitimacy of a financial request. [What is phishing?](/learning/what-is-phishing) covers the wider set of techniques used to obtain credentials, money, or sensitive information. ## A worked sender-identity example A recipient should compare the display name, visible From address, and authentication result. The following is illustrative only. Do not treat it as a complete message header or publish unredacted production headers. ```text Display name: Jordan Lee, Finance From: Jordan Lee <finance@yourdoma1n.com> Authentication-Results: mx.receiver.example; dkim=pass header.d=yourdoma1n.com; dmarc=pass header.from=yourdoma1n.com ``` This example can pass DMARC for `yourdoma1n.com` because the DKIM domain and visible From domain align. It still does not authenticate as `yourdomain.com`. [RFC 8601 defines the Authentication-Results header field](https://www.rfc-editor.org/rfc/rfc8601.html) for recording message authentication assessments. When an operator has a delivered message, its raw headers are stronger evidence than the display name alone. Compare the `header.from` value with the exact domain the business expects to use. For an exact-domain claim, a different result might look like this: ```text Display name: Jordan Lee, Finance From: Jordan Lee <finance@yourdomain.com> Authentication-Results: mx.receiver.example; spf=fail smtp.mailfrom=unrelated.example; dkim=fail; dmarc=fail header.from=yourdomain.com ``` The second example indicates an authentication failure for the visible From domain. The receiver's final handling still depends on its local policy and the DMARC policy it discovers. ## What to do with the evidence you have If you only have a suspicious message, inspect the full sender address, preserve the message, and use your organization's incident-reporting process. Verify sensitive requests through a phone number or contact record you already know, not a number supplied in the email. If you administer the domain used in an exact-domain attempt, inspect the public DMARC record and compare it with the intended policy. [Palisade's DMARC checker](/tools/dmarc) accepts a domain name and shows the public record it can find. It cannot inspect a particular message or identify whether a lookalike domain is affiliated with your organization. If you have raw message headers, compare the visible From domain with the `Authentication-Results` values. A DMARC result can help distinguish an exact-domain authentication failure from a message that authenticated for a separate lookalike domain. For ongoing domain protection, review DMARC aggregate reports to identify legitimate sending sources, authentication failures, and alignment issues before raising the policy. [What is an impersonation attack and how can you stop it?](/learning/what-is-an-impersonation-attack-and-how-can-you-stop-it) explains broader prevention measures beyond a single sender check. ## Inspect the DMARC record behind an exact-domain attempt If a suspicious message claims to be from your own domain, check the public DMARC record before changing DNS. Compare the lookup with the delivered message's authentication results and with the sending sources your organization has approved. [Check the DMARC record](/tools/dmarc) A public-record check cannot prove why a particular receiver accepted a message, identify a separate lookalike domain, or show whether every production sender is aligned. Once reports accumulate, Palisade is agentic DMARC software that analyzes DMARC aggregate-report data, identifies sending sources and authentication or alignment issues, and creates prioritized remediation tickets. It can propose the next policy step based on the evidence, while a human reviews the evidence and applies any DNS change. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=existing-content-migration&utm_content=what-are-the-3-types-of-dangerous-email-impersonation-attacks-you-should-beware-of) Palisade does not control a receiver's private delivery decision, block every lookalike domain, or prove that future messages will authenticate. For a provider-specific implementation of these authentication checks, see [What is email impersonation and how can you prevent it in 2025?](/learning/what-is-email-impersonation-and-how-can-you-prevent-it-in-2025). ## Sources and further reading - [RFC 9989: Domain-based Message Authentication, Reporting, and Conformance](https://datatracker.ietf.org/doc/html/rfc9989) - [RFC 8601: Message Header Field for Indicating Message Authentication Status](https://www.rfc-editor.org/rfc/rfc8601.html) - [Microsoft Defender for Office 365 spoof intelligence](https://learn.microsoft.com/en-us/defender-office-365/anti-phishing-protection-spoofing-about) - [CISA business email compromise guidance](https://www.cisa.gov/topics/cyber-threats-and-advisories/malware-phishing-and-ransomware) ## Frequently asked questions ### Can DMARC stop lookalike-domain attacks? No. DMARC for your domain governs messages that use your domain in the visible From address. A lookalike domain is a separate domain with its own DNS and authentication configuration. ### Is a free-mail address always malicious? No. Many legitimate people and small businesses use public email providers. Treat an unexpected request, misleading display name, or unusual payment instruction as a reason to verify the sender independently. ### Does a DMARC pass prove an email is safe? No. A DMARC pass shows that SPF or DKIM authenticated and aligned with the visible From domain under the applicable evaluation. It does not prove the sender's real-world identity or the safety of the requested action. ### What should an employee do after receiving a suspected impersonation email? Preserve the message and report it through the organization's security process. Verify any payment, payroll, credential, or bank-detail request through a known phone number or established contact channel. ### Which impersonation type can a domain owner address with DMARC? Exact-domain spoofing. DMARC lets the owner publish handling preferences for messages that fail DMARC while using the owner's visible From domain. It does not give the owner control over unrelated domains or public-mail accounts. --- # What are the key elements of DMARC syntax? Canonical: https://www.palisade.email/learning/what-are-the-key-elements-of-dmarc-syntax-and-how-do-you-implement-them-correctly > DMARC syntax uses DNS tags such as v, p, rua, adkim, and aspf to publish a policy, request reports, set alignment, and prepare your domain for enforcement. DMARC syntax is a semicolon-separated set of tag-value pairs in one DNS TXT record at `_dmarc.yourdomain.com`. The one required tag is `v=DMARC1`, and it must come first. A policy tag such as `p=none`, `p=quarantine`, or `p=reject` conventionally follows it. Other tags request aggregate reports, set alignment preferences, or define subdomain handling. Correct syntax publishes a policy. It does not prove that every production sender passes DMARC. ## Quick takeaways - A DMARC record is a DNS TXT record published at `_dmarc.yourdomain.com`. - `v=DMARC1` identifies the record as a DMARC record and appears first. - `p` states the requested handling for messages that fail DMARC. - `rua` requests aggregate DMARC reports at one or more reporting destinations. - `adkim` and `aspf` set DKIM and SPF alignment modes. - A valid DNS record still needs delivered-message and aggregate-report validation. ## How DMARC syntax works [DMARC is specified in RFC 9989](https://datatracker.ietf.org/doc/html/rfc9989) as a DNS-based policy and reporting mechanism. Its record is made of tags in the form `name=value`, separated by semicolons. Receivers use the record only after evaluating DMARC authentication and identifier alignment for the visible From domain. The two tags that establish the record are: - `v=DMARC1`: Identifies the DMARC version. Put this tag first. - `p=`: States the requested policy for the organizational domain after DMARC failure. Valid policy values are `none`, `quarantine`, and `reject`. A common monitoring record is: ```text v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com ``` `p=none` does not request enforcement action for DMARC failures. It can still request aggregate reports through `rua`, which helps a domain owner identify legitimate and unauthorized sources before considering a stronger policy. `p=quarantine` asks a receiver to treat failing mail as suspicious. `p=reject` asks a receiver not to accept failing mail. The receiving system retains its own local handling decision, so a published policy is not proof of one receiver's action on one message. For a wider protocol overview, visit the [Palisade learning center](/learning). ## When the syntax changes A short record can be valid, but the right tags depend on what the domain needs to express. Use `sp` when subdomains need a policy distinct from the organizational domain. If a visible From address uses `alerts.yourdomain.com`, inspect the policy discovery for that exact domain before assuming the root-domain record is the only relevant record. Use `rua` when your team needs aggregate reports. The destination must be a valid reporting URI, commonly a `mailto:` address. A reporting address on another domain can require external reporting authorization under the DMARC specification. Use `adkim` and `aspf` when you need to state alignment preferences: - `adkim=r` or `adkim=s` controls relaxed or strict DKIM alignment. - `aspf=r` or `aspf=s` controls relaxed or strict SPF alignment. Absent alignment tags use the protocol defaults. Strict alignment can change the result for legitimate services that use related, but not identical, domains. Confirm the actual From domain and authentication identifiers in a delivered production message before tightening alignment. > Do not move to `p=quarantine` or `p=reject` based only on a syntactically valid record. A sender can pass SPF or DKIM and still fail DMARC if the passing identifier does not align with the visible From domain. RFC 9989 identifies the older `pct` tag as historic. Do not depend on it as the basis for a current policy rollout. Use aggregate-report evidence and same-path message tests to decide when a stronger policy is appropriate. ## Worked DMARC syntax example The following is illustrative only. Do not copy the reporting address into production unless your team owns and operates it. ```text v=DMARC1; p=quarantine; sp=reject; rua=mailto:dmarc-reports@yourdomain.com; adkim=s; aspf=s ``` This example has these elements: - `v=DMARC1` identifies the record. - `p=quarantine` requests suspicious treatment for DMARC failures using the organizational domain. - `sp=reject` requests a different policy for subdomains. - `rua=mailto:dmarc-reports@yourdomain.com` requests aggregate reports. - `adkim=s` requests strict DKIM alignment. - `aspf=s` requests strict SPF alignment. Publish one valid DMARC record at the required hostname. Multiple DMARC records at the same policy domain can make policy discovery fail under the specification. Keep all intended tags in a single record. ![Example DMARC TXT record showing the version and policy tags plus reporting, subdomain, and alignment options](/images/editorial/what-are-the-key-elements-of-dmarc-syntax-and-how-do-you-implement-them-correctly/what-are-the-key-elements-of-dmarc-syntax-and-how-do-you-implement-them-correctly-syntax-record.webp "1200x400") *Source: Palisade.* ## What to check after publishing the record Start with the evidence you have. If you have a domain name and need to inspect public DNS, use the [DMARC checker](/tools/dmarc) to look up the published record. Confirm the hostname, the tag order, and whether the returned record matches the approved DNS change. If you need other public DNS checks, review [Palisade's email security tools](/tools). If you control DNS, query the authoritative DNS service and at least one public resolver after publishing. DNS visibility confirms that the record is available. It does not show that a mailing platform signs messages correctly or uses the intended envelope sender. If you have a delivered production message, inspect its raw headers. The `Authentication-Results` header can show the receiver's recorded SPF, DKIM, and DMARC evaluation for that message. Compare the visible From domain with the domains that passed SPF or DKIM. If aggregate reports have started to arrive, use them to identify sources and failure patterns over time. That is the DMARC layer of validation. It is separate from DNS publication, a vendor's configuration screen, and a single delivered message. ## Check the DMARC syntax your domain publishes A public lookup is the right next step when you need to confirm the record currently visible in DNS. Check the actual TXT record before changing policy, then compare it with the DNS value your team approved. [Check the published DMARC record](/tools/dmarc) A public-record check cannot prove that a mailing application is signing production mail, that every legitimate sender aligns, or how a specific receiver will place a future message. When ongoing aggregate reports reveal unidentified senders or recurring alignment failures, [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=email_authentication&utm_content=what-are-the-key-elements-of-dmarc-syntax-and-how-do-you-implement-them-correctly). Palisade analyzes DMARC aggregate-report data, identifies sources and alignment issues, and proposes prioritized remediation work. A human still reviews the evidence and applies any DNS or policy change. ## Sources and further reading - [RFC 9989: Domain-based Message Authentication, Reporting, and Conformance](https://datatracker.ietf.org/doc/html/rfc9989) - [RFC 8601: Message Header Field for Indicating Message Authentication Status](https://www.rfc-editor.org/rfc/rfc8601.html) - [Palisade DMARC checker](/tools/dmarc) - [Palisade learning center](/learning) ## Frequently asked questions ### Does every DMARC record need `rua`? No. The `rua` tag is optional in the DMARC record syntax. It requests aggregate reports, which are useful when a domain owner needs evidence about sending sources and DMARC outcomes before changing policy. ### Does `p=reject` guarantee that mail will be rejected? No. `p=reject` is a domain owner's requested DMARC failure policy. A receiving system makes the final handling decision according to its own local policy and message evaluation. ### Can I put a DMARC record at the root domain? No. The DMARC policy record is published at a hostname beginning with `_dmarc`, such as `_dmarc.yourdomain.com`. A TXT record at `yourdomain.com` is not the DMARC policy record for that domain. ### Is `adkim=s` always the right choice? No. Strict DKIM alignment requires the authenticated DKIM domain to exactly match the visible From domain. Check real messages from each production sender before requesting strict alignment. ### Does a passing DMARC checker result prove email delivery? No. A checker can confirm the public DNS record it retrieves. It cannot prove that a specific production message authenticated, that a receiver accepted it, or that future messages will reach the inbox. --- # What are the top email security tips for small businesses? Canonical: https://www.palisade.email/learning/what-are-the-top-email-security-tips-for-small-businesses > Email security tips for small businesses: use MFA, verify sensitive requests, authenticate sending domains, and test recovery paths safely today. The top email security tips for small businesses are to require multi-factor authentication, verify sensitive requests outside the email thread, restrict mailbox and DNS access, authenticate every sending domain, and maintain a recovery process. These controls address different risks. A protected mailbox does not prove that an invoice request is genuine, and a published DMARC record does not prove that every application sending mail for the business is authenticated. ## Quick takeaways - Require multi-factor authentication for mailboxes, administrator accounts, and recovery accounts. - Verify payment, payroll, bank-detail, and credential requests through a trusted channel outside the suspicious email. - Limit access to mailboxes, forwarding rules, DNS, domain registration, and billing settings. - Publish SPF, DKIM, and DMARC for every domain that sends business email. - Test a real message from each important production sender after changing authentication settings. - Keep recovery contacts and DNS rollback details available outside the normal email system. ## How small-business email security works Small-business email security has four connected layers: account access, message handling, sending-domain authentication, and recovery. Account protection reduces the chance that a stolen password becomes mailbox access. The [Cybersecurity and Infrastructure Security Agency's guidance on phishing-resistant MFA](https://www.cisa.gov/sites/default/files/publications/fact-sheet-implementing-phishing-resistant-mfa-508c.pdf) recommends MFA because an additional authentication factor makes a password alone less useful to an attacker. Apply it to regular mailboxes, shared-mailbox administrators, domain registrar accounts, and DNS-provider accounts. Message handling protects high-consequence actions. A display name, reply-to address, or familiar signature is not enough evidence to approve a payment or change bank details. [CISA's business email compromise guidance](https://www.cisa.gov/topics/cyber-threats-and-advisories/malware-phishing-and-ransomware) advises organizations to verify payment requests through a separate, trusted communication channel. Use a phone number from an approved directory, an existing vendor portal, or an established contact record. Do not use a phone number or reply address supplied in the suspicious message. Sending-domain authentication helps receiving systems evaluate mail that uses the business's visible From domain. [RFC 9989 defines DMARC](https://www.rfc-editor.org/rfc/rfc9989.html) as a mechanism built on SPF and DKIM authentication with identifier alignment. SPF, DKIM, and DMARC are related but distinct controls: - SPF authorizes sending infrastructure through DNS, but its authenticated domain must align with the visible From domain for SPF to support DMARC. - DKIM adds a cryptographic signature that a receiver can validate. Its signing domain must align with the visible From domain for DKIM to support DMARC. - DMARC tells receivers how to handle mail that fails DMARC validation and can request aggregate reports. The [email threats learning hub](/learning/threats) covers authentication and delivery controls in more detail, and [what an email security gateway is](/learning/email-security-gateway) explains where a dedicated inbound product fits alongside these controls. ## When the priority changes The first action should follow the evidence in front of you. If a person receives a suspicious request to send money, disclose credentials, alter payroll, or update bank information, pause the action and verify it outside email. Preserve the message for review. Do not begin with a DNS change or assume a familiar display name proves identity. If a mailbox may be compromised, review more than its password. Check mailbox forwarding rules, delegated access, recovery methods, active sessions, administrator roles, and recent configuration changes. An attacker who created a forwarding rule or added a recovery method may retain access after a password reset. If the business adds a marketing platform, invoicing system, support desk, or transactional application, treat it as a sending-domain change. Record the service owner, the visible From domain, the authentication records it requires, and the test message that will confirm the live path. If a domain has no DMARC record, first inventory its legitimate senders. A stronger DMARC policy before that inventory is complete can disrupt valid mail that has not yet achieved SPF or DKIM alignment. RFC 9989 gives receivers the final decision on local handling, so a published policy is not proof of one receiver's final delivery decision. Use this decision rule: protect the action with the greatest immediate consequence, then gather evidence before changing the control that governs it. ## A worked small-business security review Use this checklist for one sending domain and the mailboxes associated with it. It is a starting point for a review, not proof that a message is safe or that every sender is configured correctly. ```text Small-business email security review Account access - List mailbox administrators, delegates, and recovery contacts. - Require multi-factor authentication for each account. - Remove unused users, recovery methods, and delegated access. Sensitive requests - Verify payment, payroll, bank-detail, and credential requests outside email. - Use a known phone number, contact directory, or vendor portal. - Review unexpected mailbox forwarding or recipient changes. Sending domain - List each application that sends with your domain in the visible From address. - Record the SPF, DKIM, and DMARC records each application requires. - Send a real message through each production path and inspect its headers. Recovery - Document contacts for the email provider, DNS provider, and registrar. - Retain the approved previous DNS record for rollback. - Review administrator access and forwarding rules after an incident. ``` ![Decision checklist showing when a small business should protect account access, verify a request, check sending-domain authentication, or use recovery procedures](/images/editorial/what-are-the-top-email-security-tips-for-small-businesses/what-are-the-top-email-security-tips-for-small-businesses-security-decision-checklist.webp "1200x582") *Source: Palisade.* Validate email authentication at four separate layers: - DNS: Confirm the intended records through the authoritative DNS provider and at least one public resolver. - Vendor: Confirm that the sending service reports the domain or sender configuration as verified. - Message: Send a real message from the exact production path and inspect its `Authentication-Results` header. [RFC 8601 defines this header field](https://www.rfc-editor.org/rfc/rfc8601.html). - DMARC: Review aggregate-report data after reports have accumulated. A green setting in a sending service does not prove that a delivered message was signed or aligned. A DNS lookup does not identify every production sender or reveal a receiving provider's private filtering decision. ## Take the next action based on the evidence you have For a suspicious request, use the known contact method before approving the action. For a possible mailbox compromise, review access, forwarding, recovery, and administrator settings before closing the incident. For a domain that sends business email, build the sender inventory first. Then run the domain through the [Palisade Email Security Score tool](/tools/email-security-score) to inspect its publicly visible email-security records. Compare the result with the DNS records your sending services require and with headers from real production messages. ## Check the public controls behind your sending domain Use the Email Security Score tool to inspect the public DNS controls associated with the business domain. This follows naturally after the sender inventory because it can reveal records that need closer review before you test each sending path. [Check your domain's email security score](/tools/email-security-score) A public check cannot prove that every application uses the domain correctly, repair a compromised mailbox, monitor later changes, or explain a receiver's private placement decision. If DMARC aggregate reports show recurring sending sources or alignment failures, Palisade is DMARC software that analyzes aggregate-report data, identifies sources and authentication or alignment issues, and creates prioritized remediation tickets. A human reviews the evidence and applies any DNS or DMARC policy change. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=security&utm_content=what-are-the-top-email-security-tips-for-small-businesses) Palisade does not autonomously change the DMARC policy, repair every sender, or guarantee that future messages will authenticate. ## Sources and further reading - [CISA fact sheet: implementing phishing-resistant MFA](https://www.cisa.gov/sites/default/files/publications/fact-sheet-implementing-phishing-resistant-mfa-508c.pdf) - [CISA: Business email compromise](https://www.cisa.gov/topics/cyber-threats-and-advisories/malware-phishing-and-ransomware) - [RFC 9989: Domain-based Email Authentication, Reporting, and Conformance](https://www.rfc-editor.org/rfc/rfc9989.html) - [RFC 8601: Authentication-Results header field](https://www.rfc-editor.org/rfc/rfc8601.html) - [Palisade Email Security Score tool](/tools/email-security-score) ## Frequently asked questions ### Is multi-factor authentication enough to secure a business mailbox? No. Multi-factor authentication reduces the risk from a stolen password, but it does not stop an authorized user from approving a fraudulent request or prevent a compromised administrator account from changing mailbox settings. ### Should a small business verify every invoice by phone? No. Apply an out-of-band verification process to unexpected, changed, or high-consequence requests, especially those involving payment instructions, payroll, credentials, or bank details. Use a known contact method rather than contact details supplied in the message. ### Does SPF alone protect a domain from impersonation? No. SPF can authenticate a sending path, but SPF alone does not provide DMARC protection for visible From-domain impersonation. DMARC requires an aligned SPF or DKIM pass and a published DMARC policy. ### Can a public email-security check prove that business email is safe? No. A public check can inspect published DNS records. It cannot prove that each application sends with the expected authentication, that a specific message passed DMARC, or that a receiver will place future mail in the inbox. ### When should a small business move to a stronger DMARC policy? Only after it has inventoried legitimate sending sources, validated aligned authentication on real production messages, and reviewed aggregate-report evidence for remaining failures. Keep an approved rollback record before changing DNS. --- # What exactly is spoofing and how can you stop it? Canonical: https://www.palisade.email/learning/what-exactly-is-spoofing-and-how-can-you-stop-it > Spoofing is impersonation that makes a message, call, website, or network request appear trusted. Learn how to identify and limit spoofing for your domain. Spoofing is an impersonation technique that makes a message, call, website, or network request appear to come from a trusted source. Attackers use it to make a request look familiar before trying to obtain credentials, money, information, or access. You stop spoofing with controls matched to the channel: verify unusual requests independently, protect DNS and network paths, and use SPF, DKIM, and DMARC to limit unauthorized use of your email domain. ## Quick takeaways - Spoofing falsifies or imitates an identity, address, or signal so a target trusts it. - Phishing is the deceptive request or lure, while spoofing is often the impersonation technique that makes that lure believable. - A familiar display name, logo, caller ID, or domain is not proof of identity. - Email authentication can help receivers identify mail that is not authorized to use a visible From domain. - DMARC does not stop look-alike domains, compromised accounts, fraudulent phone calls, or every phishing message. - The safest response to an unusual request is to verify it through a separate, known contact path. ## How spoofing works The [NIST glossary definition of spoofing](https://csrc.nist.gov/glossary/term/spoofing) describes it as falsifying data to make it appear to come from a trusted source. The falsified element depends on the channel. An attacker can imitate an email address, a website's appearance, a caller ID value, a DNS response, or an IP source address. Spoofing works because people and systems often use visible identifiers as shortcuts. A display name that says "Accounts payable" can look familiar even when the underlying email address is unrelated. A web page can copy a legitimate brand's colors and sign-in form while using a different domain. A caller ID can display a number that appears local or known. Phishing and spoofing overlap, but they are not identical. The [US Cybersecurity and Infrastructure Security Agency's phishing guidance](https://www.cisa.gov/topics/cyber-threats-and-advisories/malware-phishing-and-ransomware) describes phishing as deceptive messages intended to persuade recipients to take an action. Spoofing can support phishing by making the sender, site, or caller appear legitimate. Spoofing can also occur in network traffic without a phishing message. Email spoofing has a defined technical defense path. [RFC 9989](https://datatracker.ietf.org/doc/html/rfc9989) specifies DMARC, which evaluates whether SPF or DKIM passes with a domain aligned to the visible Header From domain. A DMARC policy lets a domain owner publish requested handling for messages that fail that evaluation. The receiving mail system still makes its own final delivery decision. For more detail on the controls involved, see the [email authentication learning hub](/learning). ## When the answer changes The right defense changes with the identity being impersonated and the evidence you have. - If the concern is a suspicious email, inspect the full sender address, destination URLs, and the delivered message's authentication results. Do not rely on the display name. - If the concern is a website, enter the known address yourself or use a saved bookmark. Check the complete domain before entering credentials. - If the concern is an unexpected call or text, end the interaction and contact the organization using a number or app you already know is legitimate. The [Federal Communications Commission's caller ID spoofing guidance](https://www.fcc.gov/spoofing) explains that caller ID information can be manipulated. - If the concern is a network request or DNS response, use network and DNS logs to investigate. A public email-authentication lookup cannot explain a packet-level or resolver-level incident. A useful decision rule is this: validate the identity through evidence that the alleged sender did not provide. For an email, that can include authentication headers and a separate contact channel. For a payment request, use the supplier contact record your organization already maintains. For a website, use a bookmarked domain or a trusted password manager entry. > Do not change a domain's DMARC policy solely because of one suspicious message. First determine whether the message used your domain, whether it failed DMARC, and whether legitimate production senders would be affected. ## A worked email spoofing example Suppose a message displays `Billing Team <billing@yourdomain.com>`. The display name and visible address can look valid, but the received message contains evidence that shows what the receiving system evaluated. ```text Authentication-Results: mx.example.net; spf=fail smtp.mailfrom=mailer.example-attacker.com; dkim=none; dmarc=fail header.from=yourdomain.com ``` This is an illustrative example, not a header from a real message. [RFC 8601](https://www.rfc-editor.org/rfc/rfc8601.html) defines the `Authentication-Results` header field used by message-handling systems to record authentication assessment results. In this example, SPF failed for the envelope sender, no DKIM result is present, and DMARC failed for `yourdomain.com`. That result supports a narrow conclusion: this receiver found no aligned SPF or DKIM pass for the visible From domain. It does not prove who sent the message, whether every receiver reached the same result, or whether the sender's account was compromised. ![Flow showing how a suspicious email is checked through the visible From domain, authentication results, and independent verification](/images/editorial/what-exactly-is-spoofing-and-how-can-you-stop-it/what-exactly-is-spoofing-and-how-can-you-stop-it-spoofing-check-flow.webp "1200x829") *Source: Palisade.* If your domain appears in the visible From address, collect the raw headers from a delivered copy and compare them with DMARC aggregate-report data once reports have accumulated. This distinguishes a public DNS record from the actual production message path. ## What to do next, based on the evidence Start with the evidence closest to the event. - For a suspicious request received by a person, do not reply, click, or use contact details in that request. Verify the request through a separate trusted channel. - For a suspicious website, preserve the URL and report it through your organization's security process. Change passwords only through the legitimate site's known address. - For mail that claims to be from your domain, save the raw headers and inspect `Authentication-Results`. Check whether SPF or DKIM authenticated with the visible From domain. - For a domain you manage, publish and maintain SPF and DKIM for authorized sources, then use DMARC reporting to identify sources and alignment failures before considering a stronger policy. The related guide on [stopping spoofing attacks](/learning/what-exactly-is-spoofing-and-how-can-you-stop-it) covers the email-focused response in more depth. - For network-address impersonation, investigate firewall, router, DNS, and application logs. [IP spoofing has separate network-level controls](/learning/how-does-ip-spoofing-work-and-how-can-you-stop-it). Validate an email-authentication change at four layers. Query authoritative DNS and a public resolver. Confirm the sending provider's current authentication status. Send a real message through the exact production path and inspect its raw headers. Then review DMARC aggregate reports after data accumulates. A DNS result alone does not prove that an application is signing mail or using the configured return path. ## Check the DMARC record behind email-domain spoofing If a suspicious message uses a domain your organization manages, inspect the published DMARC record before changing its policy. Compare the lookup with the raw message headers and the approved DNS configuration. [Check the domain's DMARC record](/tools/dmarc) A public DMARC lookup cannot prove why one receiver handled a message a certain way, identify a caller or website, or show every production sender that still fails alignment. Palisade is agentic DMARC software that analyzes DMARC aggregate-report data, identifies sending sources and authentication or alignment issues, and proposes prioritized remediation work. A human reviews the evidence and applies any DNS or policy change. When reports show recurring unknown sources or alignment failures across domains, [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=email_authentication&utm_content=what-exactly-is-spoofing-and-how-can-you-stop-it). ## Sources and further reading - [NIST Computer Security Resource Center glossary: spoofing](https://csrc.nist.gov/glossary/term/spoofing) - [CISA phishing guidance](https://www.cisa.gov/topics/cyber-threats-and-advisories/malware-phishing-and-ransomware) - [RFC 9989: Domain-based Message Authentication, Reporting, and Conformance](https://datatracker.ietf.org/doc/html/rfc9989) - [RFC 8601: Message Header Field for Indicating Message Authentication Status](https://www.rfc-editor.org/rfc/rfc8601.html) - [FCC caller ID spoofing guidance](https://www.fcc.gov/spoofing) ## Frequently asked questions ### Is spoofing the same as phishing? No. Spoofing is the imitation or falsification of an identity or source. Phishing is a deceptive attempt to persuade someone to take an unsafe action. A phishing email often uses spoofing, but a spoofed network address does not necessarily involve phishing. ### Can DMARC stop all email spoofing? No. DMARC helps receivers evaluate unauthorized use of the visible From domain when SPF or DKIM does not pass with alignment. It does not stop look-alike domains, compromised legitimate accounts, or every phishing message that uses another domain. ### Does a sender display name prove an email is legitimate? No. Display names are easy to copy. Inspect the complete sender address, raw message headers when available, and the request itself. Verify unusual payment, credential, or account-change requests through a separate known contact channel. ### Can a caller ID be spoofed? Yes. The FCC states that caller ID information can be manipulated. Treat an unexpected call as unverified, especially when it asks for a password, verification code, payment, or remote access. ### Can SPF alone prevent email spoofing? No. SPF checks the envelope sender against published authorization, while DMARC evaluates aligned SPF or DKIM against the visible Header From domain. A complete email-domain protection plan normally needs properly configured SPF, DKIM, and DMARC. --- # What is a CNAME record and how do DNS aliases work? Canonical: https://www.palisade.email/learning/what-is-a-cname-record > CNAME record explained: learn how DNS aliases work, why they cannot share a name, when email systems reject them, and how to validate a target. A CNAME record is a DNS record that makes one hostname an alias for another hostname. When a resolver queries the alias, DNS follows the CNAME target and looks up that target's records instead. CNAME records are useful for provider-managed email authentication, tracking, and branded hostnames, but the alias cannot share its name with other DNS records and an SMTP MX target must not be a CNAME. ## Quick takeaways - A CNAME maps one DNS hostname to a canonical hostname, not directly to an IP address. - A hostname with a CNAME must not have other DNS record data at that same name. - The zone apex usually cannot be a CNAME because it must publish SOA and NS records. - An MX record's target hostname must resolve to an address record and must not be a CNAME. - A CNAME can support provider-managed DKIM or branded-hostname setup, but DNS resolution alone does not prove production mail is authenticated. ## Who is affected? CNAME rules affect anyone who publishes DNS for a domain, including IT teams configuring email authentication, marketing teams connecting a sending platform, and MSPs maintaining customer zones. The CNAME owner name is the hostname being aliased. For example, `selector1._domainkey.yourdomain.com` can be the owner name of a CNAME. The canonical name is the hostname it points to, such as a provider-managed target. This distinction matters for email setup. A provider may ask you to publish a CNAME beneath your domain so it can maintain the target record. That can make a DKIM delegation or branded hostname easier to maintain, but it does not permit a CNAME everywhere. The scope is hostname-specific. A CNAME at `mail.yourdomain.com` does not make `yourdomain.com` an alias. The domain apex has mandatory zone data, including SOA and NS records, so the normal CNAME exclusivity rule prevents a standard CNAME there. Some DNS providers offer nonstandard alias-like features for apex use. Their behavior is provider-specific and is not a CNAME record defined by the DNS standards. For related DNS record types, see the [email authentication learning hub](/learning), the guide to [A records](/learning/what-is-an-a-record), and the guide to [TXT records](/learning/what-is-a-txt-record). ## What are the requirements? The controlling specification is [RFC 1034, Domain Names - Concepts and Facilities](https://datatracker.ietf.org/doc/html/rfc1034), an IETF Internet Standard. [RFC 2181, Clarifications to the DNS Specification](https://datatracker.ietf.org/doc/html/rfc2181), clarifies the CNAME coexistence rule. These RFCs define DNS behavior. A mail provider can still impose its own setup instructions for a particular service. ### A CNAME points to another hostname A CNAME record identifies its owner name as an alias for the canonical name in the record data. The target is a DNS name, not an IPv4 or IPv6 address. ```text ; Illustrative only. Publish the exact owner and target supplied for your domain. selector1._domainkey.yourdomain.com. 300 IN CNAME selector1.provider.example. ``` Do not publish example hostnames in a production zone. Your email provider generates the actual owner name and target for its service. A resolver that receives this CNAME continues resolution at `selector1.provider.example`. The final response may contain an A record, AAAA record, TXT record, or another record type appropriate to the original query. A CNAME does not copy the target's records into your zone. It delegates name resolution for that alias. ![CNAME record anatomy showing an alias hostname resolving through a canonical target](/images/editorial/what-is-a-cname-record/what-is-a-cname-record-anatomy.webp "1200x533") *Source: Palisade.* ### A CNAME owner must not have other data [RFC 1034 section 3.6.2](https://datatracker.ietf.org/doc/html/rfc1034#section-3.6.2) says that if a CNAME resource record is present at a node, no other data should be present. [RFC 2181 section 10.1](https://datatracker.ietf.org/doc/html/rfc2181#section-10.1) makes the operational consequence explicit: an alias must have no other data. That means this is invalid at one owner name: ```text mail.yourdomain.com. 300 IN CNAME mail.provider.example. mail.yourdomain.com. 300 IN TXT "some text" ``` Put the TXT record at a different hostname, or use the record design supplied by the provider. Do not add an SPF, DMARC, MX, or verification TXT record beside a CNAME just because a DNS control panel permits the entry. Authoritative DNS behavior and resolver handling can become inconsistent when a name violates the rule. ### An SMTP MX target must not be a CNAME An MX record names the host that accepts mail for a domain, and you can [look up a domain's MX records](/tools/mx) to see the exact hostnames it publishes. [RFC 5321 section 5.1](https://datatracker.ietf.org/doc/html/rfc5321#section-5.1) says that the domain name in an MX record must not be a CNAME. The mail exchanger hostname must resolve directly to an address record. ```text ; Illustrative only. yourdomain.com. 300 IN MX 10 mx1.yourdomain.com. mx1.yourdomain.com. 300 IN A 192.0.2.25 ``` Do not use this pattern: ```text ; Invalid MX target pattern. yourdomain.com. 300 IN MX 10 mx1.yourdomain.com. mx1.yourdomain.com. 300 IN CNAME mail.provider.example. ``` SMTP senders can treat an MX target that resolves through a CNAME as an error. This rule applies to the MX target, not to every hostname involved in email services. A DKIM selector or web tracking hostname may legitimately be a CNAME when the provider's instructions call for one. ### CNAME chains are DNS dependencies DNS permits a canonical name to lead to another alias, but each extra lookup adds another dependency. RFC 1034 describes following aliases while resolving a query, with protections against loops. Keep provider-created chains intact unless the provider documents a replacement. For names you control, prefer a short chain. A long chain can make DNS failures harder to isolate and can exceed resolver limits in some implementations. ## When does the requirement take effect? There is no future enforcement date for CNAME behavior. The rules apply whenever an authoritative DNS zone publishes a CNAME record or an SMTP sender resolves an MX target. RFC 1034 was published in November 1987 as an Internet Standard. RFC 2181 was published in July 1997 to clarify DNS behavior, including the rule that an alias cannot coexist with other data. RFC 2181 clarifies the CNAME rule rather than creating a vendor rollout date. For email routing, RFC 5321 is the controlling SMTP specification for MX handling. Its prohibition on an MX target that is a CNAME applies to SMTP implementations, regardless of whether a DNS interface accepts the record. ## How do I implement the requirement? ### 1. Identify the exact hostname the provider gave you Copy the record owner name and target from the provider's current DNS instructions. Confirm whether the request is for a CNAME, TXT, MX, or another type before editing the zone. A DKIM-related request often uses a hostname below `_domainkey`. It is separate from the root domain's DMARC hostname, `_dmarc.yourdomain.com`, which normally publishes a TXT record. ### 2. Check for existing records at the alias hostname Before adding the CNAME, inspect every record at that exact owner name. Remove or relocate conflicting records only after confirming what system depends on them. > Replacing an existing MX, TXT, or address record with a CNAME can interrupt mail routing, domain verification, or an application endpoint. Record the current values and confirm the intended change with the service owner before publishing it. ### 3. Publish the target exactly as supplied Use a fully qualified hostname target. Do not substitute an IP address, alter a provider-managed target, or add a CNAME at the domain apex as a workaround. The target may be outside your domain. That is normal for a vendor-managed DKIM delegation or branded sending hostname. The important DNS question is whether the target resolves as the provider expects. ### 4. Allow cached DNS data to expire Resolvers can keep an older response until its TTL expires. Check the authoritative zone first, then query public resolvers after the change has propagated through their caches. If a provider has a verification screen, check that status separately. A successful DNS lookup shows the record is publicly resolvable. It does not prove the provider has accepted it or that the production sending path uses it. ## How do I validate compliance? Start with the record itself. Query the alias hostname and confirm that the response is a CNAME with the intended target. Then query the target to see whether it resolves to the record type needed by the service. ![CNAME validation checklist covering DNS, vendor verification, message headers, and DMARC reports](/images/editorial/what-is-a-cname-record/what-is-a-cname-record-cname-validation-checklist.webp "1200x524") *Source: Palisade.* Use Palisade's [DNS lookup tool](/tools/dns-lookup) to inspect the published CNAME and its public resolution path. Compare the result with the provider's exact DNS instructions. For an email authentication CNAME, validate all applicable layers: - DNS: confirm the authoritative zone and at least one public resolver return the expected CNAME target. - Vendor: confirm the sending provider reports the domain or selector as verified, if it offers a verification status. - Message: send a real message through the production path and inspect its raw headers. Confirm the expected DKIM result and identifier appear in `Authentication-Results`. - DMARC: after reports accumulate, review aggregate-report data to identify whether the production sources authenticate and align as expected. A successful public DNS query does not prove that an application is signing mail, that a provider has activated the configuration, that all future messages will authenticate, or that a receiver will accept a message. For reverse-DNS checks related to sending IP addresses, use the separate guide to [PTR records](/learning/what-is-a-ptr-record). ## Inspect the CNAME before relying on it for email setup A CNAME lookup is the right next check when you have a hostname and need to confirm its public alias target. It can reveal a typo, a missing target, or a conflicting record before you treat provider setup as complete. [Inspect the CNAME target](/tools/dns-lookup) A public DNS lookup cannot prove which production sending sources still fail DKIM or DMARC alignment. Palisade is agentic DMARC software that analyzes DMARC aggregate-report data, identifies sending sources and authentication or alignment issues, and creates prioritized remediation tickets. It proposes the next policy step from the evidence, while a human reviews the evidence and applies the change. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=existing_content_migration&utm_content=what-is-a-cname-record) Palisade does not change your DMARC policy automatically, repair every sender, or guarantee future authentication or inbox placement. ## Sources and further reading - [RFC 1034: Domain Names - Concepts and Facilities](https://datatracker.ietf.org/doc/html/rfc1034) - [RFC 2181: Clarifications to the DNS Specification](https://datatracker.ietf.org/doc/html/rfc2181) - [RFC 5321: Simple Mail Transfer Protocol](https://datatracker.ietf.org/doc/html/rfc5321) ## Frequently asked questions ### Can a CNAME point to an IP address? No. A CNAME points to another hostname. Use an A record for an IPv4 address or an AAAA record for an IPv6 address. ### Can a CNAME and a TXT record use the same hostname? No. A hostname that has a CNAME must not have other DNS record data at that same name. Put the TXT record at a different owner name. ### Can an MX record point to a CNAME? No. RFC 5321 says an MX target must not be a CNAME. The target hostname must resolve directly to an address record. ### Can I use a CNAME at my root domain? Not as a standard DNS CNAME. The domain apex must publish SOA and NS records, which conflicts with the requirement that a CNAME owner have no other data. A DNS provider may offer an alias-like apex feature, but that is provider-specific behavior. ### Does a CNAME prove that DKIM is working? No. A CNAME lookup can prove that the published alias resolves as expected. It does not prove that the provider has enabled signing or that a real production message contains a valid DKIM signature. --- # What is a TXT record? DNS text records explained Canonical: https://www.palisade.email/learning/what-is-a-txt-record > TXT records store DNS text used for SPF, DKIM, DMARC, verification, and other domain policies. Learn their format, limits, validation, and uses. A TXT record is a DNS record that publishes one or more character strings at a domain name. Email systems use DNS TXT records to find SPF authorization policies, DKIM public keys, and DMARC policies. Domain owners also use them to prove control of a domain to services. The record type is defined by [RFC 1035](https://www.rfc-editor.org/rfc/rfc1035), while each protocol defines how it uses the text. ## Quick takeaways - A DNS TXT record associates text with a DNS owner name. - The owner name identifies the record's job, such as `_dmarc.yourdomain.com` for DMARC. - One TXT character-string is limited to 255 octets, but one TXT record can contain multiple character-strings. - SPF, DKIM, DMARC, and domain-verification values can coexist when their names and protocol rules permit it. - A public DNS lookup shows what is published now. It does not prove that a production sender is using the intended configuration. ## Who is affected? TXT records affect anyone who controls DNS for a domain and needs another system to read domain metadata. That includes IT teams publishing email-authentication records, administrators verifying a domain with a SaaS provider, and MSPs maintaining DNS for several customer domains. For email authentication, the record name determines which system queries it: - SPF is normally published as a TXT record at the domain used in the SMTP `MAIL FROM` identity. - DKIM public-key information is published below a selector name, such as `selector1._domainkey.yourdomain.com`. - DMARC is published at `_dmarc.yourdomain.com`. - Domain-verification services commonly provide a unique name or value to publish as TXT. These uses do not make every TXT record an email record. DNS permits TXT records for general text data. The consumer of the record decides whether a value has meaning and whether its syntax is valid. A TXT record also differs from a DNS alias. A [CNAME record](/learning/what-is-a-cname-record) points one DNS name to another canonical name. A TXT record contains text returned directly in the DNS response. ## What are the requirements? ### A TXT record contains one or more character-strings RFC 1035 defines TXT RDATA as one or more character-strings. Each individual string starts with a length octet, so it can hold no more than 255 octets. ```text yourdomain.com. 3600 IN TXT "example domain-verification value" ``` The example is illustrative only. Publish the exact hostname and value supplied by the service that needs the verification record. Long values are often displayed as adjacent quoted strings by DNS software. DNS resolvers return those strings as parts of the same TXT record. A DKIM public key can therefore appear split in a zone file or DNS interface without becoming multiple DKIM records. ```text selector1._domainkey.yourdomain.com. 3600 IN TXT ( "v=DKIM1; k=rsa; p=example-public-key-part-one" "example-public-key-part-two" ) ``` This is an illustrative structure, not a usable DKIM key. Generate the real selector and public key in the sending service that signs mail. Do not copy another organization's selector, key, or CNAME target. ![DNS TXT record examples showing the distinct owner names used for domain verification, SPF, DKIM, and DMARC](/images/editorial/what-is-a-txt-record/what-is-a-txt-record-records.webp "1200x533") *Source: Palisade.* ### SPF uses a TXT record with one SPF policy [SPF](https://www.rfc-editor.org/rfc/rfc7208) uses DNS TXT records to publish a domain's SPF policy. RFC 7208 states that a domain name must not have multiple records that would cause multiple SPF records to be selected. If more than one applicable `v=spf1` record is present, SPF processing returns `permerror`. ```text yourdomain.com. 3600 IN TXT "v=spf1 include:mail.example.net -all" ``` The example is illustrative only. `include:` mechanisms and the final qualifier must match the sources authorized for your own sending domain. Other TXT records at the same owner name can exist for unrelated purposes, but avoid treating two `v=spf1` values as a way to combine sender lists. Merge authorized mechanisms into the one SPF policy after confirming that the resulting lookup count remains within SPF's limits. ### DKIM publishes a public key at a selector name [DKIM](https://www.rfc-editor.org/rfc/rfc6376) lets a receiving system retrieve public-key information from DNS. The sender places the selector in the `s=` tag of its DKIM-Signature field. The receiver queries: ```text selector._domainkey.yourdomain.com ``` The TXT record at that name carries a DKIM key record, commonly beginning with `v=DKIM1;`. The selector is service-specific. A published key only makes verification possible. It does not prove that the application is currently signing mail with that selector. ### DMARC publishes a policy at `_dmarc` [DMARC](https://www.rfc-editor.org/rfc/rfc9989.html) uses a TXT record at `_dmarc` to publish policy and reporting instructions for a domain. ```text _dmarc.yourdomain.com. 3600 IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com" ``` This is an illustrative DMARC record. The reporting address and policy must be chosen for your domain and approved by the responsible operator. A DMARC record can be syntactically present while production mail still fails SPF or DKIM alignment. For more context on these related controls, visit the [email authentication learning hub](/learning). ## When does the requirement take effect? TXT records have been part of DNS since RFC 1035, published in November 1987. RFC 1035 is a final Internet Standard, not a draft. There is no single effective date for all TXT-record uses. Each protocol has its own controlling document and deployment rules: - SPF is specified in RFC 7208, published in April 2014. It obsoleted RFC 4408. - DKIM is specified in RFC 6376, published in September 2011. - DMARC is specified in RFC 9989, published in May 2026. A mailbox provider, domain-verification service, or email platform may set separate implementation deadlines or record-generation instructions. Follow that provider's current documentation for its own service instead of assuming an example record is universal. ## How do I implement the requirement? ### 1. Identify the protocol and owner name Start with the system that needs the record. It should state the exact record type, hostname, and value it expects. For email authentication, confirm which domain is used for the visible From address, SMTP envelope sender, and DKIM selector. A record at the wrong DNS name is not discovered by the intended protocol. ### 2. Obtain the exact value from the responsible service Copy the generated value from the provider that owns the verification or signing configuration. Preserve quoted-string boundaries only when your DNS provider requires them. > Do not replace an existing SPF record by adding a second `v=spf1` TXT record. Combine the authorized mechanisms into the existing SPF policy after reviewing all active senders. Record the current value before changing it. This gives the operator a rollback reference if a typo or omitted sender breaks authentication. ### 3. Publish the record in the authoritative DNS zone Add the TXT record at the hostname supplied by the protocol or service. Set a TTL that fits the change process used by the organization. DNS dashboards differ in how they display the zone origin. A dashboard might ask for `_dmarc`, while another asks for `_dmarc.yourdomain.com`. Check the provider's field guidance so the zone origin is not appended twice. ### 4. Wait for cached answers to expire DNS changes become visible as authoritative servers serve the new zone data, but recursive resolvers can retain an earlier answer until its TTL expires. The prior TTL controls how long an already cached answer may remain available. Do not use a fixed propagation promise. Check the authoritative answer and public resolver results instead. ### 5. Confirm the service uses the published record A DNS result is only the first layer. For a domain-verification record, confirm the provider's verification status. For email authentication, send a real message through the exact production sender and inspect its `Authentication-Results` header. ## How do I validate compliance? Use the [DNS lookup tool](/tools/dns-lookup) to inspect the public TXT response for the hostname you configured. Compare the returned owner name and text with the generated value before changing any policy. For copyable terminal commands and resolver comparisons, use the [DNS TXT record lookup guide](/resources-post/demystifying-dns-txt-record-lookups-a-comprehensive-guide-for-windows-mac-and-linux-users). Then validate the applicable layers: - DNS: Query the authoritative DNS service and at least one public resolver. Confirm the expected record name and complete value. - Vendor: Check the sending or verification provider's current status. A green indicator does not prove that a production message uses the configuration. - Message: Deliver a test message through the actual production path and inspect `Authentication-Results`. [RFC 8601](https://www.rfc-editor.org/rfc/rfc8601.html) defines the header field that reports authentication results. - DMARC: After reports accumulate, inspect aggregate-report data for the domain's authorized and unauthorized sources. A public lookup cannot prove future DNS state, a receiver's private reputation decision, or inbox placement. It also cannot repair malformed records or identify every sender that may use the domain. ## Track the email sources behind your TXT records A TXT lookup is useful for confirming the published value. It does not show which production senders still fail authentication or alignment after the record is live. Palisade is agentic DMARC software that analyzes DMARC aggregate-report data, identifies sending sources and authentication or alignment issues, and creates prioritized remediation tickets. It can propose the next DMARC policy step when evidence supports it, while a human reviews the evidence and applies the change. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=email_authentication&utm_content=what-is-a-txt-record) Palisade does not autonomously change your DMARC policy, prove every future message will authenticate, or guarantee delivery or inbox placement. ## Sources and further reading - [RFC 1035: Domain names - implementation and specification](https://www.rfc-editor.org/rfc/rfc1035) - [RFC 7208: Sender Policy Framework](https://www.rfc-editor.org/rfc/rfc7208) - [RFC 6376: DomainKeys Identified Mail Signatures](https://www.rfc-editor.org/rfc/rfc6376) - [RFC 9989: Domain-based Message Authentication, Reporting, and Conformance](https://www.rfc-editor.org/rfc/rfc9989.html) - [RFC 8601: Authentication-Results](https://www.rfc-editor.org/rfc/rfc8601.html) ## Frequently asked questions ### What is the difference between a TXT record and a CNAME record? A TXT record returns text at a DNS name. A CNAME record makes one DNS name an alias for another name. Protocol documentation determines which record type and owner name to publish. ### Can a domain have more than one TXT record? Yes. A domain can have multiple TXT records, including records for domain verification and email authentication. SPF is the key exception: publishing multiple applicable `v=spf1` records causes an SPF permanent error. ### Why is a DKIM TXT record split into quoted strings? A single DNS TXT character-string can contain at most 255 octets. DNS software can publish a longer TXT record as multiple quoted character-strings within one record, which allows a DKIM public key to be represented without creating multiple DKIM key records. ### Does a TXT record prove that email authentication works? No. A TXT lookup proves only that a public DNS response contains a value. Validate a real delivered message's authentication results and then review DMARC aggregate reports to confirm production behavior. ### How long does a TXT record change take to appear? It depends on the prior DNS TTL and resolver caching. Query the authoritative DNS service and public resolvers after the change instead of relying on a fixed number of minutes or hours. --- # What is an email header? Canonical: https://www.palisade.email/learning/what-is-an-email-header > What is an email header? Learn what message headers show, how Received and Authentication-Results work, and how to validate a delivered email. An email header is the structured metadata at the start of an email message. It carries fields such as `From`, `To`, `Date`, and `Subject`, plus delivery trace and authentication information that mail systems add as a message moves between servers. Headers help an operator investigate a delivered message, but a sender-supplied field alone does not establish who sent it. ## Quick takeaways - An Internet email message has a header section followed by a body, as defined by [RFC 5322](https://www.rfc-editor.org/rfc/rfc5322.html). - Fields such as `From` and `Subject` describe the message but can be supplied by the sender. - SMTP relays add `Received` fields that can help reconstruct the server-to-server delivery path. - `Authentication-Results` records an authentication service's evaluation of SPF, DKIM, DMARC, or other methods. - Authentication results are meaningful only when you trust the server that added them. - A delivered-message header is evidence for that message path, not proof that every future message will authenticate or reach the inbox. ## Who is affected? Anyone who sends, receives, supports, or investigates email may need to read a header. For a recipient, the header can explain why a message was filtered or show which server delivered it. For an IT team, it is message-level evidence for an SPF, DKIM, or DMARC investigation. For an MSP, it can connect a delivery incident to a specific client domain or sending service. RFC 5322 defines the Internet Message Format. It describes a message as a header section followed by a body, with header fields made of a field name, a colon, and a field body. The standard defines common fields such as `From`, `To`, `Date`, `Message-ID`, and `Subject`, but extensions can add other fields. [RFC 5322's header-field rules](https://www.rfc-editor.org/rfc/rfc5322.html#section-2.2) apply to the message format, not to every mailbox provider's interface. A mail client often shows only a small subset of fields. The raw header can include additional routing and authentication details. Treat it as sensitive operational evidence because it can contain addresses, server names, message identifiers, and IP addresses. Redact recipient addresses, identifiers, and internal hostnames before sharing a header outside the team that needs it. ## What are the requirements? ### Header fields follow the Internet Message Format RFC 5322 requires a message header to be a sequence of header fields. Each field has a field name, a colon, and a field body. Field names are printable US-ASCII characters except space, control characters, and colon. The standard also defines folding rules that allow a long field to continue on later physical lines. ```text From: alerts@yourdomain.com To: recipient@example.net Subject: Illustrative delivery notice Date: Tue, 11 Aug 2026 12:00:00 +0000 Message-ID: <example-12345@yourdomain.com> ``` The values above are illustrative only. `From` identifies the author address presented to the recipient, while `Message-ID` identifies a particular message. Neither field independently proves that a domain authorized the message. Authentication checks use other inputs and policies. A field can appear in a message because RFC 5322 defines it, because an SMTP server adds it, or because a receiving system adds operational data. Read each field according to its source and purpose. Do not treat every line in a raw header as equally trustworthy. ### SMTP relays prepend `Received` fields When an SMTP server receives a message for further transmission, [RFC 5321 requires it to insert a `Received` time stamp trace record](https://www.rfc-editor.org/rfc/rfc5321.html#section-4.4) at the beginning of the message content. Because each new trace record is prepended, the oldest visible server trace is usually lower in the header and the newest is near the top. ```text Received: from outbound.yourdomain.com (outbound.yourdomain.com [192.0.2.10]) by mx.example.net with ESMTPS id example123 for <recipient@example.net>; Tue, 11 Aug 2026 12:00:00 +0000 ``` This is an illustrative trace, not a record to publish. Start near the bottom of the `Received` chain and work upward when reconstructing the route. A trace line describes what the receiving server says it received. Lines added before a message reaches infrastructure you trust can be forged, so a chain is not a complete forensic finding on its own. For the transport label in the example, see [what ESMTPS means](/learning/esmtps). ![Email header fields showing sender-supplied message fields, SMTP Received trace records, and receiver-added authentication results](/images/editorial/what-is-an-email-header/email-header-fields.webp "1200x533") *Source: Palisade.* ### Authentication services report their own results [Authentication-Results](https://www.rfc-editor.org/rfc/rfc8601.html) is a trace field for an authentication service to report the results of checks it performed. RFC 8601 specifies syntax such as an authentication service identifier, a method result, and optional properties. Common methods include SPF, DKIM, and DMARC. ```text Authentication-Results: mx.example.net; spf=pass smtp.mailfrom=mail.yourdomain.com; dkim=pass header.d=yourdomain.com; dmarc=pass header.from=yourdomain.com ``` This example is illustrative only. `smtp.mailfrom` identifies an SPF-related identity, `header.d` identifies a DKIM signing domain, and `header.from` identifies the domain evaluated for DMARC. A result of `dkim=pass` means the authentication service evaluated a valid DKIM signature under its own rules. It does not, by itself, establish DMARC alignment with the visible `From` domain. RFC 8601 also defines a trust boundary: a receiver must decide which authentication services it trusts. A sender can insert text that resembles an authentication result before delivery. Give weight to results added by the mailbox provider or other receiving infrastructure you trust, rather than relying on an unverified line lower in the header. ## When does the requirement take effect? There is no single new compliance date for email headers. RFC 5322 was published as an Internet Standard in October 2008 and obsoleted RFC 2822. [RFC 5321](https://www.rfc-editor.org/rfc/rfc5321.html), published in October 2008, defines SMTP trace requirements including `Received` records. [RFC 8601](https://www.rfc-editor.org/rfc/rfc8601.html), published in May 2019, defines the `Authentication-Results` header field and obsoleted RFC 7601. These standards define message and trace behavior. They do not set a universal deadline requiring every sender to deploy SPF, DKIM, or DMARC. Mailbox-provider sender rules can impose separate requirements, thresholds, and enforcement dates. Keep those rules separate from the header syntax itself. ## How do I implement the requirement? ### 1. Send a controlled message through the production path Send a test message from the exact application, ESP, or relay that sends production mail. Use a safe recipient mailbox where you can open the original source. A message sent from a different test system does not validate the production sending path. ### 2. Export the raw message source Use the mailbox provider's documented option to view the original message or message source. For Gmail, [View message headers in Gmail](https://support.google.com/mail/answer/29436) documents the "Show original" path. Copy the full header before forwarding the message, because forwarding can add fields and change the evidence. ### 3. Read message fields and trace fields separately Identify the `From`, `Date`, `Subject`, and `Message-ID` fields first. Then find `Received` records and read the server trace from the earliest trusted record toward final delivery. Do not assume the visible sender address is authenticated. It is an RFC 5322 author field. Authentication evidence belongs in trusted `Authentication-Results` records and in the underlying SPF, DKIM, and DMARC evaluation. ### 4. Compare authentication identities with the visible domain Locate `spf=`, `dkim=`, and `dmarc=` within the trusted `Authentication-Results` field. Compare `header.from` with the `From` domain. If DMARC fails, inspect the reported SPF and DKIM identities before changing DNS or a sending platform. A passing DNS record does not establish that the application used that record. If header evidence shows a different return-path domain or DKIM signing domain, investigate that specific production configuration. The [email authentication learning hub](/learning) has related guidance on the protocol layer. ## How do I validate compliance? Validation needs evidence from more than one layer. - DNS: confirm the domain's public SPF, DKIM, and DMARC records through authoritative DNS and a public resolver when the investigation concerns published authentication controls. - Vendor: check the sending provider's current domain-authentication status if it provides one. A green status is not proof of a delivered message. - Message: inspect a real delivered message from the production path and its trusted `Authentication-Results` field. - DMARC: review aggregate-report data after it accumulates to identify sending sources and recurring alignment failures. For a raw message, use the [email header analyzer](/tools/email-header-analyzer) to inspect a redacted header and decode visible routing and authentication fields. The analyzer can help interpret the header you provide, but it cannot prove a receiver's private filtering decision, inspect future messages, or replace DNS and aggregate-report evidence. If the header shows an authentication failure and Gmail blocks the message, compare the finding with [Gmail's unauthenticated-sender guidance](/email-deliverability/gmail-blocked-sender-is-unauthenticated). If the issue is Outlook spam placement, use the delivered message and provider evidence alongside [guidance for emails going to spam in Outlook](/email-deliverability/how-to-stop-emails-going-to-spam-in-outlook). Authentication supports delivery decisions, but it does not guarantee inbox placement. ## Track the sending sources a single header cannot show A header explains one delivered message. It does not inventory every system using the domain, show later alignment drift, or establish when the domain is ready for a stricter DMARC policy. Palisade is agentic DMARC software that analyzes DMARC aggregate-report data, identifies sending sources and authentication or alignment issues, and creates prioritized remediation tickets. It can propose a next policy step based on the evidence, while a human reviews the evidence and applies any DNS change. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=email_authentication&utm_content=what-is-an-email-header) Palisade does not change the DMARC policy automatically, guarantee delivery or inbox placement, or prove that every future message will authenticate. ## Sources and further reading - [RFC 5322: Internet Message Format](https://www.rfc-editor.org/rfc/rfc5322.html) - [RFC 5321: Simple Mail Transfer Protocol](https://www.rfc-editor.org/rfc/rfc5321.html) - [RFC 8601: Message Header Field for Indicating Message Authentication Status](https://www.rfc-editor.org/rfc/rfc8601.html) - [Google Help: View message headers in Gmail](https://support.google.com/mail/answer/29436) ## Frequently asked questions ### Is the From address in an email header proof of the sender? No. The `From` field is an author address in the message header and can be supplied by the sender. Check trusted `Authentication-Results` evidence, especially the DMARC result and the `header.from` identity, before treating it as authentication evidence. ### Should I read Received headers from the bottom up? Yes. SMTP servers prepend new `Received` trace records, so the earliest visible trace is usually lower in the header. Start with the earliest trusted record, then follow the records upward toward final delivery. ### Can an Authentication-Results header be forged? Only an untrusted one can be treated as sender-supplied text. RFC 8601 requires receivers to establish a trust boundary for authentication services. Use results added by the mailbox provider or infrastructure you trust. ### Does SPF pass mean DMARC passes? No. SPF can pass for an envelope domain that does not align with the visible `From` domain. DMARC evaluates alignment as well as SPF or DKIM authentication results. ### Can an email header prove why a message went to spam? Not always. A header can show message-level authentication and routing evidence, but mailbox providers use private filtering signals that may not appear in the header. Inspect the provider's available delivery evidence as well. --- # What is an IP reputation? Canonical: https://www.palisade.email/learning/what-is-an-ip-reputation > IP reputation is a receiving provider's assessment of an email-sending IP. See what affects it, its limits, and how to investigate delivery. An IP reputation is a receiving mail provider's assessment of the email traffic it sees from a particular sending IP address. It is not a universal score that every provider shares or applies the same way. Reputation can affect whether a provider accepts a message, filters it, or places it in spam, alongside [domain reputation](/tools/domain-reputation), authentication, content, and the provider's own local policies. ## Quick takeaways - IP reputation is receiver-assessed, so one provider's view may differ from another's. - An IP address is only one signal in an email-delivery decision. - Spam complaints, sending patterns, recipient engagement, and authentication can affect provider trust. - A shared IP can reflect traffic from multiple senders, while a dedicated IP concentrates responsibility with one sender. - Passing SPF, DKIM, or DMARC does not guarantee inbox placement. - Public reputation checks provide a point-in-time signal, not a receiver's complete private decision. ## How IP reputation works A mailbox provider receives SMTP traffic from an IP address and evaluates the behavior associated with that traffic over time. Google tells senders that it considers factors such as spam reports, user engagement, and IP and domain reputation when classifying mail. [Google's email sender guidelines](https://support.google.com/a/answer/81126) also require bulk senders to authenticate messages and keep spam rates low. The result is an operational assessment, not a portable number. A provider can use its own complaint data, traffic patterns, authentication results, recipient signals, and local anti-abuse controls. That is why a positive result in one public lookup does not prove that Gmail, Outlook, or another provider will accept or place a particular future message in the inbox. Microsoft similarly provides [Smart Network Data Services](https://sendersupport.olc.protection.outlook.com/snds/) so qualifying senders can view data related to traffic sent to Outlook.com. That visibility is provider-specific. It does not expose every filtering rule or turn the provider's delivery decision into a universal IP score. ![Diagram showing the evidence boundary between a sending IP, public reputation signals, and a mailbox provider's private delivery decision](/images/editorial/what-is-an-ip-reputation/what-is-an-ip-reputation-evidence-boundaries.webp "1200x829") *Source: Palisade.* The IP reputation signal usually appears alongside the sending domain. For the related domain-side concept, see [what is a domain reputation?](/learning/what-is-a-domain-reputation). Both signals matter in the broader [email deliverability](/email-deliverability) process. ## When the answer changes The practical meaning of an IP reputation changes with the sending arrangement and the evidence available. - **Shared IP address:** Multiple customers or applications may send through the same IP. Your own program still affects how providers assess the traffic they receive, but you do not control every sender using that address. Ask the email service provider how it manages shared infrastructure and abuse. - **Dedicated IP address:** One organization has more direct control over the traffic sent from the IP. That also means inconsistent volume, poor list quality, or unwanted mail can become associated with that IP's history. - **New IP address:** A new dedicated IP has limited provider history. [Twilio SendGrid's IP warmup guidance](https://www.twilio.com/docs/sendgrid/ui/sending-email/warming-up-an-ip-address) recommends gradually increasing volume and starting with engaged recipients rather than sending a full program immediately. - **Different mailbox providers:** A blocklist listing, provider dashboard, or public checker can be useful evidence, but each covers only its own data or method. Do not treat any one result as a complete explanation for all delivery outcomes. Use this decision rule: if the issue is limited to one provider, first inspect that provider's bounce information, sender dashboard, or feedback data. If the issue appears across several providers, compare the exact sending IP, visible From domain, authentication results, complaint data, and recent changes in volume or recipient acquisition. > Do not move traffic abruptly to a new IP to bypass filtering. Changing infrastructure does not resolve unwanted-mail practices, authentication failures, or a damaged domain reputation. ## A worked IP reputation evidence object An IP reputation investigation needs a concrete sending-path record. Record the IP from the delivery event or SMTP logs, then keep the domain and provider context with it. ```text Sending IP: 192.0.2.44 Visible From domain: yourdomain.com Recipient provider: example mailbox provider Observed result: deferred or spam placement Authentication evidence: SPF pass, DKIM pass, DMARC pass Traffic change: volume increased on 2026-08-10 Public lookup time: 2026-08-11T12:00:00Z ``` This is an illustrative evidence format only. Do not publish customer IP addresses, recipient addresses, message content, or unredacted headers. The record separates facts that are often confused: - The sending IP identifies the infrastructure the receiver observed. - The visible From domain identifies the domain the recipient saw. - SPF, DKIM, and DMARC results show authentication evidence for that message path. They do not reveal a provider's private reputation weighting. - A delivery result shows what happened for that provider and message. It does not establish a rule for every recipient. - A time-stamped public lookup can support an investigation, but it cannot prove the production path, continuous reputation state, or future inbox placement. For a security concern involving an unexpected source IP, [how IP spoofing works and how to stop it](/learning/how-does-ip-spoofing-work-and-how-can-you-stop-it) covers a different problem: falsified network source information is not the same as a mail provider's reputation assessment. ## What to do next with the evidence you have If you only have an IP address, run a [Palisade IP reputation check](/tools/ip-reputation) to inspect the public signals available for that address. Save the lookup time and compare it with the delivery event. Then identify whether the IP is shared or dedicated through the provider that sends your mail. If you have a delivered message, inspect its raw headers and the provider's delivery outcome. Confirm the sending IP and compare the `Authentication-Results` evidence with the visible From domain. A passing result supports an authorized sending path, but it does not explain every spam-folder decision. If you manage a dedicated IP, review recent volume changes, recipient permission practices, hard bounces, and complaint data before changing infrastructure. For a domain-wide delivery issue, also review [how to check and improve email domain reputation](/learning/how-can-you-check-and-improve-your-email-domain-reputation). For ongoing DMARC work, aggregate reports can identify sending sources and authentication or alignment issues across domains. Palisade provides DMARC software that analyzes DMARC aggregate-report data, creates prioritized remediation tickets, and proposes the next policy stage for human review. It does not control a mailbox provider's private reputation decision, delist an IP, or guarantee inbox placement. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=email_deliverability&utm_content=what-is-an-ip-reputation) ## Sources and further reading - [Google email sender guidelines](https://support.google.com/a/answer/81126) - [Microsoft Smart Network Data Services](https://sendersupport.olc.protection.outlook.com/snds/) - [Twilio SendGrid IP warmup guidance](https://www.twilio.com/docs/sendgrid/ui/sending-email/warming-up-an-ip-address) - [Palisade IP reputation checker](/tools/ip-reputation) ## Frequently asked questions ### Is IP reputation a score? No. Providers can assess IP reputation internally, but they do not use one shared public score. A public tool or provider dashboard may expose useful signals, yet it cannot fully reproduce another provider's filtering decision. ### Can a good IP reputation guarantee inbox placement? No. Inbox placement can also depend on domain reputation, authentication, message content, recipient signals, and the receiver's local policies. A strong IP reputation supports delivery, but it does not guarantee placement. ### Does a shared IP mean another sender can affect my delivery? Yes. A shared IP carries traffic from more than one sender, so the provider that operates the shared infrastructure has an important role in managing abuse and traffic quality. Your own sending practices still matter. ### Should a low-volume sender use a dedicated IP? Only if the sending provider and the sender's actual traffic pattern justify it. Dedicated IPs need a stable, permission-based sending program so providers can develop meaningful history for that IP. ### Can SPF, DKIM, and DMARC fix a poor IP reputation? No. Authentication establishes evidence that a message is authorized by relevant domains, but it does not erase complaint history, poor recipient engagement, or unwanted-mail patterns. It is one part of a healthy sending program. --- # What is DMARCbis? RFC 9989, the new DMARC standard Canonical: https://www.palisade.email/learning/what-is-dmarcbis-rfc-9989-dmarc-standard > DMARCbis, RFC 9989, is the current DMARC standard. Learn what changed, when it took effect, how to validate your record, and what domain owners must do. [DMARCbis](https://datatracker.ietf.org/doc/html/rfc9989) is the IETF Standards Track revision of DMARC, published as RFC 9989 in May 2026. It keeps the familiar `v=DMARC1` record and SPF or DKIM alignment model, while defining updated policy discovery, a policy for non-existent subdomains, and revised tag handling. Existing DMARC records remain usable, but domain owners should review records when they next make a policy change. ## Quick takeaways - RFC 9989 is the core DMARCbis specification and a Proposed Standard. - RFC 9989, RFC 9990, and RFC 9991 replace RFC 7489 and RFC 9091, the earlier DMARC specification and its reporting documents. - DMARCbis records still use `v=DMARC1`, not `DMARC2`. - The `np` tag can publish a policy for non-existent subdomains. - DMARCbis retires `pct`, `rf`, and `ri` from the core record model. - A public DNS check confirms the published record, but it does not prove that production mail passes DMARC. ## Who is affected? DMARCbis affects domain owners that publish DMARC policy, mailbox providers that evaluate DMARC, and services that generate or process DMARC reports. It is most relevant when an organization maintains an enforced DMARC policy, operates several sending subdomains, or manages many client domains. The controlling standard is [RFC 9989: Domain-based Message Authentication, Reporting, and Conformance](https://datatracker.ietf.org/doc/html/rfc9989), published as a Proposed Standard in May 2026. It obsoletes RFC 7489, the Informational document that defined DMARC since 2015, along with RFC 9091's experimental PSD extension. Aggregate-report processing is defined separately in [RFC 9990](https://datatracker.ietf.org/doc/html/rfc9990), and failure reporting is defined in [RFC 9991](https://datatracker.ietf.org/doc/html/rfc9991). DMARCbis does not require every domain to publish a new record immediately. A domain with a valid existing DMARC record can continue to use it. The practical work is reviewing retired tags and deciding whether the new non-existent-subdomain policy fits the domain's DNS and sending design. For the broader protocol model, see Palisade's [DMARC learning center](/learning/dmarc). ## What are the requirements? ### A DMARC record still identifies itself as DMARC1 RFC 9989 retains `DMARC1` as the record version identifier. A domain owner publishes the record at `_dmarc` under the domain being evaluated. DMARC still evaluates whether SPF or DKIM passes and aligns with the visible From domain under the rules in the core specification. ```text v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourdomain.com ``` The example is illustrative only. Publish the reporting address and policy that your organization has approved, and verify that the address can receive reports before relying on it. ![DMARCbis record fields showing the familiar DMARC1 version, policy, reporting address, and optional non-existent subdomain policy](/images/editorial/what-is-dmarcbis-rfc-9989-dmarc-standard/what-is-dmarcbis-rfc-9989-dmarc-standard-record.webp "1200x600") *Source: Palisade.* The record format is backward compatible in the useful sense: an existing `v=DMARC1` record does not need a version-label change to be understood by a DMARCbis implementation. Do not invent a `v=DMARC2` value. That value is not part of RFC 9989. ### The np tag can set policy for non-existent subdomains RFC 9989 defines `np` as a requested policy for mail that claims to use a subdomain that does not exist in DNS. It gives domain owners a way to publish an explicit policy for invented subdomain names without changing the policy for subdomains that actually exist. ```text v=DMARC1; p=reject; sp=quarantine; np=reject; rua=mailto:dmarc-reports@yourdomain.com ``` `np=reject` is appropriate only after checking the domains and subdomains used by real mail streams. If a legitimate sender uses a subdomain that has no DNS presence, the operational result can differ from what the sending team expects. > Before publishing `np=reject`, inventory legitimate sending subdomains and confirm that each has the DNS presence and authentication configuration its mail path requires. RFC 9989 defines fallback behavior when `np` is absent. Receivers use the applicable [subdomain policy](/learning/glossary/dmarc-sp) when available, then the organizational-domain policy. The new tag gives a domain owner a more specific option for a name that DNS indicates does not exist. ### DMARCbis changes tag handling and policy discovery RFC 9989 retires the `pct`, `rf`, and `ri` tags from the core DMARC specification: [the retired `pct` tag](/learning/glossary/dmarc-pct) requested that policy apply to only a percentage of failing mail, `rf` chose a failure-report format, and `ri` requested an aggregate-report interval. Domain owners should not treat a retired tag as a current DMARCbis control. Review older records during normal maintenance, especially where `pct` was used to express a rollout stage. RFC 9989 also defines a `t` tag for test policy handling. Its purpose is distinct from a percentage-based enforcement instruction. Preserve the exact behavior and receiver discretion described in the standard when documenting or deploying it. A test indicator is not evidence that every receiver will treat mail the same way. A third added tag, `psd`, identifies whether the record belongs to a Public Suffix Domain. It helps distinguish a Public Suffix Domain from an Organizational Domain during policy discovery, and it matters mainly for public suffix operators and organizations with deeper or less conventional DNS structures. Do not add it without understanding how receiving systems implement RFC 9989. DMARCbis uses DNS-based policy discovery, commonly described as a DNS Tree Walk, instead of relying on the Public Suffix List for organizational-domain discovery. The receiver walks upward through the DNS labels of the evaluated domain looking for the applicable record, and the algorithm is limited to eight queries. This change is primarily a receiver implementation matter. Domain owners should still publish DMARC records at the correct `_dmarc` locations and test the names they actually use. ## When does the requirement take effect? RFC 9989 was published in May 2026 as a Proposed Standard. It is the current core DMARC standard, while RFC 9990 covers aggregate reporting and RFC 9991 covers failure reporting. There is no single sender deadline in RFC 9989 that requires every domain owner to add `np`, remove retired tags, or replace a working DMARC record on a particular day. A mailbox provider can separately set its own sender requirements, enforcement dates, and exceptions. Those provider rules are not created by RFC 9989 itself. The practical timing is therefore tied to change control. Review the record before a planned policy change, an ESP migration, a new subdomain launch, or a wider domain portfolio audit. If a mailbox provider announces a requirement, use that provider's current documentation for its scope and date. ## How do I implement the requirement? ### 1. Retrieve the current DMARC record Query `_dmarc.yourdomain.com` through authoritative DNS and at least one public resolver. Record the exact TXT value, including every tag. Do not edit a copied value from an old ticket or dashboard without confirming it is still published. Use the [DMARC checker](/tools/dmarc) to inspect the public record syntax and discovered policy. A DNS check is a useful starting point because RFC 9989 begins with the published record. ### 2. Identify real sending domains and subdomains List the domains in visible From addresses, envelope senders, and DKIM signing domains used in production. Include transactional mail, marketing platforms, support systems, and any delegated sending service. This inventory determines whether an `np` policy is safe. A subdomain used for sending should have an intentional DNS and authentication design. Do not assume a name is unused because it is absent from one application screen. ### 3. Remove retired controls only with an approved replacement plan If the record uses `pct`, `rf`, or `ri`, review why each tag was added. Retiring a legacy tag can be a clean-up step, but it should not be used to hide an unresolved authentication failure or an incomplete sender inventory. Where a test-policy signal is appropriate, follow RFC 9989's definition of `t`. Treat it as guidance for DMARC evaluation, not as proof that mail is safe to enforce globally. ### 4. Add an np policy after checking DNS behavior Choose the `np` value that matches the domain's approved policy. For an already enforced domain with no legitimate mail from undefined subdomains, `np=reject` may align with the intended protection. Test representative real subdomains before publishing the change. Keep the change narrow. A DMARC record update cannot repair SPF authorization, DKIM signing, or From-domain alignment for a sender that already fails them. ### 5. Publish and allow DNS propagation Publish the approved TXT record at the correct `_dmarc` label. Query the authoritative nameserver and public resolvers again after the change. Retain the prior value and the planned rollback decision in the change record. ## How do I validate compliance? Validate at four layers. First, check DNS. Confirm that authoritative DNS and a public resolver return the intended TXT record. Check relevant subdomain names so that the DNS state matches the `np` decision. Second, check the sending service. Each service that sends mail for the domain should show its current SPF and DKIM configuration or verification state. A green vendor status is useful evidence, but it does not prove a delivered message used the configured path. Third, inspect a delivered message from each production path. Read the `Authentication-Results` header to confirm the observed SPF, DKIM, and DMARC outcomes for that message. DMARC result fields and their trust boundary are specified in [RFC 8601](https://www.rfc-editor.org/rfc/rfc8601.html), so use results added by a trusted receiver or trusted internal system. Fourth, review DMARC aggregate reports once data accumulates. RFC 9990 defines aggregate reporting, which helps reveal sources and disposition outcomes over time. Reports can identify an unexpected sending source, but they do not guarantee that every future message will authenticate. ![DMARCbis validation flow from public DNS record to sender status, delivered-message headers, and aggregate-report review](/images/editorial/what-is-dmarcbis-rfc-9989-dmarc-standard/what-is-dmarcbis-rfc-9989-dmarc-standard-validation-flow.webp "1200x676") *Source: Palisade.* ## Keep DMARCbis changes visible after the DNS check A record check can confirm whether `np`, `t`, and other tags are publicly published. It cannot show which production senders still fail alignment, whether a receiver applies a private policy decision, or whether a new sender appears after the check. Palisade is agentic DMARC software that analyzes DMARC aggregate-report data, identifies sending sources and authentication or alignment issues, and creates prioritized remediation tickets. It can propose the next policy step when the evidence supports it, while a human reviews the evidence and applies the change. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=existing_content_migration&utm_content=what-is-dmarcbis-rfc-9989-dmarc-standard) Palisade does not autonomously change your DMARC policy, prove every future message will authenticate, or control a mailbox provider's delivery decision. For an example of how aggregate data can expose sender requirement failures, read [what Google's DMARC reports say about sender failures](/learning/what-new-insights-do-google-dmarc-reports-provide-about-sender-requirement-failures). ## Sources and further reading - [RFC 9989: Domain-based Message Authentication, Reporting, and Conformance](https://datatracker.ietf.org/doc/html/rfc9989) - [RFC 9990: DMARC Aggregate Reporting](https://datatracker.ietf.org/doc/html/rfc9990) - [RFC 9991: DMARC Failure Reporting](https://datatracker.ietf.org/doc/html/rfc9991) - [RFC 8601: Message Header Field for Indicating Message Authentication Status](https://www.rfc-editor.org/rfc/rfc8601.html) ## Frequently asked questions ### Is DMARCbis the same as DMARC 2.0? No. DMARCbis is the revision defined by RFC 9989, and a DMARC record still begins with `v=DMARC1`. "DMARC 2.0" is not a record version defined by the standard. ### Do I need to replace my current DMARC record? No. A valid existing `v=DMARC1` record remains usable under DMARCbis. Review it when you next change policy, especially if it contains retired tags or if you want an explicit policy for non-existent subdomains. ### Does np=reject affect every subdomain? No. The `np` tag applies to a subdomain that does not exist in DNS. Existing subdomains follow the applicable DMARC policy and their own DNS and authentication configuration. ### Does DMARCbis change SPF or DKIM alignment? No. DMARCbis keeps the DMARC model in which SPF or DKIM must pass and align with the visible From domain. The revision updates the DMARC standard and related policy behavior, not the underlying SPF or DKIM protocols. ### Can a DMARC checker prove that my mail complies with RFC 9989? No. A checker can inspect the published DNS record. Compliance also needs evidence from the sending service, delivered-message authentication results, and aggregate reports from real production traffic. --- # What is email filtering and how does it prevent spam? Canonical: https://www.palisade.email/learning/what-is-email-filtering-software-services-prevent-spam > Email filtering evaluates messages for spam and threats using authentication, reputation, and message signals before delivery or quarantine. Email filtering is the process a mailbox provider or security gateway uses to evaluate an incoming message and decide whether to deliver it, place it in spam, quarantine it, or reject it. It prevents some spam by combining evidence about the sender, the message, and the recipient environment. Authentication helps establish authorized domain use, but it does not guarantee inbox placement or prove a message is safe. ## Quick takeaways - Email filters make a receiver-side decision for each message or sending stream. - Sender authentication, reputation, and message characteristics can all affect filtering. - SPF, DKIM, and DMARC help receivers evaluate whether a domain's use is authorized. - A DMARC pass does not mean a message is harmless or entitled to inbox placement. - A false positive is legitimate mail sent to spam or quarantined by a filter. - Public DNS checks can inspect published records, but cannot show a receiver's private filtering decision. ## How email filtering works Email filtering applies checks at different points in mail flow. A receiving service can reject a connection before delivery, classify a message after accepting it, or route it to a spam or quarantine location. Microsoft describes its email protection as including connection filtering, spam filtering, anti-malware filtering, and related controls in [Exchange Online Protection](https://learn.microsoft.com/en-us/defender-office-365/anti-spam-protection-about?view=o365-worldwide). Each provider can use its own policies and evidence, so there is no universal spam score that guarantees the same result everywhere. A filter commonly has evidence in these areas: - **Connection and sender evidence:** The receiving system can evaluate the sending IP address, domain, and prior behavior associated with the source. A poor reputation can affect a message even if its visible content appears ordinary. - **Authentication evidence:** SPF authorizes hosts to use a domain in mail, while DKIM provides a domain-level signature that a receiver can verify. [RFC 7208 defines SPF](https://datatracker.ietf.org/doc/html/rfc7208), and [RFC 6376 defines DKIM signatures](https://www.rfc-editor.org/rfc/rfc6376.html). - **Domain alignment and policy:** [RFC 9989 defines DMARC](https://datatracker.ietf.org/doc/html/rfc9989) as a way for a domain owner to publish an authentication policy and request reports. DMARC passes only when SPF or DKIM passes with an identifier aligned to the visible From domain. - **Message and recipient evidence:** Filters can assess message content, links, attachments, headers, recipient-level settings, and reports from users. The exact weighting is generally not published by mailbox providers. Authentication therefore gives the filter a useful identity signal. It does not replace other filtering evidence. RFC 9989 is explicit that a DMARC pass only validates authorized use of the author domain for that message. It does not state that delivery to the inbox is safe or desirable. ![Flow showing how an email filter evaluates connection, authentication, message, and receiver evidence before choosing an action](/images/editorial/what-is-email-filtering-software-services-prevent-spam/what-is-email-filtering-software-services-prevent-spam-filtering-flow.webp "1200x829") *Source: Palisade.* For broader sender-side context, see [email deliverability](/email-deliverability). Deliverability covers whether mail reaches the intended recipient and where it lands after the receiving system makes its decision. ## How MX filtering changes the mail route MX filtering is a deployment pattern in which a domain publishes the filtering service's hosts as its MX destination. Sending servers deliver inbound mail to that service first. The filter evaluates the message and forwards accepted mail to the organization's final mailbox system. [Microsoft documents this route for third-party cloud filtering services](https://learn.microsoft.com/en-us/exchange/mail-flow-best-practices/manage-mail-flow-using-third-party-cloud). MX preference still follows SMTP routing rules. [RFC 5321 says lower MX preference numbers are preferred](https://www.rfc-editor.org/rfc/rfc5321.html#section-5.1), so the published record order controls which advertised host a sender tries first. The [MX record guide](/learning/what-is-an-mx-record) explains preference, failover, and the difference between inbound routing and sender authentication. A public MX lookup can identify the hostnames advertised for inbound delivery. It cannot reveal every filtering policy, prove which product handles a generic hostname, or show whether a message was accepted, quarantined, forwarded, or rejected. Confirm the route with the domain owner or mail administrator before assigning a vendor from DNS alone. ## When filtering prevents spam, and when the result changes Filtering prevents spam when the available evidence gives the receiver a reason to block, quarantine, or classify a message as unwanted. The decision changes with the evidence available to that specific receiver. A legitimate-looking message can be filtered when its sending service is unauthorized, its DKIM signature fails, its domain has a poor reputation, or a local policy treats the message as suspicious. That outcome is a false positive when the message was legitimate. Spam can still reach an inbox when it evades the receiver's current controls, comes from a source without an established negative reputation, or uses a domain that is not the exact domain protected by DMARC. DMARC addresses unauthorized use of the visible From domain. [RFC 9989's anti-phishing scope](https://datatracker.ietf.org/doc/html/rfc9989#section-2.2) does not cover every fraudulent message, including visually similar domains and display-name abuse. Use this decision rule: - If the problem is an unknown message received by a user, inspect the message's headers and the receiver's security or quarantine view. A public DNS lookup cannot explain the provider's final decision. - If the problem is mail your organization sends, confirm the sending domain's SPF, DKIM, and DMARC publication first. Then test a real message through the production path. - If the problem is recurring spam that impersonates your exact domain, use DMARC aggregate reports to identify unauthorized use and legitimate sources before changing policy. - If the problem is user-reported spam or spam-folder placement, treat authentication as one part of the investigation. Content, reputation, and the receiving provider's local controls can still determine the outcome. Google's [email sender guidelines](https://support.google.com/a/answer/81126) require authentication practices for applicable senders and explain that meeting the guidelines does not guarantee delivery. That distinction matters: passing a protocol check is evidence about one condition, while filtering is the receiver's combined handling decision. ## A worked filtering example Consider a password-reset message sent with `From: support@yourdomain.com`. The following is an illustrative evidence object, not a record to publish or a copy of a real message. ```text Visible From domain: yourdomain.com SPF result: pass for mail.example-sender.com DKIM result: pass with d=yourdomain.com DMARC result: pass because the DKIM domain aligns with yourdomain.com Receiver action: still determined by the receiving system's filtering policy ``` The DMARC result can pass because the DKIM signing domain aligns with `yourdomain.com`. That establishes authorized use of the visible From domain under the DMARC evaluation model. It does not settle every filtering question. The recipient's provider can still consider the sending stream's reputation, the message's links or attachments, and local policy. Conversely, a failed authentication result gives a receiver a reason to treat a message with more caution, but the receiver still controls the final handling. > Do not move a domain directly to a stricter DMARC policy because a DNS check looks correct. First verify every important production sender with a real delivered message and use aggregate reports to find sources that need remediation. For a sender trying to reduce spam-folder placement, this example points to a useful sequence: verify published DNS, inspect the exact production message, then compare what the receiver recorded. [How to stop emails going to spam in Outlook](/email-deliverability/how-to-stop-emails-going-to-spam-in-outlook) covers the provider-specific evidence to collect when Outlook is the receiving environment. ## What to check next Start with the evidence you have. If you only have a sending domain, inspect its public authentication posture. A domain-level result can show whether SPF, DKIM, and DMARC records are publicly discoverable. It cannot prove that the application sending a particular message uses those records correctly. If you have a message that reached spam, use the raw message headers and the receiving provider's available spam or quarantine details. Compare the visible From domain, SPF result, DKIM result, and DMARC result with the path your application was meant to use. Then send a controlled test through the same production service. Do not rely on a test from a different platform, subdomain, or return path. If the recurring issue is promotional mail, separate spam classification from category placement. A message can arrive outside the primary inbox without being spam. The useful evidence is the receiver's placement and the authentication results from that exact message. For Gmail-specific diagnosis, see [why emails go to spam in Gmail](/email-deliverability/why-are-my-emails-going-to-spam-in-gmail). If inbound spam claims to be from your exact domain, investigate domain impersonation separately from general filtering. DMARC can help receivers identify unauthorized use of that domain, while a lookalike domain needs other detection and response work. [What is spam email and how to prevent it?](/learning/what-is-spam-email-and-how-to-prevent-it) covers the broader user-facing prevention measures. ## Check the authentication signals behind filtering Run the sending domain through Palisade's [email security score checker](/tools/email-security-score) to inspect the public authentication and DNS signals that a receiver can look up. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=existing_content_migration&utm_content=what-is-email-filtering-software-services-prevent-spam) A public check does not prove why a specific receiver filtered a message, repair content or reputation issues, monitor future changes, or guarantee inbox placement. For teams with recurring authentication gaps, Palisade autonomously analyzes DMARC aggregate-report data, identifies sending sources and alignment issues, and creates prioritized remediation tickets. A human still reviews the evidence and applies any DNS or policy change. ## Sources and further reading - [Microsoft: Anti-spam protection in Microsoft 365](https://learn.microsoft.com/en-us/defender-office-365/anti-spam-protection-about?view=o365-worldwide) - [Google: Email sender guidelines](https://support.google.com/a/answer/81126) - [RFC 9989: Domain-based Message Authentication, Reporting, and Conformance](https://datatracker.ietf.org/doc/html/rfc9989) - [RFC 7208: Sender Policy Framework](https://datatracker.ietf.org/doc/html/rfc7208) - [RFC 6376: DomainKeys Identified Mail signatures](https://www.rfc-editor.org/rfc/rfc6376.html) ## Frequently asked questions ### Is email filtering the same as spam filtering? No. Spam filtering is one part of email filtering. Email filtering can also apply malware checks, connection controls, attachment policies, quarantine rules, and organization-specific mail-flow rules. ### Does SPF prevent spam? No. SPF lets a receiver check whether the connecting host is authorized to use a domain in the SMTP envelope identity. It is an authentication signal, not a complete spam-prevention system. ### Does a DMARC pass guarantee inbox placement? No. A DMARC pass validates authorized use of the visible From domain for that message. The receiving system can still consider reputation, message characteristics, and local policy when deciding placement. ### Can a legitimate email go to spam? Yes. Legitimate mail can be classified as spam when the receiver's available evidence or local policy treats it as suspicious. Check the exact production message, its authentication results, and the receiving provider's available details before changing DNS. ### Can a filter block a spoofed email from my domain? Yes. A receiver that evaluates DMARC can use a domain owner's requested policy after DMARC failure. The receiver makes the final handling decision, and DMARC does not protect against every fraudulent use of a similar-looking domain. --- # What is email spoofing and how can you prevent it? Canonical: https://www.palisade.email/learning/what-is-email-spoofing-and-how-can-you-prevent-it > Email spoofing forges sender details to make mail look trusted. Stop spoof emails with SPF, DKIM, DMARC enforcement, header checks, and user reporting. Email spoofing is the use of forged identity details to make a message appear to come from a person or domain that did not send it. To stop spoof emails reaching your users, check suspicious messages before acting on them. To stop spoofed mail going out under your name, publish SPF, DKIM, and DMARC for every domain you control and move DMARC to enforcement. These controls authenticate domain use, but they do not make every display name trustworthy or guarantee a receiver's final delivery decision. ## Quick takeaways - Email spoofing can falsify a visible From address, an envelope sender, or both. - A familiar display name is not proof that the sender controls the shown domain. - SPF checks whether an IP is authorized to use the envelope sender domain. - DKIM lets a receiver verify a signed message and the signing domain. - DMARC ties aligned SPF or DKIM authentication to the visible From domain and publishes a requested policy for failures. - A suspicious-message review and a public DNS lookup answer different questions. ## How email spoofing works SMTP separates several identities that readers often treat as one. The visible `From:` header identifies the author address presented to the recipient. The SMTP `MAIL FROM` command supplies the envelope sender used for delivery handling, including bounces. [RFC 5321 defines the SMTP `MAIL FROM` command](https://datatracker.ietf.org/doc/html/rfc5321), but SMTP alone does not prove that a sender is authorized to use the address a recipient sees. An attacker can therefore send a message with a trusted-looking display name or a forged visible From address. Some attempts use a lookalike domain instead of the real domain. Others use the real domain in the visible From field but fail authentication. The recipient needs message-level evidence, not the sender name alone. SPF publishes the IP addresses or mechanisms allowed to send for an envelope sender domain. [RFC 7208 defines SPF evaluation](https://datatracker.ietf.org/doc/html/rfc7208), including its use of the SMTP `MAIL FROM` identity and the fallback to the SMTP `HELO` identity when the envelope sender is empty. DKIM is different. A sending system adds a cryptographic signature to selected message fields, and a receiver retrieves the public key from DNS to verify it. [RFC 6376 defines DKIM signatures and verification](https://www.rfc-editor.org/rfc/rfc6376.html). A valid DKIM signature can establish that the signed content has not changed in transit after signing, subject to the protocol's verification result. DMARC evaluates whether SPF or DKIM passed with a domain aligned to the visible From domain. [RFC 9989 defines DMARC authentication, alignment, and policy discovery](https://datatracker.ietf.org/doc/html/rfc9989), with reporting split into RFC 9990 and RFC 9991. That aligned identity check is what makes DMARC useful against unauthorized use of a domain in the visible From field. ![The three records that stop domain spoofing](/images/figures/stop-email-spoofing-records.webp "1200x512") *Source: Palisade.* For the broader protocol context, see the [DMARC learning hub](/learning/dmarc). ## When email spoofing prevention changes The right response depends on the evidence you have and whose domain is involved. For a message you received, inspect the actual sender address and the delivered message's authentication results. A sender can use a legitimate third-party service, and a public DNS record cannot explain what happened to one delivered message. If the message requests money, credentials, a changed payment destination, or an unexpected attachment, verify the request through a known separate contact method before taking action. For the header-by-header walkthrough and the visible signals that give a forgery away first, see [how to spot an email sender spoof](/learning/email-address-spoofing-prevention). For a domain you operate, publish and maintain authentication records, then validate real traffic. DMARC protection is incomplete if a legitimate sending service lacks an aligned SPF or DKIM pass. A `p=reject` policy is also not a universal instruction that every receiver must apply identically. RFC 9989 allows receivers to apply local policy when handling DMARC results. Use this decision rule: - If you have a suspicious delivered email, preserve it and inspect its full headers or message source. Check the displayed address, reply address, and authentication results before replying, opening an attachment, or following a link. - If you have a domain name and need to inspect its published authentication posture, look up the public DMARC record. - If you administer the domain, validate four layers before treating spoofing controls as working: authoritative and public DNS, the sending vendor's status, a real delivered message from the production path, and DMARC aggregate reports once they accumulate. - If the sender uses a different but confusingly similar domain, DMARC for your domain cannot authenticate that lookalike domain. Report and block the specific message through your mail provider's process, then investigate the impersonating domain separately. > Do not move a domain to `p=quarantine` or `p=reject` until important production senders have been identified and tested. A policy change can affect legitimate mail that still fails DMARC alignment. ## A worked authentication result A delivered message can contain an `Authentication-Results` header that records a receiver's authentication evaluation. [RFC 8601 defines the Authentication-Results header field](https://www.rfc-editor.org/rfc/rfc8601.html). The following is illustrative only, not evidence from a real message: ```text Authentication-Results: receiver.example; spf=pass smtp.mailfrom=mailer.yourdomain.com; dkim=pass header.d=yourdomain.com; dmarc=pass header.from=yourdomain.com ``` This example indicates that SPF passed for `mailer.yourdomain.com`, DKIM passed for a signature using `yourdomain.com`, and DMARC passed for the visible From domain `yourdomain.com`. A result such as `dmarc=pass` is useful evidence for that message at that receiver. It does not prove every future message will pass, that every sender using the domain is authorized, or that the message belongs in the inbox. Inspect the whole message context, including the recipient's known relationship with the sender and the request being made. ![Decision flow for responding to a suspicious email, separating delivered-message evidence from a domain's published authentication record](/images/editorial/what-is-email-spoofing-and-how-can-you-prevent-it/what-is-email-spoofing-and-how-can-you-prevent-it-spoofing-decision-flow.webp "1200x829") *Source: Palisade.* ## What to do next If you received a suspicious message, use the email client's reporting controls and contact the apparent sender through a known phone number, internal directory, or previously verified address. Do not use reply details supplied by the suspicious message to perform that verification. For context on impersonation that does not always involve a forged domain, read [what email impersonation is and how to prevent it](/learning/what-is-email-impersonation-and-how-can-you-prevent-it-in-2025). If you manage the visible From domain, inventory each service that sends mail for it. For each service, verify the vendor's current authentication status, send a test message through the exact production path, and inspect its delivered headers. Then use DMARC aggregate reports to identify sources and authentication or alignment failures over time. Email filtering can add another layer for inbound mail, but it does not replace domain authentication. See [how email filtering prevents spam](/learning/what-is-email-filtering-software-services-prevent-spam). Use a public record check when your question is, "What DMARC policy does this domain publish right now?" It is not the right tool for proving the origin of an individual suspicious message. ## Common issues when stopping email spoofing ### Why is my own legitimate mail failing DMARC? Almost always an alignment or missing-source problem. A stream can pass SPF or DKIM but use a different domain in the check than the one in the From address, so it fails alignment. Or a sender you forgot, such as a CRM or a payroll tool, was never added to SPF or given a DKIM key. Read the domain's aggregate reports, identify the source, and either authenticate it or route it through an authorized path before moving to `p=reject`. ### Why does SPF keep returning a permerror? The record exceeds the 10-DNS-lookup limit, or more than one SPF record exists on the domain. Each `include`, `a`, and `mx` mechanism costs a lookup. Consolidate providers, remove unused `include` entries, or use SPF flattening, and make sure exactly one `v=spf1` record exists. The full fix is in [How do I fix SPF permerror: too many DNS lookups](/learning/how-do-i-fix-spf-permerror-too-many-dns-lookups). ### Attackers are spoofing a lookalike domain, not mine. Does DMARC help? DMARC only protects the exact domain it is published on. A cousin domain like `yourdomaìn.com` or `yourdomain-support.com` is a different domain and needs its own defenses: register obvious variants, monitor for new registrations, and pair enforcement with user training. DMARC stops exact-domain spoofing. It cannot police names you do not own. For the full picture, see [how lookalike domains bypass DMARC](/learning/how-do-lookalike-domains-bypass-dmarc). ### I set p=reject and forwarded mail is bouncing. What happened? Forwarding breaks SPF because the forwarder becomes the sender, and it can break DKIM if the forwarder rewrites the message. If DKIM survives forwarding intact, DMARC still passes through it, which is why DKIM matters so much. Check the headers of a bounced message to see which check failed, and confirm the forwarding path signs or re-signs correctly. ## Check the DMARC record behind a spoofing concern Run the domain that appears in the visible From address through Palisade's checker to inspect its currently published DMARC record and policy tags. Compare the result with the delivered message's authentication results before deciding whether the message is an unauthorized spoof or a separate impersonation attempt. [Check the DMARC record](/tools/dmarc) A public DNS check cannot prove who sent one message, repair an unauthenticated sender, show a receiver's private filtering decision, or monitor later changes to a domain's sending sources. When an IT team or MSP needs to work through reports across domains, Palisade is agentic DMARC software. It analyzes DMARC aggregate-report data, identifies sending sources and authentication or alignment issues, and creates prioritized remediation tickets. It can propose the next policy step from the evidence, while a human reviews the evidence and applies any change. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=existing-content-migration&utm_content=what-is-email-spoofing-and-how-can-you-prevent-it) Palisade does not autonomously change your DMARC policy, prove every future message will authenticate, or control a receiver's final mailbox decision. For how spoofing extends beyond email (IP and caller-ID variants included) see [What is Spoofing? Spoofing Attacks Explained](/learning/what-is-spoofing). ## Sources and further reading - [RFC 5321: Simple Mail Transfer Protocol](https://datatracker.ietf.org/doc/html/rfc5321) - [RFC 7208: Sender Policy Framework](https://datatracker.ietf.org/doc/html/rfc7208) - [RFC 6376: DomainKeys Identified Mail](https://www.rfc-editor.org/rfc/rfc6376.html) - [RFC 9989: Domain-based Message Authentication, Reporting, and Conformance](https://datatracker.ietf.org/doc/html/rfc9989) - [RFC 8601: Authentication-Results header field](https://www.rfc-editor.org/rfc/rfc8601.html) ## Frequently asked questions ### Is email spoofing the same as phishing? No. Email spoofing is the falsification or misuse of email identity details. Phishing is a broader social-engineering attack that tries to obtain information or prompt a harmful action. A phishing message may use spoofing, but it can also use a lookalike domain or a compromised legitimate account. ### Can a display name be spoofed? Yes. A display name is presentation text chosen by the sender. Check the full address and, for a delivered message, the authentication results and message headers before treating a familiar name as proof of identity. ### Does SPF alone prevent email spoofing? No. SPF evaluates authorization for the envelope sender or SMTP HELO identity. It does not by itself require alignment with the visible From domain. DMARC adds that alignment requirement when SPF or DKIM passes. ### Does DKIM prevent someone from copying my display name? No. DKIM verifies a signature on a message and identifies the signing domain. It does not prevent an attacker from choosing a similar display name or registering a lookalike domain. ### Can DMARC stop all fraudulent email? No. DMARC helps receivers detect unauthorized use of the domain in the visible From field when the message fails aligned SPF and DKIM. It cannot stop fraud sent from lookalike domains, compromised accounts, or domains outside your control. --- # What is Microsoft's equivalent to Google Postmaster Tools? Canonical: https://www.palisade.email/learning/what-is-microsoft-s-equivalent-to-google-postmaster-tools > Microsoft's closest Google Postmaster alternatives are SNDS and JMRP. Compare the Outlook.com data they provide and learn where their coverage stops. Microsoft does not offer one feature-for-feature equivalent to Google Postmaster Tools. For mail sent to Outlook.com consumer addresses, the closest Microsoft services are Smart Network Data Services (SNDS), which provides IP-level sending and filtering data, and the Junk Mail Reporting Program (JMRP), which provides complaint feedback. They do not expose a universal reputation dashboard for every Microsoft 365 recipient domain. ## Quick takeaways - SNDS and JMRP are Microsoft's closest equivalent to Google Postmaster Tools for Outlook.com consumer mail. - SNDS is organized around authorized sending IP addresses, ranges, or autonomous system numbers. - JMRP reports when participating Outlook.com users mark mail as junk. - SNDS data does not reveal a corporate Microsoft 365 tenant's private filtering or mailbox decisions. - A missing SNDS report can mean the IP did not meet Microsoft's reporting threshold. It is not a positive delivery result. - Microsoft 365 message trace is tenant administration data, not a public sender-reputation service. ## How Microsoft's postmaster services work [Microsoft Smart Network Data Services](https://substrate.office.com/ip-domain-management-snds/snds) helps authorized senders understand traffic and reputation signals associated with sending IPs at Outlook.com. The same site provides access to JMRP feedback-loop settings. SNDS is closest to the operational role of [Google Postmaster Tools](/learning/email-questions/what-is-google-postmaster-tools), but the services use different scopes. Google Postmaster Tools presents Gmail data for verified domains and IPs where enough data is available. Microsoft SNDS centers on the authorized sending IP and Outlook.com consumer infrastructure. Microsoft's [SNDS FAQ](https://substrate.office.com/ip-domain-management-snds/SNDS/FAQ) says authorization can begin with responsibility for an IP address, IP range, or autonomous system number. Microsoft uses reverse DNS, RDAP, and routing information to identify acceptable authorization contacts. Once access is approved, SNDS can show daily activity and filtering information for qualifying traffic. Microsoft documents fields such as SMTP recipient and DATA command counts, recipient counts, aggregate filter results, complaint information, malware or virus observations, open-proxy status, and current IP status. ![Microsoft SNDS landing page showing data, IP-status, access-request, and JMRP navigation](/images/editorial/what-is-microsoft-s-equivalent-to-google-postmaster-tools/microsoft-snds-public-landing.png "1280x800") *Source: [Microsoft Smart Network Data Services](https://substrate.office.com/ip-domain-management-snds/snds), checked 2026-07-29.* JMRP has a narrower job. It gives participating senders feedback when Outlook.com users report their messages as junk. A complaint report is evidence to investigate the campaign, consent record, sending IP, and authenticated domain. It should also trigger suppression for the affected mail stream where the sender can identify the recipient safely. ## When the answer changes The answer changes with the recipient infrastructure and the evidence available. For `outlook.com`, `hotmail.com`, `live.com`, and `msn.com` recipients, SNDS and JMRP are the relevant Microsoft-owned services. They provide Microsoft consumer-mail telemetry, subject to authorization and reporting availability. For a single business recipient using Microsoft 365, SNDS is not the equivalent. That organization controls its own Exchange Online policies, allow or block decisions, quarantine, and message trace. An outside sender needs evidence from the recipient organization's administrator, such as a message trace result or the exact SMTP response. For a mixed audience, separate the results by recipient domain and sending path. A corporate domain can use Microsoft 365, another gateway, or a different provider over time. MX records and delivered-message headers identify the current path more reliably than an assumption based on the organization's brand. Use this decision rule: ![Decision records for selecting Microsoft sender telemetry based on recipient domain and available evidence](/images/editorial/what-is-microsoft-s-equivalent-to-google-postmaster-tools/microsoft-postmaster-decision-records.webp "1200x533") *Source: Palisade.* - Microsoft consumer mailbox traffic: check SNDS and JMRP, then compare the data with SMTP responses and campaign logs. - One corporate Microsoft 365 recipient: request tenant-side trace, quarantine, or filtering evidence. - Authentication question before sending: inspect the published DNS records with [Palisade's free email tools](/tools), then test a real message through the production path. - Cross-provider delivery issue: group evidence by receiver, IP, visible From domain, return path, DKIM domain, campaign, and time window. ## A worked SNDS evidence record SNDS data is useful when it is read as IP-level evidence rather than an inbox-placement score. Microsoft's FAQ says daily mail and spam data might be absent when an IP sent fewer than 100 messages that day. Microsoft also says its aggregate filter result does not directly represent final Inbox or Junk folder placement because recipient settings and safelists can affect handling. Use an incident record like this when comparing SNDS with your own send logs: ```text Recipient service: Outlook.com consumer mail Sending IP: 192.0.2.25 UTC send window: 2026-08-11T08:00:00Z to 2026-08-11T12:00:00Z Visible From domain: yourdomain.com Return-path domain: bounce.yourdomain.com DKIM d= domain: yourdomain.com SNDS observation: record the reported daily filter result and complaint data Message evidence: preserve the SMTP response and redacted Authentication-Results header ``` This is illustrative only. Do not publish recipient addresses, unredacted headers, complaint samples, account identifiers, or other customer data. A reported filter color can indicate that an IP needs attention, but it does not identify the responsible customer on a shared pool or prove why one campaign was filtered. JMRP reports, sender logs, and message-level evidence narrow that question. ## What to do next Start with the evidence you have. If you control the sending IP, request SNDS access and enroll in JMRP where appropriate. Export or record the relevant date range before changing campaigns, lists, or infrastructure. Then compare the SNDS view with the exact IP and UTC window in the sending platform. If an ESP controls the IP, ask the provider whether it is authorized for SNDS and JMRP, which complaint feedback it passes to customers, and how it maps complaints to an account. The provider may have the only direct access to shared-IP telemetry. If the issue affects one delivered message, collect the SMTP result and a redacted copy of its `Authentication-Results` header. [RFC 8601 defines the Authentication-Results field](https://www.rfc-editor.org/rfc/rfc8601.html), which records an authentication service's results. DNS checks can confirm a published record, but they cannot prove the application signed the message or that Microsoft made a particular mailbox decision. For the broader operating context, see Palisade's [email deliverability learning hub](/email-deliverability). ## Track the senders behind recurring Microsoft signals SNDS can show an IP-level signal, while JMRP can show that recipients reported messages as junk. Neither view inventories every production sender using your visible From domain or proves that future messages will align. [Palisade's DMARC Agent can analyze DMARC aggregate-report data, identify sending sources and authentication or alignment issues, and create prioritized remediation tickets.](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=existing-content-migration&utm_content=what-is-microsoft-s-equivalent-to-google-postmaster-tools) A human reviews the evidence and applies any DNS or DMARC policy change. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=existing-content-migration&utm_content=what-is-microsoft-s-equivalent-to-google-postmaster-tools) Palisade does not change a receiver's private reputation decision, guarantee inbox placement, or prove that every future message will authenticate. For a provider-specific implementation of these authentication checks, see [What sender data does Yahoo Postmaster provide?](/learning/what-sender-data-does-yahoo-postmaster-provide). ## Sources and further reading - [Microsoft Smart Network Data Services](https://substrate.office.com/ip-domain-management-snds/snds) - [Microsoft SNDS FAQ](https://substrate.office.com/ip-domain-management-snds/SNDS/FAQ) - [RFC 8601: Message Header Field for Indicating Message Authentication Status](https://www.rfc-editor.org/rfc/rfc8601.html) - [Palisade email deliverability learning hub](/email-deliverability) ## Frequently asked questions ### Is SNDS the same as Google Postmaster Tools? No. SNDS is Microsoft's closest equivalent for Outlook.com consumer traffic, but it is primarily IP-focused and differs from Google's Gmail-focused domain and IP dashboards. ### Does SNDS cover every Microsoft 365 recipient domain? No. SNDS covers Outlook.com consumer infrastructure. It does not expose private filtering, quarantine, or tenant-level message-trace data for every organization that uses Microsoft 365. ### Does a green SNDS filter result mean messages reached the inbox? No. Microsoft says the aggregate filter result does not directly represent final Inbox or Junk folder delivery. Recipient settings and safelists can change the final handling. ### Can an ESP customer access SNDS directly? Only if the customer can satisfy Microsoft's authorization requirements for the sending IP, range, or autonomous system number. On a shared IP pool, the ESP may be the authorized party. ### What should I do with a JMRP complaint? Suppress the recipient from the relevant mail stream when you can identify it safely, then investigate the campaign, consent, acquisition source, send time, sending IP, and authentication evidence. --- # What is a whaling attack and how can you stop it? Canonical: https://www.palisade.email/learning/what-is-whaling-attack-cybersecurity > What is a whaling attack? It is targeted phishing aimed at senior leaders. Learn how to verify requests and reduce email impersonation risk. A whaling attack is a targeted phishing attack aimed at high-ranking people, such as executives, finance approvers, and board members. The attacker uses a convincing request, often involving money, credentials, or sensitive data, to make the target act quickly. Stop it with independent verification for high-risk requests, email protections that detect spoofing and impersonation, and domain authentication that makes direct spoofing of your domain harder. ## Quick takeaways - Whaling is targeted phishing against high-ranking members of an organization, according to [CISA's definition](https://www.cisa.gov/sites/default/files/2023-05/tic_3.0_cloud_use_case_508c.pdf). - A message can impersonate a real person with a lookalike domain that still passes SPF, DKIM, and DMARC. - Finance and payroll changes need verification through known contact details outside the email thread. - DMARC helps receivers evaluate mail that falsely claims to use your domain, but it does not stop compromised accounts or lookalike domains. - Microsoft 365 can apply impersonation protection and spoof controls, with the final action determined by your configured policy. - Review suspicious requests before replying, opening attachments, following links, or changing payment details. ## How a whaling attack works Whaling relies on trust and context. An attacker may pose as a chief executive, legal adviser, supplier, or finance leader and send an urgent request for a transfer, payroll file, password, or login approval. [NIST's phishing guidance](https://www.nist.gov/itl/smallbusinesscyber/guidance-topic/phishing) identifies urgency, requests for sensitive information, and suspicious sender addresses as common warning signs. It recommends verifying a request through known contact information, rather than contact details supplied in the message. The attacker can use several sending paths: - A forged message that claims to be from your domain. SPF, DKIM, and DMARC help a receiving system evaluate this type of spoofing. - A lookalike domain or similar display name. [Microsoft's impersonation guidance](https://learn.microsoft.com/en-us/defender-office-365/anti-phishing-mdo-impersonation-insight) distinguishes this from domain spoofing because a lookalike can be a real registered domain and may pass normal authentication checks. - A compromised mailbox that sends from a legitimate account. Authentication checks may pass because the account is authorized to send. - A reply-chain or supplier compromise that makes the request appear to continue an expected conversation. That distinction matters. A passing authentication result supports identity checks for the domain it evaluates. It does not prove that the human sender intended the request, that a vendor's bank details are unchanged, or that an executive approved a payment. For related defenses against forged use of your own domain, see [how to stop spoofing attacks](/learning/what-exactly-is-spoofing-and-how-can-you-stop-it). ## When the answer changes The right control depends on what the message is trying to make someone do. - If the message requests a payment, bank-detail change, payroll export, or gift-card purchase, pause the workflow and verify the request through a known phone number, an established vendor portal, or another approved channel. Do not use a phone number, link, or reply address supplied in the message. - If the sender address is close to an executive's or supplier's address, treat it as potential impersonation even if email authentication passes. Lookalike-domain mail can pass SPF, DKIM, and DMARC for the attacker's domain. - If the message appears to be from your own domain but authentication fails, inspect the sender domain's SPF, DKIM, and DMARC posture and preserve the original message for the mail-security team. - If the message came from a real internal or supplier mailbox, treat it as a possible account compromise. Domain authentication cannot establish whether an authorized account holder sent a particular request. Microsoft documents that its anti-phishing protections can use spoof intelligence, protected users and domains, mailbox intelligence, and configured actions such as Junk Email or quarantine. A [composite authentication failure does not automatically block a message](https://learn.microsoft.com/en-us/defender-office-365/anti-phishing-protection-spoofing-about), so teams should review the configured actions and false positives before relying on them for executive-targeted mail. > Do not change payment instructions based only on an email, including a message that appears to come from a known executive or supplier. Use an independently established approval path. For the broader problem of someone posing as a trusted person, read [what an impersonation attack is and how to stop it](/learning/what-is-an-impersonation-attack-and-how-can-you-stop-it). For a prevention-focused walkthrough of the same threat, see [how to prevent whaling phishing](/learning/what-is-whaling-phishing-and-how-can-you-prevent-it). ![Decision flow for a suspected whaling request, from identifying the requested action to independent verification and email-security review](/images/editorial/what-is-whaling-attack-cybersecurity/what-is-whaling-attack-cybersecurity-whaling-decision-flow.webp "1200x829") *Source: Palisade.* ## A worked whaling-request check Use a short, repeatable check before approving a high-risk request. This is a decision rule for the recipient and approver, not proof that a message is safe. ```text Request: Change supplier bank details before payment 1. Do not reply to the email or use its links or phone number. 2. Contact the supplier through a known number or approved portal. 3. Confirm the change with the established supplier contact. 4. Require the documented approval for the payment change. 5. Preserve the original message and report it for review. ``` A request that clears this check may still need the normal financial approval process. A request that fails it should not be completed through the email thread. If the suspected message is available, retain the original message and its full headers for the mail-security team. The visible display name alone is weak evidence. The sending address, reply address, links, attachment type, authentication results, and mail-gateway verdict can help establish what happened. Do not forward sensitive payroll data, credentials, or unredacted customer information while reporting the message. Whaling also requires controls beyond email filtering. Restrict who can approve payment changes, keep supplier contacts current in an approved system, and make escalation paths clear for executives and finance staff. Targeted email attacks are hard to stop because an attacker can tailor a request to a real role or relationship. A documented verification process gives staff a safe alternative to acting on urgency. ## What to do next with the evidence you have If you have a suspicious email, report it through your organization's mail-security process and verify any business request independently. If the sender used a lookalike address or a compromised account, investigate that incident through your mail platform and identity controls. If the message claims to come from your domain, inspect the public authentication records for that exact domain. [Palisade's email security score](/tools/email-security-score) checks publicly visible DMARC, SPF, and DKIM-related posture to help identify a missing or weak domain control. A public DNS check cannot prove that the suspicious message used your production sending path, that an individual message passed authentication, that a mailbox account is uncompromised, or that a receiver will block future phishing. ## Keep spoofed use of your domain visible A one-time record check can show what your domain publishes today, but it does not identify every legitimate sender that still fails alignment or show later changes to your sending inventory. That is the ongoing gap after a whaling attempt uses your brand as the lure. Palisade is agentic DMARC software that analyzes DMARC aggregate-report data, identifies sending sources and authentication or alignment issues, and creates prioritized remediation tickets. It can propose when a domain appears ready for a stronger DMARC policy, while a human reviews the evidence and applies any DNS change. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=email_authentication&utm_content=what-is-whaling-attack-cybersecurity) Palisade does not stop a compromised mailbox, repair every sender automatically, or guarantee that a receiver will block a whaling message. ## Sources and further reading - [CISA: TIC 3.0 Cloud Use Case glossary](https://www.cisa.gov/sites/default/files/2023-05/tic_3.0_cloud_use_case_508c.pdf) - [NIST phishing guidance for small businesses](https://www.nist.gov/itl/smallbusinesscyber/guidance-topic/phishing) - [Microsoft Defender for Office 365 anti-phishing protection](https://learn.microsoft.com/en-us/defender-office-365/anti-phishing-protection-about) - [Microsoft Defender for Office 365 anti-spoofing protection](https://learn.microsoft.com/en-us/defender-office-365/anti-phishing-protection-spoofing-about) - [Microsoft Defender for Office 365 impersonation insight](https://learn.microsoft.com/en-us/defender-office-365/anti-phishing-mdo-impersonation-insight) ## Frequently asked questions ### Is whaling the same as spear phishing? No. Whaling is a targeted phishing attack aimed at high-ranking people in an organization. [Spear phishing](/learning/what-is-spear-phishing) is a broader term for phishing tailored to a specific person, team, or organization. ### Can DMARC stop every whaling attack? No. DMARC can help receivers evaluate mail that falsely claims to use your domain, especially when SPF or DKIM does not align with the visible From domain. It does not stop a lookalike domain, a compromised mailbox, or a fraudulent request sent through a legitimate account. ### Should an executive verify a wire request by replying to the email? No. Verify the request through a known contact method or approved vendor portal. A reply can go to an attacker-controlled address or continue a compromised conversation. ### Can a lookalike domain pass email authentication? Yes. A lookalike domain can have valid SPF, DKIM, and DMARC records for that domain. Authentication can therefore pass even when the domain was chosen to resemble a trusted organization. ### What should employees preserve after reporting a whaling email? Preserve the original message and its full headers when your reporting process allows it. Avoid forwarding credentials, sensitive attachments, private keys, tokens, or unredacted customer data outside approved incident-response channels. --- # What is whaling phishing and how can you prevent it? Canonical: https://www.palisade.email/learning/what-is-whaling-phishing-and-how-can-you-prevent-it > Whaling phishing is a targeted impersonation attack against executives or people who can approve payments. Learn how to verify and reduce the risk. Whaling phishing is a targeted impersonation attack that uses the authority of an executive or other senior official to pressure someone into sending money, disclosing sensitive information, or changing business details. It is a form of [spear phishing](/learning/what-is-spear-phishing), often associated with business email compromise. Prevent it with an out-of-band verification rule for high-risk requests, account security, and email authentication that limits spoofing of your own domain. ## Quick takeaways - Whaling phishing targets executives, executive assistants, finance staff, and other people who can approve sensitive actions. - A message can impersonate a leader through a lookalike address, a forged From domain, or a compromised legitimate mailbox. - Urgency, secrecy, changed payment details, and a request to bypass normal approval are warning signs. - Verify payment, banking, credential, and sensitive-data requests through a known independent channel. - SPF, DKIM, and DMARC help protect a domain from direct spoofing, but they do not prove that a message is safe. - A compromised mailbox can send mail that passes email authentication. ## How whaling phishing works Whaling uses information about an organization to make a fraudulent request appear routine. An attacker may use public staff pages, press releases, social posts, vendor names, or details exposed in an earlier email compromise. The message then poses as a chief executive, finance leader, legal contact, supplier, or another trusted authority. The [US Cybersecurity and Infrastructure Security Agency's guidance on business email compromise](https://www.cisa.gov/topics/cyber-threats-and-advisories/malware-phishing-and-ransomware) describes attacks that use social engineering to induce a payment or disclosure. In a whaling attempt, the authority of the impersonated person is part of the lure. The recipient may be told that a wire transfer, vendor-bank change, document release, or credential reset must happen immediately and without normal review. The sender address deserves inspection, but it is only one signal. A lookalike domain can resemble a legitimate company domain. A reply-to address can direct responses elsewhere. A compromised real mailbox can contain correct signatures, prior conversation history, and internal vocabulary. Email authentication addresses one part of this problem. [RFC 9989 defines DMARC](https://datatracker.ietf.org/doc/html/rfc9989) as a way for a domain owner to publish handling preferences for mail that fails DMARC validation. DMARC passes when SPF or DKIM passes with a domain aligned to the visible From domain. It can reduce successful [direct spoofing](/learning/what-exactly-is-spoofing-and-how-can-you-stop-it) of a protected domain, but it does not determine whether a request is authorized or whether a legitimate account has been compromised. For broader controls around malicious email, use the [Palisade email security learning hub](/learning). For the attack mechanics behind these requests, see [what a whaling attack is and how to stop it](/learning/what-is-whaling-attack-cybersecurity). ## When the answer changes The right response depends on what the suspicious message asks you to do and how it was sent. Treat the request as high risk when it asks for any of these actions: - A wire transfer, gift-card purchase, invoice payment, or vendor-bank detail change. - Credentials, multifactor authentication codes, tax records, payroll details, contracts, or customer data. - A new communication channel, especially one supplied by the message itself. - An exception to an approval, purchasing, or confidentiality process. - Immediate action combined with secrecy or pressure. Use this decision rule: if the message would cause money, access, or sensitive information to leave the organization, confirm the request with the alleged sender through a contact method already known to the organization. Do not call a number, use a link, or reply to an address supplied in the suspicious email. > Do not process a changed bank account or high-value payment from an email instruction alone. Confirm it through the approved vendor contact and the organization's existing approval process. A message that fails DMARC is useful evidence of potential spoofing when it uses your domain, but a passing result does not approve the transaction. The [FBI's business email compromise guidance](https://www.ic3.gov/PSA/2023/PSA230609) also recommends independently verifying payment-related requests and changes to payment instructions. ![Decision flow for a suspected whaling request, from identifying a high-risk action to independent verification and authentication review](/images/editorial/what-is-whaling-phishing-and-how-can-you-prevent-it/what-is-whaling-phishing-and-how-can-you-prevent-it-whaling-decision-flow.webp "1200x829") *Source: Palisade.* ## A worked whaling verification example A finance employee receives a message that appears to be from the CFO. It requests an urgent supplier payment and includes new bank details. The message may look plausible, but the request changes where money will go. Use the evidence in this order: ```text Request: Urgent payment to a new bank account Known risk: Payment instruction changed by email Independent check: Call the CFO or supplier using a number in the approved directory Authentication check: Inspect the visible From domain and message authentication results Decision: Hold payment until the independent contact confirms the request ``` If the visible From address uses your organization's domain, inspect the delivered message headers. [RFC 8601 defines the Authentication-Results header field](https://www.rfc-editor.org/rfc/rfc8601.html), which can report results such as `spf`, `dkim`, and `dmarc`. Those results can help establish whether the message authenticated as expected, but they must be read alongside the exact From domain and the known-channel verification. A simplified header pattern might look like this: ```text Authentication-Results: receiver.example; spf=pass smtp.mailfrom=yourdomain.com; dkim=pass header.d=yourdomain.com; dmarc=pass header.from=yourdomain.com ``` This pattern is not a safety verdict. It may be consistent with legitimate mail, but it can also appear when an attacker controls a legitimate account or an authorized sending path. The payment remains on hold until the independent confirmation is complete. ## What to do after a suspected whaling message First, preserve the message and report it through the organization's security process. Do not forward it externally with sensitive content exposed. Security staff may need the original message, its headers, the sender and reply-to addresses, URLs, attachment names, and the action requested. Next, use the established communication channel to verify the request. For a supplier change, contact the supplier through the approved vendor record. For an executive request, call or message the executive through the company directory or another known channel. Then review the applicable controls: - Require separate approval for high-value payments and vendor-bank changes. - Use phishing-resistant multifactor authentication where the organization supports it, particularly for executive, finance, administrator, and email accounts. - Review mailbox forwarding rules, delegated access, OAuth applications, and recent sign-in activity after suspected account compromise. - Train employees on the organization's exact verification process, not only on visual signs in suspicious messages. - Publish and maintain SPF, DKIM, and DMARC for domains that send mail. The [guide to preventing phishing attacks](/resources-post/the-ultimate-guide-to-preventing-phishing-attacks-expert-tips-and-strategies) covers the wider prevention program. If you have a domain but no suspicious message header, a public record lookup can establish what it publishes today. It cannot prove the production sending path, a receiver's private decision, or whether future mail will authenticate. ## Check the DMARC record that protects your domain Inspect the domain's published DMARC record before assuming direct spoofing is blocked. Compare the public result with the sender domain in the suspicious message and with the authentication results from the delivered message. [Check the DMARC record](/tools/dmarc) A public DMARC check cannot confirm that an executive approved a payment, identify a compromised mailbox, or explain why a specific receiver accepted a message. ## Track the sending sources that still need remediation If your domain sends mail through several business applications, a record check alone cannot show which legitimate sources fail alignment or whether a new sender later appears. Palisade is agentic DMARC software that analyzes DMARC aggregate-report data, identifies sending sources and authentication or alignment issues, and creates prioritized remediation tickets. It can propose the next DMARC policy step, while your team reviews the evidence and applies any DNS change. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=email_authentication&utm_content=what-is-whaling-phishing-and-how-can-you-prevent-it) Palisade does not authorize payments, change a DMARC policy without human action, or prove that every future message is legitimate. ## Sources and further reading - [CISA: Business email compromise](https://www.cisa.gov/topics/cyber-threats-and-advisories/malware-phishing-and-ransomware) - [FBI IC3 public service announcement on business email compromise](https://www.ic3.gov/PSA/2023/PSA230609) - [RFC 9989: Domain-based Message Authentication, Reporting, and Conformance](https://datatracker.ietf.org/doc/html/rfc9989) - [RFC 8601: Message Header Field for Indicating Message Authentication Status](https://www.rfc-editor.org/rfc/rfc8601.html) - [Palisade DMARC checker](/tools/dmarc) ## Frequently asked questions ### Is whaling phishing the same as business email compromise? No. Whaling phishing is a targeted form of phishing that impersonates or targets a senior figure. Business email compromise is a broader category of fraud that can include executive impersonation, supplier impersonation, and compromised email accounts. ### Can a whaling email pass DMARC? Yes. A message sent from a compromised legitimate mailbox can pass SPF, DKIM, and DMARC. Authentication results help assess domain authorization, but they do not confirm that a payment request is legitimate. ### Should employees reply to verify an executive request? No. A reply can go to an attacker-controlled address or remain inside a compromised conversation. Verify through a phone number, directory entry, or separate trusted channel that existed before the request. ### Does DMARC stop lookalike-domain attacks? No. DMARC protects the domain that publishes the DMARC policy. It does not stop an attacker from registering a different domain that resembles the organization's name. Recipients still need to inspect unusual requests and follow verification controls. ### What should happen after a suspected whaling payment is sent? Contact the financial institution and the organization's incident-response and finance teams immediately. Preserve the message and related records, then follow the organization's fraud-response process. The FBI advises prompt reporting of business email compromise incidents through its reporting channels. --- # Why do corporations struggle with DMARC enforcement? Canonical: https://www.palisade.email/learning/why-do-corporations-struggle-to-move-from-dmarc-awareness-to-enforcement > DMARC enforcement stalls when corporations lack verified sender ownership, message evidence, and a safe policy-change process and rollback criteria. Corporations struggle with DMARC enforcement because a published DNS policy does not identify every legitimate system that sends mail for a domain. Before requesting quarantine or rejection, a team needs evidence that important sending paths pass aligned SPF or DKIM, clear ownership for exceptions, and a controlled way to reverse a harmful change. DMARC aggregate reports help uncover that evidence over time, while a single DNS lookup cannot. ## Quick takeaways - DMARC enforcement applies after DMARC evaluation, which requires aligned SPF or DKIM authentication for the visible From domain. - A `p=reject` record is a receiver-handling request, not proof that every receiver will make the same final delivery decision. - Large organizations often separate DNS control from ownership of marketing, support, finance, and acquired-business mail systems. - A vendor dashboard, public DNS lookup, delivered message, and aggregate report answer different questions. - A safe policy change needs named owners, message evidence, an exception decision, and a rollback condition. - Unknown senders should be investigated before a stronger DMARC policy is requested. ## Why enforcement becomes an evidence and ownership problem [DMARC](https://datatracker.ietf.org/doc/html/rfc9989) lets a domain owner publish a policy for messages that fail DMARC validation. A message can pass DMARC when SPF or DKIM passes and aligns with the domain in the visible From field. The receiving system then applies its own handling decision while considering the domain owner's requested policy. That protocol sequence explains why record publication is only one part of enforcement. DNS can show that a domain publishes `p=none`, `p=quarantine`, or `p=reject`. It cannot show whether every production application uses an aligned identifier, whether a provider is using the intended configuration, or whether a business-critical sender is still unknown. Corporations commonly have several teams and providers sending mail under related domains. The DNS administrator may control the DMARC record, while another team owns an invoice system, a marketing platform, a support platform, or a recently acquired business application. This is an operating problem, not a protocol defect. A delivered message provides a more specific evidence layer. [RFC 8601 defines the Authentication-Results header field](https://www.rfc-editor.org/rfc/rfc8601.html), which can report the authentication evaluation associated with a message. Inspecting that header from the actual production path helps a team distinguish a configured domain from a message that authenticated as intended. Mailbox-provider requirements increase the cost of leaving this work unresolved. For example, [Google's sender guidelines](https://support.google.com/a/answer/14229414) require bulk senders to Gmail to authenticate email and publish a DMARC record, with enforcement expectations for applicable senders. Those requirements do not inventory a corporation's senders or resolve its ownership gaps. For the protocol context behind the policy, start with the [DMARC learning hub](/learning/dmarc). This page addresses the organizational question that follows: when is the evidence strong enough to request stricter handling? ## When the answer changes A corporation can move closer to enforcement when each important sending path has a known purpose, accountable owner, and evidence from the real production configuration. It should pause when a material sender remains unknown or cannot be tested safely. Use this Palisade-authored readiness framework: - Proceed when the approved sender inventory matches the material sources found in DMARC aggregate-report data, each exception has an owner, and important paths have current message evidence. - Investigate when aggregate reports identify a source absent from the inventory, or when a provider says a domain is configured but a production message does not show the expected authentication result. - Pause a policy increase when a business-critical sender lacks an owner, a team cannot produce a same-path test message, or the rollback decision has not been approved. - Scope the change to the evidence available. A result for one domain or subdomain does not automatically establish readiness for another. The four evidence layers should remain separate: - **DNS:** Query the authoritative DNS service and at least one public resolver to confirm the intended policy is published. - **Vendor:** Confirm the sender's current domain-authentication status in the provider's documented interface. - **Message:** Send and inspect a real message through the exact production path, including its raw headers or Authentication-Results data. - **DMARC:** Review aggregate reports after data accumulates, then reconcile the sources with the approved inventory. A green vendor status is useful, but it is not a delivered-message check. A passing public lookup is useful, but it does not establish continuous production state, a receiver's private filtering decision, or future inbox placement. ## A worked DMARC enforcement readiness record Use one review record for each domain before proposing a stronger policy. This is an internal operating checklist, not a DNS record and not evidence that a domain is ready by itself. ```text Domain: yourdomain.com Current policy: Record the current DMARC TXT value and lookup time DNS owner: Team authorized to approve DNS changes Known senders: Production applications and providers using this domain Message evidence: Redacted delivered-message headers for each important path DMARC evidence: Aggregate-report sources reconciled to the sender inventory Open exceptions: Business purpose, accountable owner, and review date Rollback: Prior approved record and the condition for restoring it Decision: Proceed, pause, or remediate before the next policy stage ``` ![Readiness checklist showing ownership, DNS, message, DMARC-report, exception, and rollback evidence before a DMARC policy increase](/images/editorial/why-do-corporations-struggle-to-move-from-dmarc-awareness-to-enforcement/why-do-corporations-struggle-to-move-from-dmarc-awareness-to-enforcement-readiness-checklist.webp "1200x639") *Source: Palisade.* The key decision is whether the team understands the consequences of a failure. [RFC 9989's DMARC policy model](https://datatracker.ietf.org/doc/html/rfc9989) does not make `p=reject` a declaration that all mail is safe. It requests handling for messages that fail DMARC under the applicable policy. If a legitimate source is still failing, stronger enforcement can affect that source's mail. > Do not increase a DMARC policy because a public record lookup looks correct. The lookup does not identify every production sender or prove how a receiving mailbox provider will handle a future message. ## What to do next with the evidence you have If you only have a domain name, inspect the currently published policy with the [DMARC checker](/tools/dmarc). Compare the result and lookup time with the approved DNS change record. This can reveal a mismatch between the intended policy and the public record. If you have access to a sending platform, ask its owner for the provider's current authentication status and a test message sent through the same production configuration. Inspect the delivered message headers before treating the vendor status as completion. If you have DMARC aggregate-report data, reconcile each source with the approved sender inventory. Assign an owner to unmatched sources. The source may be a legitimate system that needs alignment work, a system that should use another domain, or unauthorized use that requires an internal response. Aggregate data makes the source visible. It does not make the business decision for the team. If the inventory, ownership, and evidence are in place, use [How can you simplify the journey to DMARC enforcement?](/learning/how-can-you-simplify-the-journey-to-dmarc-enforcement) to organize a staged policy proposal and validation plan. ## Inspect the policy before assigning ownership gaps Check the public DMARC record first, then use that result as a shared artifact when the DNS owner and sending-system owners review the gaps. [Check the DMARC record](/tools/dmarc) A public-record check cannot identify every production sender, repair authentication alignment, monitor later DNS changes, or prove a receiver's handling of an individual message. For ongoing evidence across domains and sending sources, Palisade is agentic DMARC software that analyzes DMARC aggregate-report data, identifies sending sources and authentication or alignment issues, creates prioritized remediation tickets, and proposes the next policy step for human review. It does not autonomously apply a DMARC policy change. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=existing_content_migration&utm_content=why-do-corporations-struggle-with-dmarc-awareness-to-enforcement) ## Sources and further reading - [RFC 9989: Domain-based Message Authentication, Reporting, and Conformance](https://datatracker.ietf.org/doc/html/rfc9989) - [RFC 8601: Message Header Field for Indicating Message Authentication Status](https://www.rfc-editor.org/rfc/rfc8601.html) - [Google Email sender guidelines](https://support.google.com/a/answer/14229414) - [Palisade DMARC checker](/tools/dmarc) ## Frequently asked questions ### Does publishing `p=none` mean a corporation is ready for DMARC enforcement? No. `p=none` publishes a valid DMARC policy with no requested handling preference for failures. It does not prove that legitimate sending sources are known, aligned, or ready for a stronger policy. ### Can a corporation move directly to `p=reject`? Only when the organization has evidence for the sending paths within the proposed scope and an approved way to respond if a legitimate source fails. RFC 9989 defines `p=reject` as a requested receiver policy after DMARC failure, so the receiving system still makes the final handling decision. ### Are DMARC aggregate reports enough to approve enforcement? No. Aggregate reports can help identify patterns and sending sources, but they should be reconciled with sender ownership and message-level evidence from important production paths. A report does not replace a real delivered-message check. ### Does a passing DMARC check prove that all email will reach the inbox? No. A public DMARC check can show the published DNS record. It cannot prove every sender's configuration, a receiver's private filtering decision, or future inbox placement. ### Who should own a DMARC enforcement change? The DNS owner should control the approved record change, but each material sending path also needs an accountable application or business owner. The change decision should name the parties responsible for evidence, exceptions, and rollback. --- # Secure email server: the standards that define one Canonical: https://www.palisade.email/learning/secure-email-server > Secure email server requirements come from RFC 3207 STARTTLS, RFC 8461 MTA-STS, RFC 8460 TLS-RPT, and SPF, DKIM, and DMARC. See what to publish and verify. A secure email server is one that implements the standards controlling SMTP transport and sender identity: TLS negotiated with STARTTLS (RFC 3207), an enforceable transport policy through MTA-STS (RFC 8461), delivery visibility through TLS-RPT (RFC 8460), and sender authentication through SPF, DKIM, and DMARC. IT teams, MSPs, and anyone else running a mail transfer agent are affected, since none of these six controls is optional if the goal is a server that resists downgrade attacks and address spoofing. ## Quick takeaways - STARTTLS (RFC 3207, February 2002) negotiates TLS inside an existing SMTP session, but a compliant server must not require it for local delivery, which makes plain STARTTLS opportunistic and downgradable. - MTA-STS (RFC 8461, September 2018) lets a domain publish a policy telling senders to skip delivery when TLS negotiation, MX matching, or certificate validation fails, with three modes: none, testing, and enforce. - TLS-RPT (RFC 8460, September 2018) reports successful and failed TLS session counts back to the sending domain through a separate TXT record. - SPF (RFC 7208), DKIM (RFC 6376), and DMARC (RFC 9989) authenticate who may send as a domain; none of the three encrypts the SMTP transport or the message body. - DMARC is a Proposed Standard on the IETF Standards Track since RFC 9989 (May 2026) replaced the Informational RFC 7489; DKIM sits a level higher still, at Internet Standard STD 76. ## Who is affected? This framework affects anyone who operates the server side of SMTP: internal IT teams running their own mail transfer agent, MSPs managing infrastructure for client domains, and administrators of a hosted or self-managed mail platform. It governs the server and the DNS records tied to a sending domain, not end-user encryption tools such as S/MIME, which [NIST SP 800-177 Rev. 1](https://csrc.nist.gov/pubs/sp/800/177/r1/final) treats as a separate control layer for message-level confidentiality. A team looking for that narrower, client-side question should see [how to send secure email in Outlook](/learning/how-can-i-send-secure-email-using-outlook) instead. The standards apply at the domain level regardless of who operates the sending software. A domain that outsources outbound mail to a third-party service still needs its own SPF, DKIM, DMARC, and, where the provider does not already publish one, MTA-STS and TLS-RPT records, because these are DNS declarations tied to the domain rather than settings inside a vendor's dashboard. STARTTLS is different: it is a property of whichever mail transfer agent answers connections on port 25 or the submission ports 587 and 465, so an organization that still receives mail on its own server has to configure STARTTLS on that server directly. None of RFC 3207, RFC 8461, RFC 8460, RFC 7208, RFC 6376, or RFC 9989 names a required vendor, operating system, or mail server product. Each is protocol level: it defines what a compliant server or DNS zone does, not which software runs it. A [secure email gateway](/learning/email-security-gateway) can implement several of these controls on a team's behalf, but the underlying DNS records still have to be published for the sending domain either way. ## What are the requirements? A secure email server, in verifiable protocol terms, implements six controls: negotiated transport encryption, an enforceable transport policy, transport reporting, and three sender-authentication records. Each comes from its own RFC. ![Six standards a secure email server implements, the record each one publishes, and what it does](/images/editorial/secure-email-server/secure-email-server-decision-table.webp "1200x733") *Source: Palisade.* ### Negotiate TLS with STARTTLS before message content moves [RFC 3207](https://www.rfc-editor.org/rfc/rfc3207) defines STARTTLS as an SMTP service extension that lets a server and client "use TLS... to provide private, authenticated communication over the Internet." The EHLO keyword and the command are both STARTTLS, and the server signals readiness with the reply "220 Ready to start TLS": ```text EHLO client.example.com 250-mail.yourdomain.com Hello client.example.com 250-STARTTLS 250 OK STARTTLS 220 Ready to start TLS ``` Illustrative session only; hostnames are examples. After negotiation, both sides discard everything learned in the plaintext phase, and the client should send EHLO again so the session restarts cleanly inside TLS, per RFC 3207 section 4.2. RFC 3207 also states that a publicly referenced SMTP server "MUST NOT require use of the STARTTLS extension in order to deliver mail locally." Baseline STARTTLS is opportunistic by standard, not by accident, which makes it downgradable: an attacker who strips the "250 STARTTLS" line from the plaintext response, or rewrites the resolved MX record, can force a fallback to plaintext or redirect delivery entirely. [RFC 8461](https://www.rfc-editor.org/rfc/rfc8461) names that exact scenario as its motivation. ### Publish an MTA-STS policy so senders can enforce TLS instead of trusting it MTA-STS lets a mail service provider declare that it can receive TLS-secured SMTP and tell sending systems what to do when TLS cannot be negotiated. The policy has two published parts: a TXT record at `_mta-sts.<domain>` and a policy file fetched over HTTPS at a fixed path. ```text _mta-sts.yourdomain.com. IN TXT "v=STSv1; id=20260101000000Z" ``` ```text version: STSv1 mode: testing mx: mail.yourdomain.com max_age: 604800 ``` Illustrative record and policy file; the `id` value and `mx` host are examples, not values to publish as shown. MTA-STS defines exactly three modes. In enforce mode, RFC 8461 states that senders "MUST NOT deliver the message to hosts that fail MX matching or certificate validation or that do not support STARTTLS." In testing mode, failures are reported through TLS-RPT but mail still delivers. In none mode, the domain is treated as having no active policy. MTA-STS relies on certificates from a public certificate authority and does not require DNSSEC. DANE covers the same goal through DNSSEC instead, and RFC 8461 is explicit that MTA-STS validation must never override a failing DANE validation. ### Publish a TLS-RPT record to see which connections actually used TLS [RFC 8460](https://www.rfc-editor.org/rfc/rfc8460) defines TLS-RPT as "a reporting mechanism and format by which sending systems can share statistics and specific information about potential failures" with recipient domains. A domain enables reporting with a TXT record whose `rua` tag names the report destination: ```text _smtp._tls.yourdomain.com. IN TXT "v=TLSRPTv1; rua=mailto:tlsrpt@yourdomain.com" ``` Illustrative record; the reporting mailbox is an example address. Aggregate reports carry per-policy counts, including `total-successful-session-count` and `total-failure-session-count`, so an operator can see both working and failing TLS delivery instead of assuming STARTTLS worked because nothing bounced. ### Publish SPF, DKIM, and DMARC records so receivers can verify the sender [RFC 7208](https://www.rfc-editor.org/rfc/rfc7208) has domains publish DNS records authorizing which hosts may use their name in the "MAIL FROM" or "HELO" identities; receivers test that authorization during the SMTP transaction. [RFC 6376](https://www.rfc-editor.org/rfc/rfc6376), Internet Standard STD 76, "permits a person, role, or organization to claim some responsibility for a message by associating a domain name with the message," validated through a cryptographic signature and a public key published at the signer's domain. [RFC 9989](https://www.rfc-editor.org/rfc/rfc9989.html) lets the owner of an Author Domain state a "message handling preference regarding failed validation" and "request reports about the use of the domain name" on top of SPF and DKIM, published as a DNS TXT record at `_dmarc.<domain>`. RFC 9989 is Standards Track, so the Informational caveat that applied to RFC 7489 no longer holds. Though a Proposed Standard still sits below DKIM's Internet Standard status. ```text yourdomain.com. IN TXT "v=spf1 include:_spf.yourdomain-provider.com -all" selector1._domainkey.yourdomain.com. IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqh..." _dmarc.yourdomain.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com" ``` Illustrative records only. The sending platform generates the real DKIM selector and key, and a DMARC report processor generates the real `rua` address; do not publish these example values on a live domain. ## When does the requirement take effect? None of these documents ships with a sender-specific enforcement deadline. Mailbox-provider deadlines and volume thresholds are set independently by each provider and change on their own schedule, which is a separate, provider-specific check rather than a fact fixed by the protocol itself. What each RFC does fix is its own publication date and standards status: - RFC 3207 (STARTTLS): Standards Track, February 2002. - RFC 6376 (DKIM): Internet Standard STD 76, September 2011. - RFC 7208 (SPF): Standards Track, April 2014. - RFC 9989 (DMARC): Standards Track, May 2026; obsoletes the Informational RFC 7489 of March 2015. - RFC 8460 (TLS-RPT): Standards Track, September 2018. - RFC 8461 (MTA-STS): Standards Track, September 2018. - NIST SP 800-177 Rev. 1: Final publication, February 2019. A server built today still has to satisfy all six regardless of publication order. MTA-STS and TLS-RPT were designed specifically to close the gap STARTTLS's opportunistic design leaves open; SPF, DKIM, and DMARC address a separate problem, message origin, that transport encryption does not touch. For the transport-encryption side of this list in more depth, see [email transport security](/learning/infrastructure). ## How do I implement the requirement? The following is implementation guidance built from the standards above, not a requirement any single RFC states in this order. ![Five-step implementation for email server security standards](/images/editorial/secure-email-server/secure-email-server-implementation.webp "1200x813") *Source: Palisade.* ### 1. Enable STARTTLS and install a valid certificate On the mail transfer agent, turn on STARTTLS support and install a certificate issued by a publicly trusted certificate authority on ports 25, 587, and 465 as applicable. Confirm the server responds with "220 Ready to start TLS" and that it discards the prior plaintext session state, restarting with a fresh EHLO inside the encrypted channel, per RFC 3207 section 4.2. ### 2. Publish the MTA-STS TXT record and HTTPS policy file, starting in testing mode Publish the `_mta-sts` TXT record and the policy file at the fixed `.well-known` path, with `mode: testing` first. Testing mode reports failures through TLS-RPT without blocking delivery, so a misconfigured policy does not silently drop mail. ### 3. Publish a TLS-RPT record before changing the MTA-STS mode Add the `_smtp._tls` TXT record with a working `rua` address before moving MTA-STS out of testing. Reports arrive as aggregated counts, so allow enough sending volume to accumulate meaningful successful and failed session totals. ### 4. Publish SPF, DKIM, and DMARC records for the sending domain Publish SPF at the domain apex, DKIM keys under the selector the sending platform assigns, and a DMARC record at `_dmarc` with a reporting address, starting DMARC at `p=none` so aggregate reports arrive before any policy change can affect delivery. ### 5. Move MTA-STS to enforce once TLS-RPT reports come back clean After TLS-RPT aggregate reports show consistent successful-session counts with no unexplained failures, change the MTA-STS mode to enforce. From that point, RFC 8461 requires that compliant senders not deliver to hosts that fail MX matching, certificate validation, or STARTTLS. ## How do I validate compliance? Confirm each record resolves the way the standard requires before assuming the server behind it is compliant. [Look up the DNS records for the sending domain](/tools/dns-lookup) to see the current SPF, DKIM, DMARC, MTA-STS, and TLS-RPT TXT records exactly as a public resolver returns them, and compare that output against the record shapes above. A resolved TXT record only proves the record is published. It does not prove that a specific message used STARTTLS, matched the MTA-STS policy, or passed SPF and DKIM alignment. For that, pull the raw headers from an actual delivered message and check the TLS version reported in the `Received` header chain along with the `Authentication-Results` line the receiving server adds for SPF, DKIM, and DMARC. Then watch the TLS-RPT and DMARC aggregate reports over at least one full reporting cycle, since RFC 8460 aggregate reports carry separate successful and failed session counts and a single day's data can hide an intermittent downgrade. > A green certificate indicator on a vendor dashboard is not the same as a delivered-message check. Confirm TLS and authentication on a real message before treating a server as compliant. ## Confirm what the sending domain actually publishes Working through six RFCs does not show what is live on a specific domain today. [Look up the DNS records for your sending domain](/tools/dns-lookup) to see the current SPF, DKIM, DMARC, MTA-STS, and TLS-RPT TXT records as public resolvers return them, before changing anything on the mail server itself. A DNS lookup confirms what is published. It does not show which real sending sources are failing SPF or DKIM alignment against a published DMARC record, and that gap only closes once aggregate reports accumulate. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=infrastructure_transport&utm_content=secure-email-server) to have DMARC aggregate reports parsed into which sources are aligned and which are not, so a move from `p=none` toward enforcement is based on that evidence rather than a guess. Palisade analyzes DMARC aggregate-report data and proposes the next policy step; it does not configure STARTTLS, MTA-STS, or TLS-RPT on the mail server itself, and a human still reviews and applies any policy change it proposes. ## Sources and further reading - [RFC 3207: SMTP Service Extension for Secure SMTP over TLS](https://www.rfc-editor.org/rfc/rfc3207) - [RFC 8461: SMTP MTA Strict Transport Security (MTA-STS)](https://www.rfc-editor.org/rfc/rfc8461) - [RFC 8460: SMTP TLS Reporting](https://www.rfc-editor.org/rfc/rfc8460) - [RFC 7208: Sender Policy Framework (SPF)](https://www.rfc-editor.org/rfc/rfc7208) - [RFC 6376: DomainKeys Identified Mail (DKIM) Signatures](https://www.rfc-editor.org/rfc/rfc6376) - [RFC 9989: Domain-based Message Authentication, Reporting, and Conformance (DMARC)](https://www.rfc-editor.org/rfc/rfc9989.html) ## Frequently asked questions ### What is the safest email server to use? No independently verified ranking establishes one email server product as safest. What is verifiable is whether a given server implements the controls covered here: STARTTLS negotiated per RFC 3207, an MTA-STS policy in enforce mode per RFC 8461, TLS-RPT reporting per RFC 8460, and SPF, DKIM, and DMARC records per RFC 7208, RFC 6376, and RFC 9989. Compare candidate servers or providers against that checklist rather than a marketing claim. ### What is the most hacked email provider? No source used in this article provides a verified, comparable incident dataset across providers, so this cannot be answered with a ranked list. A more useful question for an IT team is whether its own domain publishes DMARC with a `rua` reporting address and an MTA-STS policy in enforce mode, since aggregate and TLS reports show real attempts against that specific domain rather than an industry-wide incident count. ### How do I set up a secure email server? Setup follows the four standards this article defines, in order: enable STARTTLS on the mail transfer agent with a valid TLS certificate (RFC 3207), publish an MTA-STS TXT record and HTTPS policy file starting in testing mode (RFC 8461), publish a TLS-RPT record so failures are visible before enforcing anything (RFC 8460), then publish SPF, DKIM, and DMARC records for the sending domain (RFC 7208, RFC 6376, RFC 9989). Move MTA-STS to enforce only after TLS-RPT reports show clean delivery. ### What is the safest email service? Not answerable as a single ranked choice from public, verifiable data. A defensible comparison checks whether a given service publishes and enforces the same controls covered here: STARTTLS by default, an MTA-STS policy set to enforce rather than testing or none, active TLS-RPT reporting, and SPF, DKIM, and DMARC records with a DMARC policy stronger than `p=none`. A service that publishes all five is verifiably ahead of one that does not, even without an industry-wide ranking. --- # What does 'all' mean in an SPF record? Canonical: https://www.palisade.email/learning/spf-all-mechanism > What does 'all' mean in an SPF record? Learn how SPF all matches senders, what qualifiers mean, and how to validate the final policy correctly. In an SPF record, `all` is the final mechanism that matches every sending IP address not matched earlier in the record. Its qualifier sets the SPF result for those remaining senders: `-all` returns Fail, `~all` returns SoftFail, `?all` returns Neutral, and a bare `all` returns Pass. RFC 7208 defines `all` as a mechanism that always matches, so it belongs at the end of the record. ## Quick takeaways - The SPF `all` mechanism always matches when evaluation reaches it. - SPF checks mechanisms from left to right and stops at the first match. - `-all` produces an SPF Fail result for senders not authorized earlier in the record. - `~all` produces SoftFail, while `?all` produces Neutral. - A bare `all` has the default `+` qualifier and produces Pass for every sender. - Any SPF mechanism written after `all` cannot be evaluated. ## Who is affected? The `all` mechanism affects every domain that publishes an SPF policy, including domains that send through a hosted mailbox provider, an email service provider, a helpdesk, a payroll system, or an application server. SPF evaluates the SMTP client IP address against the domain used in the SMTP `MAIL FROM` command, or against the `HELO` or `EHLO` domain when `MAIL FROM` is empty. [RFC 7208's SPF evaluation rules](https://datatracker.ietf.org/doc/html/rfc7208#section-4.3) require a receiver to evaluate mechanisms in order and stop when one matches. `all` does not identify a legitimate sender. Earlier mechanisms such as `ip4`, `ip6`, `a`, `mx`, and `include` do that work. The final `all` mechanism supplies the default result for everything left over. This rule applies only to SPF's identity checks. SPF Pass alone does not prove that the visible `From:` domain is authenticated. DMARC evaluates whether SPF or DKIM aligns with that visible domain. The [email authentication learning hub](/learning) explains how SPF, DKIM, and DMARC fit together. ## What are the requirements? ### `all` always matches RFC 7208 defines `all` as a mechanism that always matches. A receiver reaches it only if no previous mechanism has matched the sending IP address. ```text v=spf1 include:_spf.example.net ip4:192.0.2.10 -all ``` In this illustrative record, a sender authorized by `include:_spf.example.net` or using `192.0.2.10` receives SPF Pass before evaluation reaches `-all`. Every other sender reaches `-all` and receives SPF Fail. > Do not publish this example unchanged. Your email providers generate their own include domains, IP addresses, and sending configuration. ![SPF evaluation order showing authorized mechanisms first and the final all mechanism as the default result](/images/editorial/spf-all-mechanism/spf-all-mechanism-records.webp "1200x600") *Source: Palisade.* Because `all` matches every remaining sender, it must be last. [RFC 7208 section 5.1](https://datatracker.ietf.org/doc/html/rfc7208#section-5.1) states that mechanisms after `all` will never be tested. ### The qualifier determines the SPF result An SPF mechanism can have a qualifier. RFC 7208 defines `+` as Pass, `-` as Fail, `~` as SoftFail, and `?` as Neutral. If a qualifier is omitted, `+` is the default. ```text v=spf1 -all v=spf1 ~all v=spf1 ?all v=spf1 +all ``` `-all` means that an IP address reaching this mechanism receives SPF Fail. It does not instruct every receiver to reject a message. SPF produces an authentication result, and each receiver applies its own mail-handling policy. `~all` means the sender receives SPF SoftFail. RFC 7208 describes SoftFail as a result for a host that is probably not authorized, while allowing the receiver to accept the message. Treat it as a distinct SPF result, not as a guarantee that mail will be delivered or accepted. `?all` produces Neutral. RFC 7208 says Neutral means the domain owner has explicitly stated that nothing can be said about the validity of the identity. `+all`, or a bare `all`, produces Pass for every sender that reaches it. It makes SPF unable to distinguish an unauthorized IP address from an authorized one for that evaluated identity. ### The record has one SPF policy record A domain name must not publish multiple SPF records that begin with `v=spf1`. [RFC 7208 section 3.2](https://datatracker.ietf.org/doc/html/rfc7208#section-3.2) says multiple records cause SPF evaluation to return PermError. Keep authorized sending mechanisms in one record, then put the selected `all` mechanism last. Do not merge policies by appending a second `all` or by adding mechanisms after the existing one. For a focused explanation of individual address mechanisms, see [what `ip4` means in an SPF record](/learning/glossary/spf-ip4) and [what `ip6` means in an SPF record](/learning/glossary/spf-ip6). ## When does the requirement take effect? The controlling standard is [RFC 7208, Sender Policy Framework](https://datatracker.ietf.org/doc/html/rfc7208), published in April 2014. It is a final IETF Standards Track RFC and obsoletes RFC 4408. RFC 7208 does not set a future enforcement date for `all`. The rule that `all` always matches, the qualifier meanings, and the left-to-right evaluation behavior apply whenever a receiver evaluates an SPF record under the RFC. Mailbox providers can make separate decisions about how they use SPF results. Those decisions can change and are outside the `all` mechanism's protocol definition. An SPF Fail from `-all` is evidence that the evaluated sender was not authorized by the SPF policy. It is not, by itself, proof of a particular mailbox-provider action. ## How do I implement the requirement? ### 1. Inventory every system that sends with the domain List each production system that sends mail using the domain's SMTP envelope identity. Include employee mail, marketing platforms, transactional mail, support systems, billing services, and servers under your control. Ask each provider for its documented SPF include domain or the IP ranges it requires. Do not copy another organization's record values. A sender that is absent from the policy will reach the final `all` mechanism. ### 2. Put authorized mechanisms before `all` Add each approved `include`, `ip4`, `ip6`, `a`, or `mx` mechanism before the final policy. Keep the policy as one DNS TXT record beginning with `v=spf1`. ```text v=spf1 include:_spf.yourprovider.example ip4:192.0.2.10 ~all ``` > This is a structural example only. Use the values supplied by your own provider and domain configuration. If your record starts with the required version tag, [the `v=spf1` mechanism guide](/learning/glossary/spf-v-spf1) explains why that tag identifies the TXT record as an SPF policy. ### 3. Select the final qualifier deliberately Publish `~all` on a domain that sends mail, and `-all` on a domain that sends none. Under an enforcing DMARC policy, SoftFail and Fail give a receiver the same non-pass for an unlisted sender, and Fail carries the extra risk that a receiver rejects during the SMTP transaction before DMARC evaluation runs. [SPF hard fail versus softfail](/learning/spf-hardfail-vs-softfail) weighs that decision in full, with the receiver behaviour and the vendor guidance on both sides. Whichever qualifier you publish, an unlisted sender still needs finding and authorizing. The qualifier sets the result for what is left over; it does not complete the inventory. Avoid `+all` and a bare `all` unless you intentionally want every sender to receive SPF Pass. `?all` explicitly publishes Neutral and does not express an authorization boundary. ### 4. Keep DNS lookup limits in view An SPF evaluation can cause DNS lookups through mechanisms such as `include`, `a`, `mx`, `exists`, and `redirect`. [RFC 7208 section 4.6.4](https://datatracker.ietf.org/doc/html/rfc7208#section-4.6.4) limits those DNS-querying terms to 10 during one SPF check. If evaluation exceeds the limit, the result is PermError, so a receiver may never get as far as the result you intended from `all`. Count the evaluated lookup path after each provider change. A syntactically correct final `all` mechanism does not repair a policy that exceeds the lookup limit, because PermError is returned before evaluation reaches it. ## How do I validate compliance? First, inspect the authoritative DNS TXT response and at least one public resolver response. Confirm there is one `v=spf1` policy, every authorized mechanism appears before `all`, and the chosen `all` qualifier is at the end. Then send a real message through each production path. In the delivered message headers, inspect the receiver's `Authentication-Results` field for the SPF result and the identity it evaluated. [RFC 8601](https://www.rfc-editor.org/rfc/rfc8601.html) defines the Authentication-Results header field, including SPF result properties such as `smtp.mailfrom` and `smtp.helo`. Finally, review DMARC aggregate reports after data has accumulated. This is the layer that helps identify production sources and alignment outcomes across real traffic. A DNS lookup confirms the published text. A provider dashboard can confirm its own configuration. Neither one proves that a production message used the intended return-path domain or that every receiver will make the same delivery decision. ## Check the final SPF policy before changing it Before changing the final qualifier, inspect the published record with the [SPF record checker](/tools/spf). Compare the result with message headers from each sender and with DMARC aggregate-report evidence. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=email_authentication&utm_content=spf-all-mechanism) Palisade autonomously analyzes DMARC aggregate-report data, identifies sending sources and SPF or DKIM alignment issues, and creates prioritized remediation tickets for human review. It can help expose senders that a public SPF lookup cannot see across time. A DNS check does not prove the production sending path, continuously monitor later changes, or guarantee a receiver's delivery decision. ## Sources and further reading - [RFC 7208: Sender Policy Framework](https://datatracker.ietf.org/doc/html/rfc7208) - [RFC 7208 section 4.6.4: DNS lookup limits](https://datatracker.ietf.org/doc/html/rfc7208#section-4.6.4) - [RFC 8601: Authentication-Results header field](https://www.rfc-editor.org/rfc/rfc8601.html) - [RFC 9989: Domain-based Message Authentication, Reporting, and Conformance](https://www.rfc-editor.org/rfc/rfc9989.html) ## Frequently asked questions ### Does `all` have to be last in an SPF record? Yes. `all` always matches, and SPF evaluation stops at the first matching mechanism. Any mechanism after `all` is unreachable. ### Does `-all` make receivers reject every unauthorized message? No. `-all` produces an SPF Fail result when an unlisted sender reaches it. The receiving system decides how to use that result under its own mail-handling policy. ### Is a bare `all` the same as `+all`? Yes. The default SPF qualifier is `+`, so `all` produces Pass for every sender that reaches it. ### Should I use `~all` or `-all`? Use `~all` on a domain that sends mail, and `-all` on a domain that sends none. Once DMARC is at `p=quarantine` or `p=reject`, SoftFail and Fail give the same non-pass for an unlisted sender, so Fail adds no protection on a sending domain while still risking SMTP-time rejections of forwarded mail. ### What happens if a record has no `all` mechanism? Evaluation runs off the end of the record without a match and returns Neutral, the same result `?all` states explicitly. A `redirect=` modifier is the exception: it replaces the evaluation with another domain's record, and that record's own `all` mechanism supplies the result. ### Can SPF `all` protect the visible From address? No. SPF evaluates the SMTP envelope identity, usually the `MAIL FROM` domain. DMARC checks whether that authenticated identity aligns with the visible `From:` domain. --- # Why do phishing emails pass SPF and DKIM checks? Canonical: https://www.palisade.email/learning/why-do-phishing-emails-pass-spf-and-dkim > Why do phishing emails pass SPF and DKIM checks? They authenticate a sending domain, not whether a message, brand claim, or sender identity is honest. Yes. Phishing emails can pass SPF and DKIM when the sender legitimately controls the domain and infrastructure those checks authenticate. SPF verifies whether an IP is authorized for the envelope sender domain. DKIM verifies a signature for its signing domain. Neither check decides whether the visible brand claim, display name, link, or request is honest. DMARC adds alignment to the visible From domain, but it cannot protect against a separately registered lookalike domain. ## Quick takeaways - SPF checks authorization for the SMTP envelope sender domain, often shown later as `Return-Path`. - DKIM checks whether a domain identified by the `d=` tag signed an unmodified message. - A phisher can publish valid SPF and DKIM records for a domain they own. - A passing SPF or DKIM result does not prove that the visible From domain is aligned. - DMARC requires an aligned SPF or DKIM pass, but it applies only to the domain being evaluated. - Authentication results are evidence about domain control and message handling, not proof that a message is safe. ## How SPF and DKIM can authenticate a phishing message [SPF](https://datatracker.ietf.org/doc/html/rfc7208) evaluates the domain supplied in the SMTP `MAIL FROM` command, also called the envelope sender. The receiving server checks that domain's published SPF policy to see whether the connecting IP address is authorized. The RFC does not define SPF as a test of the mail client's visible `From:` header. [DKIM](https://www.rfc-editor.org/rfc/rfc6376.html) adds a cryptographic signature to selected message fields and body content. The signature contains a signing domain in the `d=` tag. A receiver retrieves that domain's public key from DNS and can validate that the signed content has not changed in transit. A valid signature can be from any domain whose owner has configured DKIM, including a domain created for a phishing campaign. That distinction explains a common result: an attacker registers `yourcornpany-example.com`, configures its own mail service, and sends a message claiming to be from a finance team. The attacker has not forged their own domain. SPF can pass for the envelope sender, and DKIM can pass for the attacker's signing domain. ![Records card showing the distinct identifiers SPF and DKIM authenticate, alongside the visible From domain that DMARC evaluates for alignment](/images/editorial/why-do-phishing-emails-pass-spf-and-dkim/why-do-phishing-emails-pass-spf-and-dkim-authentication-scope.webp "1200x600") *Source: Palisade.* A delivered message can expose these results in an `Authentication-Results` field. [RFC 8601](https://www.rfc-editor.org/rfc/rfc8601.html) defines this field as a way for a receiving authentication service to report its evaluation. The result is meaningful only in the context of the service that added it. Do not treat a copied header line as proof that another receiver made the same decision. ## When a phishing email changes from an SPF and DKIM pass to a DMARC failure [DMARC](https://datatracker.ietf.org/doc/html/rfc9989) evaluates the visible `From:` domain and requires either SPF or DKIM to pass with an aligned identifier. Alignment means the authenticated SPF domain or DKIM `d=` domain has the required relationship to the visible From domain. A phishing email can therefore pass SPF and DKIM but fail DMARC when its authenticated domains differ from the visible From domain. For example, a message can use an attacker-controlled return path and DKIM signature while showing `billing@yourcompany.com` in the visible From header. SPF and DKIM may each have a technical pass result, but neither aligns with `yourcompany.com`. The answer changes when the attacker sends from a domain they own and also uses that same domain in the visible From header. In that case, the message can pass SPF, DKIM, and DMARC. DMARC confirms that the domain in the visible From header authorized the message. It does not establish that the domain is a legitimate business, that a display name is truthful, or that a linked sign-in page is safe. Use this decision rule: - If SPF or DKIM passes but the authenticated domain differs from the visible From domain, inspect DMARC alignment. - If DMARC passes for a lookalike domain, the message is authenticated as that lookalike domain. Evaluate the sender identity, links, recipient context, and security controls separately. - If mail claims to be from your exact domain but fails DMARC, your published DMARC policy can ask receivers to apply handling to that failure. - If mail uses a different registered domain, your DMARC policy has no authority over that domain. For the broader relationship between the standards, see [Comparing DKIM and SPF Email Standards: Are Both Necessary?](/learning/dkim-vs-spf-difference). ## Worked header example: valid checks, dishonest purpose This illustrative example shows why an authentication pass is not a trust verdict: ```text From: Accounts Payable <invoice@yourcornpany-example.com> Return-Path: <bounce@yourcornpany-example.com> Authentication-Results: receiver.example; spf=pass smtp.mailfrom=yourcornpany-example.com; dkim=pass header.d=yourcornpany-example.com; dmarc=pass header.from=yourcornpany-example.com ``` The domain spelling is the evidence that matters in this example. The sender controls `yourcornpany-example.com`, so it can authorize an IP for SPF, sign mail with DKIM, and publish a DMARC record. None of those checks make it `yourcompany.com`. Compare the exact domains in these fields: - `From:` is the identity most mail clients show to the recipient. - `smtp.mailfrom` is the SPF identity reported in `Authentication-Results`. - `header.d` is the DKIM signing identity reported in `Authentication-Results`. - `header.from` is the domain DMARC evaluates for alignment. > Do not block or allow mail solely because SPF or DKIM says `pass`. A pass can be correct while the message still impersonates a person, business function, or brand through a different domain. ## What to check next, based on the evidence you have If you have a suspicious delivered message, inspect its raw headers in the mail system that received it. Look for the receiver-added `Authentication-Results` field, then compare `smtp.mailfrom`, `header.d`, and `header.from` with the domain the recipient expected. A result from a forwarding service or another intermediary may not reflect the final recipient's assessment. If you only have a domain name, check its published configuration with Palisade's [SPF checker](/tools/spf) and [DKIM checker](/tools/dkim). A public DNS check can show the record a domain publishes. It cannot prove the production message path, identify the party behind a domain, show a receiver's private filtering decision, or predict future inbox placement. If the suspicious email uses your exact domain in the visible From header, review your DMARC policy and the aggregate reports for your domain. The [email security learning hub](/learning) covers the controls that complement authentication when the threat is impersonation rather than a direct domain forgery. ## Track the senders that still fail alignment A header review can explain one phishing message, and public SPF or DKIM lookups can show a domain's published DNS. Neither action inventories every legitimate source that sends as your domain or shows which sources later fail DMARC alignment. Palisade is agentic DMARC software that analyzes DMARC aggregate-report data, identifies sending sources and authentication or alignment issues, and creates prioritized remediation tickets. It can propose the next policy stage when the evidence supports it, while your team reviews the evidence and applies any DNS policy change. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=existing_content_migration&utm_content=why-do-phishing-emails-pass-spf-and-dkim) Palisade does not determine whether an attacker-controlled lookalike domain is trustworthy, guarantee inbox placement, or prove that every future message will authenticate. ## Sources and further reading - [RFC 7208: Sender Policy Framework](https://datatracker.ietf.org/doc/html/rfc7208) - [RFC 6376: DomainKeys Identified Mail](https://www.rfc-editor.org/rfc/rfc6376.html) - [RFC 8601: Authentication-Results header field](https://www.rfc-editor.org/rfc/rfc8601.html) - [RFC 9989: Domain-based Message Authentication, Reporting, and Conformance](https://datatracker.ietf.org/doc/html/rfc9989) - [Comparing DKIM and SPF Email Standards: Are Both Necessary?](/learning/dkim-vs-spf-difference) ## Frequently asked questions ### Can a phishing email pass SPF and DKIM but fail DMARC? Yes. SPF and DKIM can pass for attacker-controlled domains while neither identifier aligns with the visible From domain. DMARC fails when neither authenticated identifier meets the applicable alignment requirement. ### Does a DMARC pass mean an email is safe? No. A DMARC pass shows that SPF or DKIM aligned with the visible From domain. It does not verify the sender's business identity, assess the content, or determine whether a link is malicious. ### Can a lookalike domain publish DMARC? Yes. Any domain owner can publish a DMARC record for their own domain. A strict policy on a lookalike domain authenticates that lookalike domain. It does not make the domain affiliated with the brand it resembles. ### Why does SPF not check the visible From address? SPF was designed to authorize the SMTP envelope sender domain and connecting IP address. The visible From header is evaluated by DMARC alignment when a receiver performs DMARC evaluation. ### Can a valid DKIM signature be used for phishing? Yes. A valid DKIM signature proves that the signing domain authorized the signature and that signed content remained intact. An attacker can validly sign a phishing message with a domain they control. --- # How to configure SPF and DKIM for Chargebee Canonical: https://www.palisade.email/learning/configure-spf-dkim-chargebee > Configure SPF and DKIM for Chargebee by authenticating the custom SMTP provider, connecting it in Chargebee, and validating a real notification. To configure SPF and DKIM for Chargebee notifications, authenticate the sending domain with the custom SMTP provider that will deliver the mail, then connect that provider in Chargebee under **Settings > Configure Chargebee > Email Notifications > Configure SMTP**. Chargebee passes notifications to that SMTP service, so the provider generates the account-specific SPF and DKIM DNS values. The documented path was verified from Chargebee's official documentation. ## Quick takeaways - Chargebee notifications can use Chargebee SMTP or a customer-managed custom SMTP connection. - When Chargebee uses custom SMTP, the SMTP provider supplies the domain-authentication records. - Publish only one SPF policy for a domain, even when several services send mail for it. - DKIM selectors and DNS targets are account-specific. Copy them from the selected SMTP provider account. - A successful connection in Chargebee does not prove that a delivered notification passed SPF, DKIM, or DMARC. - Test a new Chargebee notification through the same configured SMTP path and inspect the received message headers. ## What should I check before configuring Chargebee? Confirm which Chargebee notifications are in scope, such as invoices, payment receipts, renewal reminders, or dunning emails. This guide covers notifications sent by Chargebee through a custom SMTP provider. It does not configure employee mailbox mail, transactional applications that bypass Chargebee, or marketing campaigns sent directly from another platform. You need access to the Chargebee site, permission to configure the SMTP connection, access to the SMTP provider account that sends the notification, and authority to change the sending domain's DNS zone. Chargebee's [custom SMTP instructions](https://www.chargebee.com/docs/billing/2.0/kb/notification/how-can-i-use-a-custom-smtp-for-our-email-notifications-from-chargebee) list the connection fields required for the provider. Decide which visible From domain the notification will use before making DNS changes. Chargebee documents that a mismatch between the configured From address and the authenticated SMTP identity can cause SPF and DKIM problems for DMARC-enabled domains in its [authentication troubleshooting guidance](https://www.chargebee.com/docs/billing/2.0/kb/notification/emails-fail-due-to-spf-and-dkim-settings). > Copy DNS values from the account and domain you are configuring. Do not publish selectors, targets, tokens, or hostnames from another account or from an online example. ## Which setup method should I use? Use Chargebee SMTP only if its authentication approach fits the domain and notification workflow you need. Use custom SMTP when your organization already operates an SMTP provider for the domain and can authenticate that provider's sending path. Chargebee documents both options in its [email notification settings](https://www.chargebee.com/docs/billing/2.0/customers/email-notifications-v2). For a custom SMTP setup, authentication belongs to the SMTP provider, not the Chargebee form. The provider determines whether it needs an SPF include, DKIM TXT record, DKIM CNAME records, a branded return path, or another domain-verification step. Do not assume a provider's example record applies to your account. The available Chargebee documentation does not establish a universal automatic authentication option or dedicated-IP requirement for custom SMTP. Follow the selected SMTP provider's current domain-authentication documentation for those choices. ![Chargebee Email Notifications settings showing the Configure SMTP control used to connect a custom SMTP provider](/images/editorial/configure-spf-dkim-chargebee/chargebee-email-notifications-configure-smtp.png "1600x1088") *Source: [SMTP Configuration](https://www.chargebee.com/docs/billing/2.0/customers/smtp-configuration), checked 2026-07-21.* ## How do I configure SPF and DKIM for Chargebee? ### 1. Open the Chargebee SMTP settings In Chargebee, open **Settings > Configure Chargebee > Email Notifications**, then select **Configure SMTP** and choose the option to send notifications through your own SMTP server. Confirm the site and notification configuration before entering credentials. The SMTP connection determines the production route to test. Record the selected sending domain, From address, SMTP provider, and test recipient with the change request. ### 2. Select and authenticate the sending domain in the SMTP provider Open the SMTP provider account that will receive Chargebee's connection. Add or select the domain used in the visible From address, then use the provider's domain-authentication workflow to generate its DNS records. The provider's values are specific to its account and your domain. Do not reuse an SPF include, DKIM selector, CNAME target, or return-path target from another provider account. A structural example of the DNS records you may receive is below. It is illustrative only. Your SMTP provider generates the real host names and values. **Record type:** `TXT` **Host (illustrative only):** ```text yourdomain.com ``` **Value (illustrative only):** ```text v=spf1 include:spf.smtp-provider.example -all ``` **Record type:** `CNAME` **Host (illustrative only):** ```text selector1._domainkey.yourdomain.com ``` **Value (illustrative only):** ```text selector1.yourdomain.com.dkim.smtp-provider.example ``` > Do not publish these examples. Copy the complete records generated by the SMTP provider for the account and domain you are configuring. ![Example decision flow for Chargebee custom SMTP authentication](/images/editorial/configure-spf-dkim-chargebee/configure-spf-dkim-chargebee-authentication-flow.webp "1200x829") *Source: Palisade.* ### 3. Publish the provider-generated DNS records Add each provider-generated record to the authoritative DNS zone. Before saving an SPF change, inspect the current TXT records at the root domain. [RFC 7208 says a domain must not publish multiple SPF records that are selected during evaluation](https://datatracker.ietf.org/doc/html/rfc7208#section-3.2). Merge an authorized provider mechanism into the existing SPF policy when one already exists. Do not create a second `v=spf1` record. Keep each DKIM selector separate and avoid overwriting an active selector without the provider's rotation procedure. Many DNS providers automatically append the zone name to the host field. If the zone is `yourdomain.com`, entering `selector1._domainkey.yourdomain.com` where the interface expects only a relative host can create a duplicated owner name. Check the final fully qualified DNS name before publishing. ### 4. Enter the SMTP provider credentials in Chargebee Return to the Chargebee SMTP form and enter the hostname, port, username, password, and encryption settings from the SMTP provider. These are connection credentials, not SPF or DKIM values. Keep passwords, API keys, and tokens out of ticket comments, screenshots, and shared header files. Chargebee's custom SMTP documentation identifies these fields as part of the connection configuration. The current interface example below shows the connection form. It does not evidence the correct settings for a particular SMTP provider. ![Chargebee custom SMTP form showing server, credentials, encryption, and port fields](/images/editorial/configure-spf-dkim-chargebee/chargebee-smtp-basic-auth-redacted.png "1656x1184") *Source: [SMTP Basic Authentication](https://www.chargebee.com/docs/billing/2.0/customers/smtp-basic-authentication), checked 2026-07-21.* ### 5. Verify the provider and send a real notification Complete the SMTP provider's own verification workflow after public DNS answers with the expected records. Then send a new invoice, receipt, or other notification from Chargebee to a mailbox where you can inspect raw source. Do not accept a successful Chargebee connection alone as proof of authentication. It proves that Chargebee connected to the configured SMTP service. It does not prove the visible From domain, envelope sender, DKIM signing domain, or receiver result on a delivered notification. ## How does this setup affect DMARC? DMARC passes when SPF passes and aligns with the visible From domain, DKIM passes and aligns with the visible From domain, or both. [RFC 9989 defines DMARC evaluation and aligned identifier requirements](https://datatracker.ietf.org/doc/html/rfc9989). For a Chargebee custom SMTP path, compare three identities in a received notification: - The visible `From:` domain. - The SPF-authenticated envelope sender shown as `smtp.mailfrom`. - The DKIM signing domain shown by the `d=` value in `DKIM-Signature`. An SMTP provider can produce an SPF pass for its own return-path domain without satisfying DMARC for the visible Chargebee From domain. DKIM can satisfy DMARC if its `d=` domain aligns instead. Use Palisade's [DMARC checker](/tools/dmarc) to inspect the published policy. A public DNS result does not prove that Chargebee used the expected SMTP identity for a notification. ## How do I validate the setup? ### Check public DNS Query the authoritative DNS server and at least one public resolver for the exact SPF owner and DKIM selector generated by the SMTP provider. Use the [SPF checker](/tools/spf) to inspect the public SPF policy and the [DKIM checker](/tools/dkim) to spot-check available DKIM records. ```bash dig +short TXT yourdomain.com dig +short CNAME selector1._domainkey.yourdomain.com ``` Public DNS checks show published records. They do not prove the configured Chargebee path, a provider verification state, or future receiver placement. ### Check the vendor status In the SMTP provider, confirm that the selected domain is verified or authenticated according to that provider's documented status. In Chargebee, confirm that the custom SMTP configuration is saved and enabled for the notification workflow. A green provider indicator is not a delivered-message check. It does not show whether Chargebee sent the notification with the expected From address. ### Inspect a delivered message Send a fresh Chargebee notification and open its raw source in the receiving mailbox. Inspect `DKIM-Signature` and the receiver-added `Authentication-Results` field. [RFC 8601 defines Authentication-Results and its receiving-service trust boundary](https://www.rfc-editor.org/rfc/rfc8601.html). Confirm `spf=pass`, `dkim=pass`, and `dmarc=pass` where the receiver reports them. Also confirm that the SPF or DKIM identifier aligns with the visible From domain. Redact recipient addresses, message IDs, and account data before retaining headers with the change record. ### Review DMARC reports After DMARC aggregate reports accumulate, review the Chargebee notification source alongside other senders using the domain. A real-message test proves one observed route. DMARC reporting can reveal recurring alignment failures or sources that were not included in the original change. ## Troubleshooting ### Chargebee saves the SMTP configuration but notifications still fail Check the SMTP provider logs first. Chargebee documents that it cannot inspect customer-managed SMTP logs. Compare the failing notification time with the provider's accepted, deferred, or rejected event and verify the configured hostname, port, encryption, and credentials. ### SPF passes but DMARC fails Inspect `smtp.mailfrom` and the visible From domain. SPF can pass for an SMTP provider return path that does not align with the From domain. Check whether DKIM passes with an aligned `d=` domain, then use the SMTP provider's branded-domain or return-path options if its documentation supports them. ### DKIM is missing or fails on the received notification Confirm the exact selector and record type generated by the SMTP provider. Query the fully qualified selector name, then compare the public answer with the provider status. If DNS is correct, compare the provider's signing configuration and the delivered message. A valid DNS record does not prove that the provider signed this specific Chargebee notification. ### DNS appears correct but the provider cannot verify the domain Check for a duplicated zone suffix, a truncated TXT value, an old conflicting record, or a CNAME placed at an owner that already has another record. Wait only for the provider's documented DNS propagation window before changing records again. ### The notification uses a different From address than expected Compare the Chargebee notification sender setting, the SMTP provider's authenticated domain, and the received `From:` header. Chargebee's troubleshooting guidance identifies From-address mismatch as a risk for SPF and DKIM settings. Correct the configured sender identity or authenticate the domain actually used. ## Check the public authentication posture for the sending domain After validating a real Chargebee notification, run the sending domain through Palisade's [Email Security Score](/tools/email-security-score). It can inspect the public SPF, DKIM, DMARC, and BIMI posture that supports this sending path. The score cannot prove that Chargebee used the configured SMTP identity or that a specific notification passed at a receiver. For recurring visibility after the message test, Palisade analyzes aggregate-report data, identifies observed sending sources and authentication or alignment issues, and creates prioritized remediation tickets for human review. It does not configure Chargebee or the SMTP provider, and it does not guarantee a receiver's handling of future mail. If Chargebee notifications are one of several changing sources on the domain, [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=vendor_setup&utm_content=configure-spf-dkim-chargebee) to review the DMARC evidence and proposed next policy step before a human applies any DNS change. ## Sources and further reading - [Chargebee custom SMTP setup](https://www.chargebee.com/docs/billing/2.0/kb/notification/how-can-i-use-a-custom-smtp-for-our-email-notifications-from-chargebee) - [Chargebee SPF and DKIM troubleshooting](https://www.chargebee.com/docs/billing/2.0/kb/notification/emails-fail-due-to-spf-and-dkim-settings) - [Chargebee email notification settings](https://www.chargebee.com/docs/billing/2.0/customers/email-notifications-v2) - [RFC 7208 SPF record selection](https://datatracker.ietf.org/doc/html/rfc7208#section-3.2) - [RFC 9989 DMARC evaluation](https://datatracker.ietf.org/doc/html/rfc9989) - [RFC 8601 Authentication-Results](https://www.rfc-editor.org/rfc/rfc8601.html) ## Frequently asked questions ### Does Chargebee create SPF and DKIM records for custom SMTP? No. For a custom SMTP connection, the SMTP provider generates the domain-authentication records and Chargebee uses that provider to send notifications. Copy the records from the provider account that owns the sending domain. ### Can I publish a second SPF record for Chargebee? No. A domain must not publish multiple SPF records that can be selected during SPF evaluation. Add the SMTP provider's authorized mechanism to the existing SPF policy when required, then validate the complete record. ### Does a successful Chargebee SMTP connection mean DMARC passes? No. A successful connection does not prove the authentication result on a delivered notification. Inspect a new received message for receiver-added SPF, DKIM, and DMARC results, then confirm alignment with the visible From domain. ### Can DKIM pass while DMARC fails for a Chargebee notification? Yes. DKIM can pass for a signing domain that does not align with the visible From domain. DMARC requires an aligned SPF pass or an aligned DKIM pass. ### Should I use Chargebee SMTP or custom SMTP? No, use custom SMTP when the chosen SMTP provider is the authenticated sender for the domain and you can validate the whole notification path. Use Chargebee SMTP only after confirming its documented authentication approach fits the domain and notification workflow. --- # What is an email security gateway? Canonical: https://www.palisade.email/learning/email-security-gateway > An email security gateway inspects mail before it reaches recipients. It runs in front of the mailbox, alongside it via an API, or inside the platform. An email security gateway is a mail server or cloud service that inspects email before it reaches recipients, then delivers, tags, quarantines, or rejects each message according to policy. Google's Workspace documentation defines the equivalent role plainly: "An inbound mail gateway is a mail server that processes inbound email in some way, before messages are delivered to recipients." Many gateways handle the outbound direction too, applying loss-prevention and encryption policy on the way out. The label describes where a product sits in mail flow, not one fixed architecture. ## Quick takeaways - A gateway inspects mail and applies a delivery, tag, quarantine, or reject decision. Most work on inbound mail, and many also apply policy to outbound. - "Gateway" names a role in mail flow. Three deployment models are common, and they behave differently. - Routing mail through a gateway first changes the source IP your mailbox platform sees, which weakens the platform's own filtering until you configure for it. - Microsoft and Google both publish a setting that recovers the original sender IP from behind a gateway. - A gateway protects mail arriving at your organization. It does nothing about your domain being spoofed to everyone else. - Evaluate a gateway against your documented mail path, not against the product category. ## What an email security gateway does Google describes what email security gateways do in practice: inbound gateways "typically check for spam, archive messages, and scan for harmful attachments or software" (checked 2026-08-14). Whatever the vendor calls it, the functional core is the same. The gateway receives a message, evaluates it against configured policy and detection logic, and produces one of a small set of outcomes. The same applies in reverse where a gateway also handles outgoing mail. Google's outbound equivalent "can block outgoing messages that could be spam or messages with harmful content" and supports "compliance requirements by archiving messages, enforcing policies, and creating an audit trail" (checked 2026-08-14). Those outcomes matter more than the detection method, because they are what your team operates day to day: - **Deliver.** The message reaches the mailbox unchanged. - **Tag.** The message is delivered with a header, subject prefix, or banner marking it suspicious. - **Quarantine.** The message is held, and someone has to release it. - **Reject.** The gateway refuses the message at SMTP time, and the sender gets a bounce. Quarantine is where most of the operational cost lives. A gateway that quarantines well but has no named owner for releases produces a queue nobody drains, and legitimate mail sits in it. ## How an email security gateway works For the common case, where the gateway sits in front of the mailbox, the sequence is the same every time: 1. **DNS points at the gateway.** The MX record for your domain resolves to the gateway's servers rather than to your mailbox platform, so sending servers deliver there first. 2. **The gateway accepts the SMTP connection.** It can refuse the message outright at this point, which is what produces a bounce to the sender rather than a silent quarantine. 3. **It inspects the message.** Envelope and headers, body content, URLs, and any attachments, against configured policy and whatever detection the product provides. 4. **It applies a verdict.** Deliver, tag, quarantine, or reject. 5. **It relays what survives.** Anything cleared is handed to your mailbox platform, which then applies its own filtering to a message that now appears to come from the gateway. Step five is where most deployment problems start, and it is covered in detail below. ## The three deployment models An email security gateway's behavior is set by where it sits in mail flow, not by the category label. ![Three-column comparison of email security gateway deployment models: in front of the mailbox, alongside the mailbox via API, and built into the mailbox platform](/images/figures/email-security-gateway-deployment-models.webp "1200x442") *Source: Palisade.* | Model | MX points at | What the mailbox platform sees | What you must configure | |---|---|---|---| | In front of the mailbox | The gateway | The gateway's IP as the sender | Skip listing, so the platform recovers the real source | | Alongside the mailbox | The mailbox platform | The original sender, unchanged | API access and permissions for the gateway | | Built into the platform | The mailbox platform | The original sender, unchanged | Policy in the platform's own admin console | **In front of the mailbox.** The MX record for your domain points at the gateway. It accepts mail from the internet, inspects it, then relays what survives to your mailbox platform. This is the classic secure email gateway, and it is the model that changes the most about how the rest of your mail stack behaves. **Alongside the mailbox.** The MX record still points at your mailbox platform. The gateway connects through the platform's API, sees messages after they are delivered, and can retract one from a mailbox after the fact. Mail reaches the platform on its original path, so the platform's own filtering sees what it would normally see. **Built into the platform.** No separate product sits in the path at all. Microsoft 365 and Google Workspace both ship inbound filtering, configured in their own admin consoles, with evidence in their own logs. ### What changes when mail routes through a gateway first Put a gateway in front of your mailbox platform and every message arrives from the gateway, not from the sender. Microsoft is direct about the consequence and about whose behavior it is: > As you can see, the message adopts the source IP of the last hop that sits in front of Microsoft 365. The message arrives in Microsoft 365 with a different source IP address. This behavior isn't a limitation of Microsoft 365; it's simply how SMTP works. That single hop degrades everything downstream that reasons about sender reputation. Both major platforms publish a fix, and both require you to configure it. Microsoft calls its version Enhanced Filtering for Connectors, also known as skip listing, which "preserves the source IP address and sender information" (checked 2026-08-14). Microsoft's own before-and-after table shows what it recovers: domain authentication moves from implicit anti-spoof heuristics to "Explicit, based on the source domain's SPF, DKIM, and DMARC records in DNS." In other words, without skip listing, a gateway in front of Microsoft 365 stops your senders' SPF, DKIM, and DMARC results being evaluated the way they otherwise would be. Google's equivalent is the Inbound gateway setting. "Gmail recognizes that inbound gateway IP addresses aren't originating, source IP addresses," and it walks the headers to find the first public IP that is not on your gateway list. There is a trap attached: when the same IP sits in both the Gateway IPs list and an email allowlist, "the allowlist entry doesn't affect message delivery or spam filters." Allowlisting the gateway does nothing, because you have to allowlist the original sender instead. One more configuration detail catches teams out. Microsoft warns that once Enhanced Filtering is on, you must disable any mail flow rule that sets the spam confidence level to `-1` for messages on that connector. That rule is a common shortcut for "trust everything from our gateway," and leaving it in place tells Microsoft 365 to skip filtering entirely on exactly the mail you just went to the trouble of re-evaluating. ## How to evaluate an email security gateway A product name tells you which category a vendor sells into. It does not tell you what will happen to your mail. Evaluate the specific deployment against seven questions: | Verify | Evidence that satisfies it | |---|---| | Where it sits in the production mail path | The vendor's current documentation for your deployment, not a diagram from a sales deck | | Which messages it receives, and which it never sees | Your own mail-flow map, including internal and platform-to-platform traffic | | What each verdict does | The policy configuration, stated as deliver, tag, quarantine, or reject | | Who owns quarantine release | A named owner and a documented escalation path | | Whether the platform still filters correctly behind it | Skip listing configured, confirmed in the platform's own headers | | What evidence it records per message | A retrievable log entry for a test message, and its retention period | | What happens during a gateway outage | The documented behavior, whether mail queues or inspection is bypassed | ![Checklist of seven items to verify before relying on an email security gateway, covering mail path, scope, verdicts, quarantine ownership, platform filtering, evidence, and outage behavior](/images/figures/email-security-gateway-evaluation-checklist.webp "1200x696") *Source: Palisade.* Two of those are skipped most often. **Whether the platform still filters correctly behind it** is the skip-listing question above, and it is invisible until you look for it. **What happens during a gateway outage** decides whether your mail queues or your inspection silently stops, and the answer belongs in your documentation before you need it. For a comparison of the products in this space against suite-native controls, see the [anti-phishing software comparison](/learning/anti-phishing-software). For the operational view of how a gateway fits with authentication and user reporting, see [how secure email gateways protect an organization](/learning/how-secure-email-gateways-protect-organization). ## Where the gateway's protection ends A gateway inspects mail arriving at your organization. That is a real and useful boundary, and it is only half the problem. Nothing a gateway does affects a message that spoofs your domain and is sent to your customers, your suppliers, or your partners. That mail never touches your infrastructure. The only controls that reach it are the ones you publish in DNS for other receivers to evaluate: SPF, DKIM, and the policy you set with DMARC. [RFC 9989 defines DMARC](https://www.rfc-editor.org/rfc/rfc9989.html) as the mechanism a domain owner uses to publish that policy and to ask receivers for reports on what they saw. The two controls answer different questions and neither proves the other is working: - "Can we inspect suspicious mail before our users act on it?" is the gateway's question. - "Can other receivers tell our real mail from someone impersonating us?" is the authentication question. An inbound filter may quarantine a spoofed message even when the sending domain publishes no DMARC policy at all. A DMARC pass may confirm authorized use of a domain while the message still carries a malicious link that needs content evaluation. Related reading: [what phishing is and how it works](/learning/what-is-phishing), [how to stop email spoofing](/learning/what-is-email-spoofing-and-how-can-you-prevent-it), and [what a DMARC failure report tells you](/learning/what-exactly-is-a-dmarc-failure-report-and-why-should-you-care). ## A worked evidence example Suppose someone tells you the organization "has an email security gateway." The useful next question is not whether the label sounds complete. It is which evidence you can actually produce. ```text Question: Does this gateway protect our production mail path? Evidence available: - Product name: Example Email Security - Deployment model: MX points at the gateway - Vendor documentation: Current, tenant-specific - Configuration status: Console shows enabled - Skip listing: Not configured - Delivered message: Test message from a production sender - Security logs: Available for that same message Assessment: - The enabled status supports a configuration claim, nothing more. - The message and its matching logs show one observed path. - Skip listing is unconfigured, so the mailbox platform is filtering against the gateway IP rather than the real sender. - Nothing here establishes handling for every future message. ``` Four kinds of evidence get mixed together in conversations like this: the product name, the vendor's documentation, the current configuration state, and a real message with its logs. Only the last one shows what happened. Even then, one message does not establish continuous coverage or how a different receiver would decide. ## Assess the controls around your email domain A posture check is a reasonable starting point when the open question is broader than one gateway. [Check your email security score](/tools/email-security-score) A public check cannot prove a gateway's deployment, inspect private mail-flow logs, confirm a receiver's decision, or guarantee that future messages will be protected. It reads what your domain publishes and flags areas worth an internal review. ## Keep the outbound half of the problem visible Once a gateway review is done, the inbound side has an owner and a documented path. The outbound side usually does not. Every service that sends as your domains, and every one of them that still fails DMARC alignment, sits outside what a gateway can see. Palisade is agentic DMARC software that analyzes DMARC aggregate-report data, identifies sending sources and authentication or alignment issues, and creates prioritized remediation tickets. It proposes the next policy step from the evidence it has. Your team reviews that evidence and applies any DNS or policy change. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=security&utm_content=email-security-gateway) Palisade does not operate as an email gateway, filter inbound phishing messages, change DMARC policy on its own, or guarantee delivery or inbox placement. ## Sources and further reading - [Microsoft: Enhanced filtering for connectors in Exchange Online](https://learn.microsoft.com/en-us/exchange/mail-flow-best-practices/use-connectors-to-configure-mail-flow/enhanced-filtering-for-connectors) - [Google Workspace: Set up an inbound mail gateway](https://knowledge.workspace.google.com/admin/gmail/advanced/set-up-an-inbound-mail-gateway) - [RFC 9989: Domain-based Message Authentication, Reporting, and Conformance](https://www.rfc-editor.org/rfc/rfc9989.html) - [Palisade email security score tool](/tools/email-security-score) - [Palisade DMARC checker](/tools/dmarc) ## Frequently asked questions ### Is an email security gateway the same as a secure email gateway? Yes. The two names describe the same role, and vendors use them interchangeably along with the abbreviation SEG. Neither name tells you the deployment model, so ask whether the product sits in front of the mailbox, connects through an API, or is built into the mailbox platform. ### Do Microsoft 365 and Google Workspace need a separate email security gateway? Both platforms ship their own inbound filtering, so a separate gateway is an added layer rather than a missing one. The case for adding one rests on gaps you can name in your own environment. If you do add one in front of the platform, configure Microsoft's Enhanced Filtering for Connectors or Google's Inbound gateway setting, or the platform's filtering will evaluate your gateway's IP instead of the real sender's. ### Does an email security gateway replace DMARC? No. A gateway inspects mail coming to you. DMARC, SPF, and DKIM govern how other receivers evaluate mail claiming to come from your domain. A gateway cannot stop your domain being spoofed to someone else's inbox, and DMARC cannot tell you whether an attachment is malicious. ### What is the difference between a secure email gateway and an integrated cloud email security product? Deployment, mostly. A gateway in the traditional sense takes the MX record and inspects mail before your platform ever sees it. Integrated cloud email security, sometimes abbreviated ICES, leaves the MX record alone and connects through the platform's API, which means it sees messages after delivery and can retract one from a mailbox. The second model avoids the source-IP problem described above, because mail reaches the platform on its original path. ### What breaks if I put a gateway in front of Microsoft 365 without configuring it? Microsoft 365 sees your gateway as the source of every message, so IP reputation and anti-spoof heuristics work against the wrong address. Enhanced Filtering for Connectors restores the original source and moves domain authentication to explicit SPF, DKIM, and DMARC evaluation. If you also left a mail flow rule setting the spam confidence level to `-1` on that connector, Microsoft 365 skips filtering on that mail entirely. ### Can a gateway guarantee that no phishing reaches the inbox? No. A gateway applies configured controls to the messages it processes, and a verdict on one message does not predict every future one. Lookalike domains and mail from genuinely compromised accounts pass many automated checks, which is why user reporting and a named investigation owner stay part of the control set. --- # How do I set up SPF and DKIM for SendGrid? Canonical: https://www.palisade.email/learning/how-do-i-set-up-spf-and-dkim-for-sendgrid > SendGrid SPF and DKIM setup: authenticate a domain, publish account-generated DNS records, verify SendGrid, inspect headers, and validate DMARC. To set up SPF and DKIM for SendGrid, open [Settings > Sender Authentication in Twilio SendGrid's Domain Authentication guide](https://www.twilio.com/docs/sendgrid/ui/account-and-settings/how-to-set-up-domain-authentication), select Domain Authentication, enter the domain used in your From addresses, and publish the DNS records SendGrid generates for that account and domain. Then verify the domain in SendGrid and inspect a newly delivered production message. The generated record owners and targets are account-specific. ## Quick takeaways - SendGrid Domain Authentication configures branded sending authentication. It is different from Single Sender Verification. - Automated security uses SendGrid-generated CNAME records, while manual security uses a different generated record set. - Copy each DNS record from the SendGrid account, selected domain, and region you are configuring. - A SendGrid verified status confirms public DNS validation, not the authentication result of every production message. - DMARC needs aligned SPF or DKIM for the visible From domain. - Validate DNS, SendGrid status, a delivered message, and DMARC reports as separate checks. ## What should I check before configuring SendGrid? This setup applies to outbound mail sent through Twilio SendGrid, including API, SMTP relay, and marketing paths that use Domain Authentication. It does not configure dedicated-IP reverse DNS, Inbound Parse, or a mailbox provider's own outbound mail. Confirm which exact domain appears after the `@` in the production From address. Also confirm whether the parent account or a subuser sends the mail. SendGrid's [Domain Authentication instructions](https://www.twilio.com/docs/sendgrid/ui/account-and-settings/how-to-set-up-domain-authentication) require DNS-host selection and a domain before SendGrid generates the record set. You need permission to use the SendGrid account that sends the messages and permission to edit the domain's authoritative DNS zone. Check existing records at the owners SendGrid will generate before making the DNS change. A CNAME cannot share its owner name with another DNS record. > Copy DNS values from the account and domain you are configuring. Do not publish selectors, targets, tokens, or hostnames from another account or from an online example. For a broader explanation of why SPF, DKIM, and DMARC need separate checks, see [what email authentication is and why it matters](/learning/what-is-email-authentication-and-why-does-it-matter). ## Which setup method should I use? Use automated security for the standard SendGrid configuration. SendGrid supplies CNAME delegations for its managed authentication configuration, so its generated targets handle the SPF and DKIM setup behind those records. Keep those CNAMEs intact after verification. Use manual security only when your DNS policy requires direct control of the generated records. The manual path has a different record set, so do not convert values from one mode into another. Select the method before publishing anything, then copy the complete generated set exactly. The documented path is verified from official Twilio documentation. This public tutorial capture illustrates the DNS-host selection state, but it is not evidence of a live account's current generated values. ![SendGrid domain authentication screen showing DNS host selection and setup choices](/images/editorial/how-do-i-set-up-spf-and-dkim-for-sendgrid/sendgrid-dns-host-selection-official-tutorial.webp "709x447") *Source: [Get Started with DMARC and SendGrid](https://www.twilio.com/en-us/blog/developers/community/get-started-sendgrid-dmarc), checked 2026-08-10.* If your current SendGrid screen offers Domain Connect for your DNS provider, use it only when you are authorized to approve the DNS change. Otherwise, complete the normal DNS-host workflow. ## How do I configure SPF and DKIM for SendGrid? ### 1. Open the Sender Authentication settings Sign in to the SendGrid account that sends the mail. Open `Settings > Sender Authentication`, find Domain Authentication, and select `Get Started`, as described in [Twilio's Domain Authentication setup instructions](https://www.twilio.com/docs/sendgrid/ui/account-and-settings/how-to-set-up-domain-authentication). Do not substitute Single Sender Verification for Domain Authentication when you need a branded domain configuration. ### 2. Choose the DNS host and setup options Select the provider that hosts the authoritative DNS zone. Choose the appropriate alternative when the provider is not listed. Keep automated security enabled unless a DNS architecture or change-control requirement calls for manual security. Review the selected domain carefully before continuing. The domain must cover the From addresses used on the production sending path you plan to test. ### 3. Enter the sending domain and generate records Enter the domain requested by SendGrid without a URL scheme or `www`. SendGrid then displays the record owners and values for that setup. The following card shows record roles, not values to publish: ![Example SendGrid DNS record roles for a branded sending domain](/images/editorial/how-do-i-set-up-spf-and-dkim-for-sendgrid/how-do-i-set-up-spf-and-dkim-for-sendgrid-records.webp "1200x533") *Source: Palisade.* ### 4. Publish every SendGrid-generated DNS record With automated security selected, SendGrid provides CNAME records for its return-path and DKIM configuration. Copy the exact owner and target from the Domain Authentication screen. **Return-path and SPF delegation** - **Record type:** `CNAME` - **Host:** account-generated return-path owner - **Value:** account-generated SendGrid target ```text Illustrative only: em1234.yourdomain.com CNAME u12345678.wl.sendgrid.net ``` **First DKIM selector** - **Record type:** `CNAME` - **Host:** account-generated selector under `_domainkey` - **Value:** account-generated SendGrid target ```text Illustrative only: s1._domainkey.yourdomain.com CNAME s1.domainkey.u12345678.wl.sendgrid.net ``` **Second DKIM selector** - **Record type:** `CNAME` - **Host:** account-generated selector under `_domainkey` - **Value:** account-generated SendGrid target ```text Illustrative only: s2._domainkey.yourdomain.com CNAME s2.domainkey.u12345678.wl.sendgrid.net ``` > Do not publish these examples. Generate the real records in the SendGrid account and domain you are configuring, then copy each complete value from that screen. When manual security is selected, publish the TXT and MX records SendGrid generates instead. Do not add a second SPF TXT record to the same domain. SPF permits one effective SPF record, so merge provider-authorized mechanisms into the existing record only when the generated manual instructions require it. Many DNS interfaces append the zone name to a host field. If the zone is `yourdomain.com`, entering `s1._domainkey.yourdomain.com` into a field that automatically appends the zone can create `s1._domainkey.yourdomain.com.yourdomain.com`. Check the final fully qualified owner after saving. This official tutorial image shows the generated-record table format. Its values are redacted because SendGrid records must come from the account you are configuring. ![SendGrid generated domain authentication DNS record table with account-specific values redacted](/images/editorial/how-do-i-set-up-spf-and-dkim-for-sendgrid/sendgrid-generated-dns-records-redacted-official-tutorial.webp "979x349") *Source: [Get Started with DMARC and SendGrid](https://www.twilio.com/en-us/blog/developers/community/get-started-sendgrid-dmarc), checked 2026-08-10.* ### 5. Verify the domain and send a real test message Wait for the records to resolve publicly, then select `Verify` in SendGrid. Twilio's [Sender Authentication troubleshooting guide](https://www.twilio.com/docs/sendgrid/ui/account-and-settings/troubleshooting-sender-authentication) documents DNS propagation, invalid record, duplicate-domain, and underscore-related validation issues. After SendGrid shows a verified result, send a new message through the same API key, SMTP relay, marketing workflow, parent account, or subuser that will send production mail. Use a From address covered by the authenticated domain. ![SendGrid Domain Authentication panel showing a verified domain status](/images/editorial/how-do-i-set-up-spf-and-dkim-for-sendgrid/sendgrid-domain-verified-redacted-official-tutorial.webp "876x154") *Source: [Get Started with DMARC and SendGrid](https://www.twilio.com/en-us/blog/developers/community/get-started-sendgrid-dmarc), checked 2026-08-10.* ## How does this setup affect DMARC? SendGrid SPF and DKIM support DMARC only when an SPF-authenticated identifier or DKIM signing domain aligns with the visible From domain. [RFC 9989 defines DMARC evaluation and identifier alignment](https://www.rfc-editor.org/rfc/rfc9989.html). A DKIM pass for an unrelated `d=` domain does not create a DKIM-aligned DMARC pass. Use Palisade's [DMARC checker](/tools/dmarc) to inspect the published DMARC policy before changing enforcement. A public record check does not prove which SendGrid path sent a message or how a receiving mailbox provider treated it. ## How do I validate the setup? ### Check public DNS Query the exact owners SendGrid generated from both the authoritative DNS server and a public resolver. Confirm the owner names and targets match the SendGrid screen. ```bash dig +short CNAME s1._domainkey.yourdomain.com dig +short CNAME em1234.yourdomain.com ``` Use the [SPF checker](/tools/spf) and [DKIM checker](/tools/dkim) for a public DNS review. Their results do not prove that SendGrid is signing a production message with the expected domain and selector. ### Check the SendGrid status Return to `Settings > Sender Authentication` and confirm the selected domain is verified. This shows SendGrid accepted the expected public DNS configuration. It does not prove that the actual sending path uses that domain for its From address. ### Inspect a delivered message Open the raw source for a message sent after verification. Check `DKIM-Signature` for the expected `d=` signing domain and selector. Then inspect the receiver-added `Authentication-Results` header. [RFC 8601 defines Authentication-Results and explains its trust boundary](https://www.rfc-editor.org/rfc/rfc8601.html). Accept the result only when the trusted receiver result reports `dkim=pass` or an aligned `spf=pass`, and the passing identifier aligns with the visible From domain. Keep a redacted header sample with the DNS change record. ### Review DMARC reports After reports accumulate, review SendGrid traffic separately from other sources using the same domain. Look for SPF and DKIM alignment failures, unexpected sending sources, or traffic that uses a different From domain. A verified SendGrid domain does not inventory every sender that can use your domain. ## Troubleshooting ### SendGrid cannot verify the domain Compare the generated owner and target with the authoritative DNS response. Twilio documents that DNS propagation can take time and advises checking each failing record in its [Sender Authentication troubleshooting guidance](https://www.twilio.com/docs/sendgrid/ui/account-and-settings/troubleshooting-sender-authentication). Do not regenerate records before confirming that the selected SendGrid account, domain, and setup method are still correct. ### The DNS owner has the domain twice Inspect the fully qualified name returned by DNS. If it ends with the zone name twice, remove the duplicated suffix in the DNS provider's host field. This happens when a provider appends the zone automatically. ### The DNS provider rejects an underscore DKIM owner names normally use `_domainkey`. If the DNS interface rejects the underscore, check whether it has a separate validation rule or whether the record was entered into the wrong field. Twilio lists underscore support as a sender-authentication troubleshooting consideration. ### A record conflicts with an existing DNS record Do not overwrite another active CNAME, TXT, or MX record to make SendGrid verify. Find the existing service owner, then choose a different authenticated subdomain or follow the service's rotation or migration process. ### SendGrid is verified but DMARC still fails Inspect the new message's `Authentication-Results`, visible From domain, `DKIM-Signature d=`, and SPF-authenticated domain. The likely issue is alignment or a From-domain mismatch, not DNS reachability. Twilio documents authenticated-domain selection behavior for account and subuser contexts in its [sender authentication troubleshooting documentation](https://www.twilio.com/docs/sendgrid/ui/account-and-settings/troubleshooting-sender-authentication). ## Check the domain beyond SendGrid verification After a verified SendGrid domain and a header check, run Palisade's [Email Security Score](/tools/email-security-score) against the From domain to inspect public DMARC, SPF, DKIM, and related email-security signals. That check is useful because SendGrid's private verification state does not reveal root-domain policy gaps. For ongoing work across domains or clients, Palisade is agentic DMARC software that analyzes DMARC aggregate-report data, identifies sending sources and alignment issues, and creates prioritized remediation tickets. It proposes the next policy stage while a person reviews the evidence and applies any DNS or policy change. Palisade does not configure SendGrid, control mailbox-provider decisions, or guarantee delivery or inbox placement. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=vendor_setup&utm_content=how-do-i-set-up-spf-and-dkim-for-sendgrid) ## Sources and further reading - [Twilio SendGrid Domain Authentication](https://www.twilio.com/docs/sendgrid/ui/account-and-settings/how-to-set-up-domain-authentication) - [Twilio SendGrid Sender Authentication troubleshooting](https://www.twilio.com/docs/sendgrid/ui/account-and-settings/troubleshooting-sender-authentication) - [RFC 9989: DMARC](https://www.rfc-editor.org/rfc/rfc9989.html) - [RFC 8601: Authentication-Results](https://www.rfc-editor.org/rfc/rfc8601.html) - [Get Started with DMARC and SendGrid](https://www.twilio.com/en-us/blog/developers/community/get-started-sendgrid-dmarc) ## Frequently asked questions ### Does SendGrid Domain Authentication set up both SPF and DKIM? Yes. SendGrid Domain Authentication generates the DNS records needed for its selected authentication method. Automated security uses generated CNAME delegations, while manual security presents a different generated record set. Use the records shown in your own account. ### Should I use automated security in SendGrid? Yes, for the standard setup. Automated security lets SendGrid manage the authentication configuration behind its generated CNAME records. Use manual security only when a documented DNS or change-control requirement requires direct records. ### Can I copy SendGrid DNS records from another domain? No. SendGrid generates record owners and targets for the selected account and domain. Copying another account's values can authenticate the wrong configuration or fail verification. ### Does a verified SendGrid domain prove DMARC passes? No. Verification shows that SendGrid found the expected public DNS records. DMARC requires an aligned SPF or DKIM result on a real delivered message, then reports should confirm the continuing production pattern. ### How long does SendGrid verification take? It depends on DNS publication and resolver propagation. Check the authoritative DNS response first, then compare it with SendGrid's generated records. Twilio notes that propagation and DNS validation issues can delay verification. ### Can I authenticate more than one SendGrid sending domain? Yes. Configure and verify each sending domain in the SendGrid account that uses it. Validate each domain with a new message from its actual production path because one verified domain does not prove another domain or subuser configuration. --- # How do I set up SPF and DKIM for Amazon SES? Canonical: https://www.palisade.email/learning/how-do-i-set-up-spf-and-dkim-for-amazon-ses > Set up SPF and DKIM for Amazon SES by publishing identity-specific Easy DKIM records, configuring custom MAIL FROM, and validating real mail. To set up SPF and DKIM for Amazon SES, open the sending domain under **Configuration > Verified identities**, use its **Authentication** settings to copy the Easy DKIM CNAME records, and publish those exact account-generated values in DNS. For SPF alignment, configure a custom MAIL FROM subdomain and publish the MX and SPF TXT records SES supplies. This console path is verified from [AWS's current Easy DKIM documentation](https://docs.aws.amazon.com/ses/latest/dg/send-email-authentication-dkim-easy-managing.html). ## Quick takeaways - Amazon SES Easy DKIM uses three CNAME records generated for the selected domain identity. - Copy DNS values from the AWS account, Region, and identity that will send the mail. - A custom MAIL FROM subdomain is the Amazon SES configuration that can provide an SPF identity aligned with the visible From domain. - Do not add an Amazon SES SPF include to an existing root-domain SPF record unless the SES setup specifically requires that record there. - A successful SES identity status does not prove that a production message is signed, SPF-authenticated, or DMARC-aligned. - Validate DNS, the SES identity state, a newly delivered message, and DMARC aggregate reports separately. ## What should I check before configuring Amazon SES? Confirm the exact outbound path in scope. This guide covers mail sent through an Amazon SES domain identity, such as application or transactional mail. It does not configure employee mailbox mail sent directly through Google Workspace or Microsoft 365, even if those messages use the same visible From domain. Identify the AWS account and AWS Region used by the sender, the domain shown in production From addresses, and the DNS zone that controls that domain. AWS documents Easy DKIM records as identity-specific configuration, and its documentation notes that a Region can use a DKIM domain other than the default one. Use the values displayed for the active identity rather than values from an example or another Region. You also need permission to view and edit the SES identity plus access to the authoritative DNS provider. If an existing SPF, DKIM, or MX record is already present, identify the system that owns it before changing anything. > Copy DNS values from the account and domain you are configuring. Do not publish selectors, targets, tokens, or hostnames from another account or from an online example. For broader vendor-specific guidance, see the [vendor email authentication guides](/learning/esp-setup). If Amazon SES is only one sender among several, document which application uses each identity before treating a DNS result as evidence for all mail. ## Which setup method should I use? Use Easy DKIM for the Amazon SES domain identity when you need SES to sign mail with DKIM. AWS's [Easy DKIM management guide](https://docs.aws.amazon.com/ses/latest/dg/send-email-authentication-dkim-easy-managing.html) describes the three CNAME records associated with an Easy DKIM identity. Those records delegate the selector names AWS generates. They are not reusable DNS templates. Use a custom MAIL FROM domain when the return-path domain needs to be under your organizational domain for SPF alignment. AWS documents custom MAIL FROM as a separate identity setting with its own MX and SPF records and fallback behavior in the [IdentityMailFromDomainAttributes API reference](https://docs.aws.amazon.com/ses/latest/APIReference/API_IdentityMailFromDomainAttributes.html). DKIM and custom MAIL FROM solve different problems. Start with Easy DKIM if you need an aligned authentication path for DMARC. Add custom MAIL FROM when SPF alignment is a requirement for your sending design or operational policy. ![Amazon SES identity creation screen showing the Easy DKIM selection and key-length options](/images/editorial/how-do-i-set-up-spf-and-dkim-for-amazon-ses/ses-create-domain-identity-aws-blog-2023.png "1306x1324") *Source: [How to send your first email on SES](https://aws.amazon.com/blogs/messaging-and-targeting/how-to-send-your-first-email-on-ses/), checked 2026-08-10. This is a historical AWS interface example. Use the current controls for your selected Region.* ## How do I configure SPF and DKIM for Amazon SES? ### 1. Open the sending-domain identity In the AWS Region that sends the mail, open Amazon SES and go to **Configuration > Verified identities**. Select the domain identity used by the application, then open its **Authentication** settings. AWS's official documentation verifies this identity and authentication path. Check the selected domain and Region before copying a record. If the same domain sends through multiple AWS Regions, review the identity configuration in each sending Region. ### 2. Enable or review Easy DKIM Use the selected identity's Easy DKIM configuration and open the DNS records AWS displays. Amazon SES generates three CNAME records for the identity. Copy all three record names and targets exactly as presented. ![Amazon SES documentation view showing three Easy DKIM CNAME records for a domain identity](/images/editorial/how-do-i-set-up-spf-and-dkim-for-amazon-ses/ses-easy-dkim-records-aws-docs.png "2754x794") *Source: [Creating and verifying identities in Amazon SES](https://docs.aws.amazon.com/ses/latest/dg/creating-identities.html), checked 2026-08-10. The values shown in your own SES identity are the values to publish.* Do not replace an active DKIM selector because an online example uses a different name. If a generated owner conflicts with an existing record, stop and establish whether that selector belongs to an active sender before changing DNS. ### 3. Publish the Easy DKIM CNAME records Create the three CNAME records in authoritative DNS. The following shape is illustrative only. Amazon SES generates the real selectors and targets in the identity settings. **Record type:** `CNAME` **Host, illustrative only:** ```text <selector>._domainkey.yourdomain.com ``` **Value, illustrative only:** ```text <selector>.dkim.amazonses.com ``` > Do not publish these placeholders. Copy every complete CNAME owner and target from the selected Amazon SES identity and Region. Some DNS providers append the zone name automatically. If the DNS zone is `yourdomain.com`, entering `selector._domainkey.yourdomain.com` into a host field that appends the zone can create `selector._domainkey.yourdomain.com.yourdomain.com`. Query the final public name after saving. ### 4. Configure a custom MAIL FROM domain when SPF alignment is needed In the domain identity's custom MAIL FROM settings, choose a subdomain reserved for Amazon SES return paths, such as `mail.yourdomain.com`. AWS then provides an MX record and an SPF TXT record for that subdomain. The records have this structure only: **Record type:** `MX` **Host, illustrative only:** ```text mail.yourdomain.com ``` **Value, illustrative only:** ```text <priority> feedback-smtp.<aws-region>.amazonses.com ``` **Record type:** `TXT` **Host, illustrative only:** ```text mail.yourdomain.com ``` **Value, illustrative only:** ```text v=spf1 include:amazonses.com -all ``` > Do not publish these example values. Copy the exact MX priority, target, TXT value, and fallback choice Amazon SES displays for your identity. A custom MAIL FROM SPF record belongs on the MAIL FROM subdomain, not automatically on the root domain. SPF has one policy record per identity. Merge a new root-domain SPF mechanism only when the root domain is actually evaluated for the relevant mail path and the existing record owner confirms the change. ### 5. Verify the SES status and send a new message Return to the same Amazon SES identity and review its DKIM and custom MAIL FROM status after public DNS returns the expected records. AWS's identity state confirms that SES can find the required configuration for that identity. Then send a new message through the exact production application path. A test sent before the DNS change or from a different AWS Region is not evidence for the path you configured. ## How does this setup affect DMARC? DMARC evaluates alignment between the visible From domain and a passing SPF or DKIM identifier. [RFC 9989](https://www.rfc-editor.org/rfc/rfc9989.html) defines the SPF and DKIM alignment checks used by DMARC. Easy DKIM can satisfy DMARC when the passing DKIM signing domain aligns with the visible From domain. Custom MAIL FROM can make an aligned SPF identifier possible when the return-path subdomain aligns under the domain's published DMARC alignment mode. A valid SES identity alone does not establish either result. Use the [DMARC checker](/tools/dmarc) to inspect the published DMARC record before changing its policy. A public record check does not prove which SES application path is sending, whether a receiver accepted a message, or whether future mail will align. For related setup patterns, compare this workflow with [Brevo SPF and DKIM setup](/learning/how-do-i-set-up-spf-and-dkim-for-brevo) and [Customer.io SPF and DKIM setup](/learning/how-do-i-set-up-spf-and-dkim-for-customer-io). ![Illustrative Amazon SES DNS record set for Easy DKIM and a custom MAIL FROM subdomain](/images/editorial/how-do-i-set-up-spf-and-dkim-for-amazon-ses/how-do-i-set-up-spf-and-dkim-for-amazon-ses-records.webp "1200x533") *Source: Palisade.* ## How do I validate the setup? ### Check public DNS Query the exact CNAME owners generated by Amazon SES. If you configured custom MAIL FROM, also query its MX and TXT records. Compare the authoritative answer and at least one public resolver with the values in the selected SES identity. ```bash dig +short CNAME <selector>._domainkey.yourdomain.com dig +short MX mail.yourdomain.com dig +short TXT mail.yourdomain.com ``` The public DNS answers show what resolvers can see. They do not prove that SES has accepted the configuration or that an application is using it. ### Check the Amazon SES identity status Return to the same Region and selected identity. Confirm the current DKIM and, where applicable, custom MAIL FROM status. This is vendor-side evidence that Amazon SES recognizes the identity configuration. A green SES indicator is not a delivered-message check. It does not prove that the application selected that identity, that the message traversed the intended Region, or that DKIM survived the delivery path. ### Inspect a delivered message Open the raw source for a newly delivered test message. Inspect the `DKIM-Signature` field for the expected selector and signing domain, then inspect the trusted receiver-added authentication result. [RFC 8601](https://www.rfc-editor.org/rfc/rfc8601.html) defines `Authentication-Results` and explains why the receiving system's assessment has a trust boundary. Look for a trusted `dkim=pass` result and, where custom MAIL FROM is in use, the SPF result associated with the message's return-path identity. Compare the passing identifiers with the visible From domain to determine DMARC alignment. ### Review DMARC reports After aggregate reports accumulate, review Amazon SES traffic as a sending source and check the reported SPF and DKIM alignment results. This layer can reveal a separate application, Region, or return-path configuration that was not covered by a single test message. Palisade is agentic DMARC software that analyzes DMARC aggregate-report data, identifies authentication and alignment issues, and creates prioritized remediation tickets. It can propose a next DMARC policy step when evidence supports it, while your team reviews the evidence and applies DNS changes. ## Troubleshooting ### SES still shows DKIM as pending Check each public CNAME owner and target against the identity's current values. A missing record, altered target, or duplicated DNS suffix can prevent SES from finding the configuration. Do not copy a record from another identity or Region to clear a pending state. Return to the selected identity and use its generated values. ### The DKIM record is present but the test message does not pass DKIM Confirm that the message came from the configured Amazon SES path and inspect its actual `DKIM-Signature` selector and `d=` value. A DNS record can be correct while the sending application uses a different AWS account, Region, identity, or mail route. ### SPF passes but DMARC does not Compare the SPF-authenticated return-path domain with the visible From domain. SPF can pass for a domain that does not align for DMARC. Configure and validate custom MAIL FROM only when the desired return-path alignment is part of the design. ### DKIM passes but DMARC does not Compare the passing DKIM `d=` domain with the visible From domain and the domain's DMARC alignment policy. A valid DKIM signature does not automatically meet DMARC alignment. ### The root-domain SPF record was changed for SES and another sender broke Restore the previous approved SPF policy before making another change. Review whether the SES workflow actually requires a root-domain SPF record or whether the configuration belongs on a custom MAIL FROM subdomain. SPF policy changes affect every sender evaluated against that identity. ## Check the DNS records behind your Amazon SES identity After you have the SES-generated CNAME, MX, and TXT values, inspect the public DNS names before changing DMARC policy. The public results help catch missing records and duplicated zone suffixes, but they do not prove the Amazon SES account state, the production sending path, or a receiver's private delivery decision. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=existing_content_migration&utm_content=how-do-i-set-up-spf-and-dkim-for-amazon-ses) when you need to follow Amazon SES and other sending sources through DMARC aggregate reports. Palisade does not automatically change your DMARC policy or guarantee delivery. Your team reviews the evidence and applies the proposed change. For a provider-specific implementation of these authentication checks, see [How do I set up SPF and DKIM for Klaviyo?](/learning/how-do-i-set-up-spf-and-dkim-for-klaviyo). For a provider-specific implementation of these authentication checks, see [How do I set up SPF and DKIM for Mailgun?](/learning/how-do-i-set-up-spf-and-dkim-for-mailgun). For a provider-specific implementation of these authentication checks, see [How do I set up SPF and DKIM for Postmark?](/learning/how-do-i-set-up-spf-and-dkim-for-postmark). ## Sources and further reading - [Amazon SES Easy DKIM management](https://docs.aws.amazon.com/ses/latest/dg/send-email-authentication-dkim-easy-managing.html) - [Creating and verifying Amazon SES identities](https://docs.aws.amazon.com/ses/latest/dg/creating-identities.html) - [Amazon SES custom MAIL FROM identity attributes](https://docs.aws.amazon.com/ses/latest/APIReference/API_IdentityMailFromDomainAttributes.html) - [RFC 9989: Domain-based Message Authentication, Reporting, and Conformance](https://www.rfc-editor.org/rfc/rfc9989.html) - [RFC 8601: Authentication-Results](https://www.rfc-editor.org/rfc/rfc8601.html) - [Google Workspace: define an SPF record for Gmail](https://support.google.com/a/answer/33786) — for the employee mailbox mail this guide excludes. - [Microsoft 365: set up SPF](https://learn.microsoft.com/en-us/defender-office-365/email-authentication-spf-configure) — the Microsoft 365 equivalent. ## Frequently asked questions ### Does Amazon SES Easy DKIM require three DNS records? Yes. AWS documents three CNAME records for an Easy DKIM domain identity. Copy all three names and targets from the selected SES identity because they are account- and Region-specific. ### Do I need a custom MAIL FROM domain for Amazon SES? Only when your sending design requires Amazon SES to use a return-path subdomain that you control, including cases where SPF alignment is required. Easy DKIM and custom MAIL FROM are separate settings. ### Can I add Amazon SES to my existing root-domain SPF record? Only if the root domain is the SPF identity evaluated for the Amazon SES path and the change is compatible with every existing sender. A custom MAIL FROM setup normally places the SES SPF record on the return-path subdomain AWS provides. ### Does a verified Amazon SES identity prove DMARC passes? No. SES verification proves that Amazon SES recognizes the identity's expected DNS configuration. DMARC requires evidence from a delivered message and, over time, DMARC aggregate reports. ### Can a passing DKIM signature still fail DMARC? Yes. DMARC requires the passing DKIM signing domain to align with the visible From domain under the published DMARC alignment mode. A signature from an unrelated domain can pass DKIM without satisfying DMARC. --- # HubSpot SPF and DKIM setup: connect and verify Canonical: https://www.palisade.email/learning/how-do-i-set-up-spf-and-dkim-for-hubspot > HubSpot SPF and DKIM setup: connect your sending domain, publish account-generated DNS records, verify HubSpot, and validate a real message. Set up SPF and DKIM for HubSpot under [Settings > Content > Domains & URLs > Email Sending](https://knowledge.hubspot.com/marketing-email/manage-email-authentication-in-hubspot), then select **Connect sending domain**. HubSpot provides two DKIM CNAME records and SPF data for the account and domain you connect. Publish those exact values in authoritative DNS, merge SPF into any existing SPF policy, complete the HubSpot check, and test a newly delivered marketing email. Do not reuse DNS values from another HubSpot account. ## Quick takeaways - This process applies to HubSpot marketing email and automated marketing email, not connected inboxes, sequences, or transactional email. - HubSpot generates two separate DKIM CNAME records for an email sending domain. - A domain must publish one SPF policy, so add HubSpot's generated data to an existing `v=spf1` record instead of creating another SPF TXT record. - Provider-assisted setup is available only for DNS providers HubSpot supports in the connection flow. - HubSpot's authentication status confirms its DNS check. It does not prove a production message passes DKIM, SPF alignment, or DMARC. - Validate DNS, HubSpot status, a delivered message, and DMARC aggregate reports as separate checks. ## What should I check before configuring HubSpot? Confirm that the domain is used for HubSpot marketing email and that you know the exact visible From domain you will test. HubSpot documents different sending paths for [marketing email, connected inboxes, sequences, and conversations](https://knowledge.hubspot.com/marketing-email/understand-email-sending-in-hubspot). This guide covers the marketing-email sending-domain path only. You need access to the authoritative DNS zone and a HubSpot user who can connect or reconnect the domain. HubSpot's [email sending-domain troubleshooting guidance](https://knowledge.hubspot.com/email/troubleshoot-your-email-sending-domain) identifies Super Admin or Domain settings permission for domain connection work. Check the current DNS zone before making changes: - Save the existing SPF TXT value, if one exists. - Check whether either proposed DKIM host already has a DNS record. - Confirm the DNS provider's host-field behavior. Some interfaces append the zone automatically, so pasting a full domain can create a duplicated owner name. - Keep the DNS change and a test mailbox tied to the same production From domain. > Copy DNS values from the account and domain you are configuring. Do not publish selectors, targets, tokens, or hostnames from another account or from an online example. ## Which setup method should I use? Use **Sign in with provider** when HubSpot offers your authoritative DNS provider and you are authorized to approve the requested DNS changes. Use **No, I'll set it up manually** when your provider is unavailable, DNS changes require review, or your team manages DNS through a separate workflow. HubSpot documents both choices in its [email authentication connection flow](https://knowledge.hubspot.com/marketing-email/manage-email-authentication-in-hubspot). The account-specific records remain the source of truth in either path. If you use manual setup, copy every current **Host** and **Required data** field from the HubSpot domain connection screen. For a comparable provider-specific workflow, see how to set up SPF and DKIM for Amazon SES. The same DNS safety rule applies, but do not substitute Amazon SES record values for HubSpot values. ## How do I configure SPF and DKIM for HubSpot? ### 1. Open the Email Sending domain connection flow In HubSpot, select the settings icon, then open **Content > Domains & URLs > Email Sending**. Select **Connect sending domain**. This documented path was verified from HubSpot's official documentation rather than an authenticated account. Enter an email address that uses the From domain for the HubSpot marketing-email path. Do not connect a domain used only by another sender. ### 2. Select the sending domain you will validate Confirm the selected domain before proceeding. A root domain and a subdomain can have separate DNS zones, SPF policies, DKIM records, and DMARC policy discovery. Record the exact From address you will use for the final message test. The visible From domain is the identifier DMARC evaluates for alignment. ### 3. Select provider-assisted or manual setup Choose the connection method that matches the DNS ownership model you checked earlier. If HubSpot can connect through the provider and you approve the change, review the DNS changes before accepting them. If you choose manual setup, keep the HubSpot record screen open while entering values in DNS. Do not infer record values from a screenshot, documentation example, or another HubSpot portal. HubSpot generates values for the current account and connected domain. ### 4. Publish both account-generated DKIM CNAME records HubSpot's [email-authentication instructions](https://knowledge.hubspot.com/marketing-email/manage-email-authentication-in-hubspot) require two DKIM CNAME records. Copy the two host and target pairs separately. A CNAME cannot coexist with another DNS record at the same owner name. **Record type:** `CNAME` **Host (illustrative only):** ```text hs1-123456._domainkey ``` **Value (illustrative only):** ```text Copy the complete account-generated HubSpot CNAME target. ``` **Record type:** `CNAME` **Host (illustrative only):** ```text hs2-123456._domainkey ``` **Value (illustrative only):** ```text Copy the complete account-generated HubSpot CNAME target. ``` > Do not publish these examples. Generate and copy both complete host and target pairs from the HubSpot account and domain you are connecting. The official HubSpot interface below shows separate DKIM rows with their own host, required-data, and copy controls. ![HubSpot DNS verification table showing two distinct account-generated DKIM CNAME rows](/images/editorial/how-do-i-set-up-spf-and-dkim-for-hubspot/hubspot-dkim-cname-records.png "1454x404") *Source: [Manage your email authentication](https://knowledge.hubspot.com/marketing-email/manage-email-authentication-in-hubspot), checked 2026-07-18.* If the DNS zone is managed through Cloudflare, follow HubSpot's documented DNS requirements. In particular, do not use a proxy for these authentication records, and check that domain-wide CNAME flattening does not alter the required answer. ### 5. Merge HubSpot SPF data into one SPF record HubSpot displays the SPF data to use for the connected domain. Copy the complete current value from the HubSpot screen. It is account-specific. **Record type:** `TXT` **Host (illustrative only):** ```text @ ``` **Value structure, illustrative only:** ```text v=spf1 include:existing-sender.example include:account-generated.hubspotemail.example -all ``` > Do not publish this sample. Preserve the existing policy and add only the exact HubSpot SPF mechanism supplied in your account. [RFC 7208](https://www.rfc-editor.org/info/rfc7208/) specifies that SPF evaluation uses one SPF record. Creating a second TXT record beginning `v=spf1` can produce an SPF PermError. Merge the generated HubSpot mechanism into the existing policy before its [final `~all` or `-all` mechanism](/learning/glossary/spf-all-qualifier). Review the policy's DNS-querying mechanisms as part of the change because SPF has a limit on DNS-term evaluation. The record card below shows the ownership and separation to preserve: two DKIM CNAME owners and one root SPF policy. ![Illustrative HubSpot email authentication DNS record shapes showing two DKIM CNAME records and one merged SPF TXT policy](/images/editorial/how-do-i-set-up-spf-and-dkim-for-hubspot/how-do-i-set-up-spf-and-dkim-for-hubspot-records.webp "1200x533") *Source: Palisade.* ### 6. Complete verification and send a new test message Return to the HubSpot domain connection screen and continue its verification process after public DNS returns the expected records. Then send a new marketing email through the exact production path to a mailbox where you can inspect raw headers. Do not test an older message. It may have been sent before HubSpot completed authentication or before the DNS change propagated. ## How does this setup affect DMARC? DMARC passes when SPF or DKIM passes and the authenticated identifier aligns with the visible From domain. [RFC 9989 defines SPF and DKIM alignment for DMARC](https://www.rfc-editor.org/info/rfc9989/). A HubSpot DKIM result can satisfy DMARC when the DKIM `d=` domain aligns with that visible From domain. A passing SPF result for a different return-path domain does not satisfy SPF alignment. Use the [DMARC checker](/tools/dmarc) to inspect the published DMARC record before changing policy. A public record lookup does not show the exact HubSpot message path, a receiver's private evaluation, or future delivery results. If you are building a wider vendor inventory, the [vendor email authentication hub](/learning/esp-setup) groups related setup guides, including how to set up SPF and DKIM for Brevo. ## How do I validate the setup? ### Check public DNS Query each DKIM owner and the root-domain SPF policy through the authoritative DNS service and a public resolver. ```bash dig +short CNAME hs1-123456._domainkey.yourdomain.com dig +short CNAME hs2-123456._domainkey.yourdomain.com dig +short TXT yourdomain.com ``` Replace the illustrative selector with the exact host HubSpot generated. Use the [DNS lookup tool](/tools/dns-lookup) to inspect public answers, and use the [SPF checker](/tools/spf) to review the published SPF policy. These checks confirm public DNS only. They do not prove HubSpot is using the records. ### Check the HubSpot status HubSpot presents status and record-specific diagnostics for the connected sending domain. Check that the account shows the expected authenticated state and that no required record remains unresolved. ![HubSpot email sending domains status list showing authentication state and record diagnostics](/images/editorial/how-do-i-set-up-spf-and-dkim-for-hubspot/hubspot-authentication-status.png "2096x508") *Source: [Manage your email authentication](https://knowledge.hubspot.com/marketing-email/manage-email-authentication-in-hubspot), checked 2026-07-18.* A green HubSpot status proves that HubSpot accepted its DNS check. It is not a delivered-message check and does not prove every outbound route signs or aligns the same way. ### Inspect a delivered message Open the raw source of the new test message. Confirm the expected `d=` domain and `s=` selector in `DKIM-Signature`, then inspect the receiver-added `Authentication-Results` field. [RFC 8601 defines Authentication-Results and its trust boundary](https://www.rfc-editor.org/rfc/rfc8601.html). Accept the setup only when the trusted receiver result reports the expected DKIM pass and, where needed for DMARC, the passing DKIM domain aligns with the visible From domain. Keep a redacted header copy with the DNS change record. ### Review DMARC reports After aggregate reports accumulate, review HubSpot traffic separately from other sources that use the domain. Look for DKIM pass and alignment results for the HubSpot source. This layer identifies whether the live traffic matches the intended configuration over time. ## Troubleshooting ### HubSpot cannot find a required record Compare the fully qualified DNS owner with the exact HubSpot host. A DNS provider that appends `yourdomain.com` can turn a full hostname into `host.yourdomain.com.yourdomain.com`. Check authoritative DNS before editing again. If the public answer is correct but HubSpot remains pending, use HubSpot's [domain troubleshooting steps](https://knowledge.hubspot.com/email/troubleshoot-your-email-sending-domain) and compare the complete target or TXT data character by character. ### The DKIM CNAME record conflicts with an existing record Stop before replacing it. A CNAME cannot share an owner with other DNS data. Determine which sender owns the existing record, then choose a non-conflicting provider workflow or complete its documented rotation process. ### SPF returns multiple records or a PermError Find every TXT answer beginning with `v=spf1`. Keep one policy and merge HubSpot's current generated mechanism into it. Do not remove another sender's include or change the final policy mechanism without understanding the existing mail flow. ### HubSpot is authenticated but DMARC fails Inspect a newly delivered message. Compare the visible From domain with the DKIM `d=` domain and the receiver's `Authentication-Results`. HubSpot status alone does not show whether the delivered message had an aligned identifier. ### Cloudflare is altering the required answer Review the record's proxy setting and the zone's CNAME-flattening behavior. HubSpot's authentication guidance specifies the DNS conditions needed for its records. Retest the public answer after each DNS correction. ## Check the wider authentication posture for the sending domain Run the production From domain through Palisade's [Email Security Score](/tools/email-security-score) after HubSpot shows the domain as authenticated and you have tested a real message. This checks the surrounding public authentication configuration that HubSpot's status page does not inventory. A public score cannot prove the HubSpot production path, inspect private receiver decisions, or monitor future DNS changes. For an ongoing DMARC workflow, Palisade is agentic DMARC software that analyzes aggregate-report data, identifies sending sources and alignment issues, and creates prioritized remediation tickets. A human reviews the evidence and applies DNS or DMARC policy changes. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=vendor_setup&utm_content=how-do-i-set-up-spf-and-dkim-for-hubspot) ## Sources and further reading - [HubSpot: Manage your email authentication](https://knowledge.hubspot.com/marketing-email/manage-email-authentication-in-hubspot) - [HubSpot: Understand email sending in HubSpot](https://knowledge.hubspot.com/marketing-email/understand-email-sending-in-hubspot) - [HubSpot: Troubleshoot your email sending domain](https://knowledge.hubspot.com/email/troubleshoot-your-email-sending-domain) - [RFC 7208: Sender Policy Framework](https://www.rfc-editor.org/info/rfc7208/) - [RFC 8601: Authentication-Results](https://www.rfc-editor.org/rfc/rfc8601.html) - [RFC 9989: DMARC](https://www.rfc-editor.org/info/rfc9989/) ## Frequently asked questions ### Does HubSpot require two DKIM records? Yes. HubSpot's email sending-domain connection flow provides two DKIM CNAME records. Publish both exact host and target pairs for the selected account and domain. ### Can I add a second HubSpot SPF TXT record? No. Publish one SPF policy beginning with `v=spf1` for the domain. Add HubSpot's account-generated SPF mechanism to the existing policy rather than creating a separate SPF record. ### Does this configure a connected HubSpot inbox? No. This guide covers HubSpot marketing-email sending domains. Connected inboxes, one-to-one email, sequences, conversations inbox mail, and transactional email use different sending paths and may need separate authentication checks. ### Does an authenticated HubSpot domain guarantee DMARC will pass? No. HubSpot authentication confirms its DNS verification state. Check a real delivered message for the receiver's DKIM and SPF results, then confirm that a passing identifier aligns with the visible From domain. ### How long should I wait before troubleshooting DNS verification? Only troubleshoot after checking the authoritative and public DNS answers for the exact HubSpot-generated records. DNS publication time depends on the DNS provider and TTL. If the answers match HubSpot's current values but the status remains unresolved, follow HubSpot's documented domain troubleshooting process. --- # Apollo email warmup: what it does and what it cannot prove Canonical: https://www.palisade.email/learning/apollo-email-warmup > Apollo email warmup uses inbox-network activity for connected mailboxes, but it does not prove authentication, consent, or inbox placement today. Apollo Email Warmup is a connected-mailbox feature that uses a third-party inbox network to send and engage with system-generated warmup messages. Apollo documents it for new mailboxes and domains. It can create warmup activity, but that activity does not prove that a real campaign is authenticated, sent to consenting recipients, or placed in recipients' inboxes. Apollo's separate Inbox ramp up option gradually raises sending in Apollo sequences or scheduled emails for mailboxes with prior history. ## Quick takeaways - Apollo Email Warmup requires a mailbox connected to Apollo. - Apollo says Email Warmup uses a private inbox network and Warmbox.ai. - Apollo distinguishes Email Warmup from Inbox ramp up, which raises Apollo sending gradually for mailboxes with sending history. - Warmup activity does not prove SPF, DKIM, or DMARC authentication for a production campaign. - A warmup setting does not show recipient consent, list quality, or a receiving provider's inbox-placement decision. - Public authentication records and real delivered-message evidence answer different questions from warmup activity. ## How Apollo email warmup works [Apollo's Email Warmup documentation](https://knowledge.apollo.io/hc/en-us/articles/26772718460045-Use-Email-Warmup-to-Improve-Deliverability) describes a feature for connected mailboxes that sends system-generated messages through a private inbox network supplied by Warmbox.ai. Apollo positions the feature for new mailboxes and domains. Its purpose is preparatory mailbox activity, not a test of a specific campaign's delivery. Apollo also documents Inbox ramp up as a different option. Rather than using the warmup inbox network, it gradually increases sending from Apollo sequences or scheduled emails for mailboxes that already have sending history. The distinction matters because neither option establishes whether the production path has the authentication configuration required by the visible From domain. Email deliverability includes authentication, reputation, content, recipient engagement, and receiver-specific handling. See the [email deliverability hub](/email-deliverability) for the wider model. A warmup feature can affect activity around a mailbox, while a mailbox provider still makes its own decision about each real message. DMARC evaluates whether SPF or DKIM passes and aligns with the message's visible From domain. The domain owner publishes a DMARC policy in DNS, and the receiving system performs the evaluation for the message it receives, as specified by [RFC 9989](https://www.rfc-editor.org/rfc/rfc9989.html). Warmup traffic is not a substitute for that message-level authentication result. ![Decision flow separating Apollo warmup activity from public authentication checks and real-campaign delivery evidence](/images/editorial/apollo-email-warmup/apollo-email-warmup-evidence-boundaries.webp "1200x738") *Source: Palisade.* ## When the answer changes Use the evidence that matches the question. - If the mailbox and domain are new, Apollo's Email Warmup feature may be the relevant Apollo option because Apollo documents it for new mailboxes and domains. - If the mailbox already has sending history and the question is about gradually raising Apollo sequence or scheduled-email volume, Apollo's Inbox ramp up option is the closer documented feature. - If a campaign fails DMARC, shows an authentication warning, or has an unaligned sender identity, inspect the authentication configuration and a delivered message. Warmup activity does not resolve that evidence. - If recipients report spam-folder placement or filtering, preserve an example from the exact campaign path and investigate the observed symptoms. The [guide to emails going to spam](/learning/why-do-your-emails-go-to-spam-and-how-can-you-fix-it) covers that diagnostic task. Apollo notes that Email Warmup cannot repair a damaged sender reputation. That limitation also means an operator should not treat a warmup status as a repair confirmation for a mailbox already affected by filtering or reputation problems. The usable decision rule is straightforward: use Apollo's documented feature descriptions to choose between warmup activity and ramped Apollo sending, then use DNS records and a real delivered message to assess authentication and campaign behavior. ## A worked evidence check Suppose `sales.yourdomain.com` sends a real Apollo campaign with a visible From address at `yourdomain.com`. A warmup setting can show that Apollo is performing warmup activity for the connected mailbox. It cannot answer whether the actual campaign message passes DMARC. Inspect a real message header from that production path. The relevant evidence may include a receiver-generated result like this illustrative shape: ```text Authentication-Results: mx.receiver.example; spf=pass smtp.mailfrom=mail.yourdomain.com; dkim=pass header.d=yourdomain.com; dmarc=pass header.from=yourdomain.com ``` This example is illustrative only. Do not publish or share unredacted message headers, customer addresses, message IDs, or tokens. Under [RFC 8601](https://www.rfc-editor.org/rfc/rfc8601.html), an `Authentication-Results` field communicates authentication assessments made by the receiving system. The field can include SPF, DKIM, and DMARC method results and their associated properties. The exact values in a real header depend on the receiver and the message path. A result such as `dmarc=pass` is evidence about that delivered message. It still does not guarantee later inbox placement because receiving systems can use additional local signals. Conversely, a warmup activity indicator is not an `Authentication-Results` field and does not prove that this production message passed DMARC. For a deeper protocol explanation, see [what DMARC is](/learning/what-is-dmarc). If you are evaluating generic service categories rather than Apollo's feature, use [Email warmup service: compare the evidence before choosing](/learning/email-warmup-service). ## Check the evidence before changing sending volume Start with the evidence you already have. - If you only have a domain name, inspect its public SPF, DKIM, and DMARC configuration with the [Email Security Score](/tools/email-security-score). - If you have a real campaign message, obtain its raw headers from the receiving mailbox and compare its authentication results with the visible From domain and return-path domain. - If you have reports of filtering, retain the campaign details and diagnose the exact sending path before changing volume or assuming warmup caused the result. - If you receive DMARC aggregate reports over time, use them to inventory sending sources and identify authentication or alignment failures that a public DNS check cannot reveal. A public record check confirms what DNS publishes at the time of the lookup. It does not test Apollo warmup traffic, recipient consent, a mailbox provider's private reputation decision, or inbox placement for a particular campaign. ## Inspect authentication before relying on warmup Apollo's documented feature can create warmup activity, while a public authentication check can reveal whether the domain publishes SPF, DKIM, and DMARC records that need review before production sending. [Check public email authentication](/tools/email-security-score) If DMARC reports later reveal unknown sources or alignment failures across the domain, Palisade is DMARC software that analyzes DMARC aggregate-report data, identifies issues, and creates prioritized remediation tickets for human review. It does not control Apollo, automatically change DNS or sender settings, prove inbox placement, or guarantee a receiver's behavior. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=vendor_email_authentication&utm_content=apollo-email-warmup) ## Sources and further reading - [Apollo: Use Email Warmup to Improve Deliverability](https://knowledge.apollo.io/hc/en-us/articles/26772718460045-Use-Email-Warmup-to-Improve-Deliverability) - [Apollo Email Deliverability Software](https://www.apollo.io/email-deliverability) - [RFC 9989: Domain-based Message Authentication, Reporting, and Conformance (DMARC)](https://www.rfc-editor.org/rfc/rfc9989.html) - [RFC 8601: Message Header Field for Indicating Message Authentication Status](https://www.rfc-editor.org/rfc/rfc8601.html) - [Palisade Email Security Score](/tools/email-security-score) ## Frequently asked questions ### What is the best email warm up tool? There is no single best email warmup tool for every mailbox or sending program. Choose a product based on the evidence it produces, its documented behavior, and whether it addresses your actual problem. A warmup feature does not replace public authentication checks or real-message investigation. ### What is the most hacked email provider? No authoritative, universal ranking establishes one email provider as the "most hacked." Account-compromise risk depends on factors such as phishing resistance, multi-factor authentication, recovery controls, device security, and user practices. A provider's security posture is separate from email warmup and inbox placement. ### How do I turn off Apollo email warming? Check Apollo's current [Email Warmup documentation](https://knowledge.apollo.io/hc/en-us/articles/26772718460045-Use-Email-Warmup-to-Improve-Deliverability) and the controls available in your authenticated account before making a change. The documented feature description does not make a current account-specific disabling workflow universal, so do not rely on inferred UI steps. ### Does email warmup actually work? Yes, email warmup can create the activity its provider documents, such as messages sent through a warmup network. It does not prove authentication for a real campaign, recipient consent, sender reputation at a particular receiver, or inbox placement. Validate those questions with DNS records, delivered-message headers, and observed campaign evidence. ### Does Apollo Email Warmup fix a damaged reputation? No. Apollo states that Email Warmup cannot repair a damaged sender reputation. Investigate the affected production sending path, authentication results, recipient practices, and filtering evidence instead of treating warmup activity as a repair result. --- # Why Brevo does not provide SPF alignment by default Canonical: https://www.palisade.email/learning/brevo-spf-alignment > Brevo SPF alignment is not default because standard domain setup uses Brevo's return path. Verify aligned DKIM, headers, and DMARC results now. Brevo does not provide SPF alignment by default because its standard authenticated-domain setup can use Brevo's generic SPF and return-path infrastructure. SPF may therefore pass for a Brevo-controlled envelope domain rather than your visible From domain. That can still produce a DMARC pass when Brevo DKIM signs with, and aligns to, your domain. Use a branded subdomain only when Brevo makes that option available for your account and you specifically need aligned SPF. ## Quick takeaways - SPF passing and SPF aligning with the visible From domain are separate checks. - Brevo's ordinary domain-authentication flow does not require you to publish an SPF record. - A Brevo message can pass DMARC through aligned DKIM when SPF is unaligned. - SPF alignment depends on the SMTP envelope domain, also called the return path, rather than the visible From address alone. - A green Brevo domain status is useful evidence, but a new delivered message proves which identifiers the production path actually used. - Do not add or replace an SPF include until Brevo has supplied account-specific DNS instructions for the sending configuration. ## Scope and prerequisites Start with one affected Brevo sending path. Record the visible From domain, the Brevo account that sends the mail, the DNS zone owner, the person responsible for the change, and a test mailbox where you can inspect full message headers. [Brevo's domain setup guidance](https://help.brevo.com/hc/en-us/articles/35852083084178-Domain-setup-for-better-email-deliverability) distinguishes its standard authenticated-domain flow from branded-subdomain setup. The standard flow can use Brevo infrastructure for SPF and the return path. The branded option moves those identities to a customer-controlled subdomain, but Brevo says availability is gradual. You need access to the exact Brevo account and to authoritative DNS before publishing anything. Save the current DNS records before changing them. The rollback condition is clear: if a new Brevo configuration causes verification failure or a new production-path message loses its expected authentication result, restore the prior known-good Brevo setting and preserve existing DNS records until the mismatch is understood. Brevo's ordinary authentication instructions use account-generated domain records and say SPF and MX records are not required for that normal flow. Brevo documents SPF and MX in dedicated-IP contexts instead. Follow the [current Brevo domain-authentication instructions](https://help.brevo.com/hc/en-us/articles/12163873383186-Authenticate-your-domain-with-Brevo-Brevo-code-DKIM-DMARC) shown for the account you are configuring. ## Choose the implementation approach Use the delivered-message evidence to choose the next step. - Keep the standard Brevo configuration when DKIM passes, the DKIM `d=` domain aligns with the visible From domain, and DMARC passes. SPF alignment is not required for DMARC in that case. - Complete Brevo's current domain-authentication flow when DKIM is absent, fails, or signs with a domain that does not align with the visible From domain. - Use Brevo's branded-subdomain workflow only when it is available in the account and the organization needs SPF alignment for its own operational policy or message-authentication design. - Investigate a dedicated-IP configuration through Brevo's dedicated-IP guidance. Do not apply those record requirements to an ordinary shared-infrastructure account by assumption. [DMARC's current specification](https://www.rfc-editor.org/rfc/rfc9989.html) defines a DMARC pass when either SPF or DKIM passes and aligns with the RFC5322.From author domain. The protocol does not require both mechanisms to align. A receiving mailbox provider can still apply its own local handling after DMARC evaluation. ![Decision flow for a Brevo message with unaligned SPF, showing when aligned DKIM is enough and when to investigate branded subdomain setup](/images/editorial/brevo-spf-alignment/brevo-spf-alignment-decision-flow.webp "1200x856") *Source: Palisade.* ## How to configure Brevo domain authentication ### 1. Identify the exact From domain and sending path Send a new test campaign or transactional message through the affected Brevo configuration. Use the same sender identity, template type, and production route that recipients use. Do not use a message sent through a different platform as evidence for Brevo. A company can have several senders that all use the same visible From domain but authenticate differently. ### 2. Inspect the current Brevo domain setup Open Brevo's current domain setup for the exact sender domain. Record whether it shows the normal authentication workflow, a branded-subdomain option, or a dedicated-IP-related setup. Copy the owner names, record types, and values from the account only. DKIM selectors, CNAME targets, and tenant values are generated for the account. Do not copy an example from another organization, article, or old ticket. ### 3. Publish only the records Brevo generated Brevo's normal authentication flow commonly requires the DNS records displayed for the account. The following is an illustrative structure, not a Brevo value to publish: ```text illustrative only <selector>._domainkey.yourdomain.com CNAME <tenant-generated-target> _dmarc.yourdomain.com TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com" ``` > Do not replace an existing DMARC record with this example. A domain has one DMARC policy record at `_dmarc`, and it may already contain a policy and reporting destinations that protect other sending systems. If Brevo offers branded-subdomain setup, use the exact subdomain and records it generates. That configuration is provider-specific. It is not equivalent to adding a guessed `include:` mechanism to the visible From domain's SPF record. ### 4. Preserve existing SPF and DMARC records SPF has one effective TXT policy per envelope domain. If Brevo explicitly instructs you to add an SPF mechanism for a dedicated-IP or branded setup, merge that instruction into the existing policy only after reviewing every current sender. Publishing a second independent `v=spf1` record can cause SPF PermError. Do not change `aspf` or `adkim` to strict alignment as a shortcut. Strict alignment changes the DMARC comparison rule. It does not make Brevo use a different envelope domain or repair a missing DKIM signature. ### 5. Activate Brevo verification and send a new message Return to Brevo after public DNS answers with the records it generated. Complete its verification process, then send a new message through the same production path. A message delivered before the DNS change cannot validate the new configuration. Keep the date, sender, visible From domain, and Brevo configuration name with the test evidence. ## How to validate the setup Validate the Brevo configuration at four separate layers. - DNS: Query the authoritative DNS service and at least one public resolver for the exact Brevo-generated owner names. Confirm that the record type and target or value match the current Brevo account instructions. - Vendor: Confirm Brevo reports the exact domain as authenticated or verified. This shows Brevo can see the required domain setup, not that every production message uses it. - Message: Inspect a new received message from the affected Brevo path. Compare the visible From domain with the SPF-authenticated envelope domain and the DKIM `d=` domain. Record the SPF, DKIM, and DMARC results. - DMARC: Review aggregate-report data after reports accumulate. Confirm the Brevo source passes through the intended aligned identifier over time. A useful test record can use this shape: ```yaml sending_path: brevo-campaign-or-transactional-stream from_domain: yourdomain.com smtp_mailfrom_domain: observed-envelope-domain spf_result: pass-or-fail dkim_domain: observed-d-value dkim_result: pass-or-fail dmarc_result: pass-or-fail alignment_method: spf-or-dkim checked_at: UTC timestamp ``` A public SPF lookup cannot supply the message-layer values. Use the [Palisade SPF checker](/tools/spf) to inspect the published SPF policy for the domain you enter, then compare it with a real message header. The checker does not prove Brevo's active return path, a receiver's private delivery decision, or future inbox placement. ![Palisade SPF checker result for a domain lookup](/images/editorial/spf-checking-tool/palisade-google-com-spf-result-current.png "1280x926") *Source: https://www.palisade.email/tools/spf?domain=google.com* For context on a similar distinction between provider setup and DMARC alignment, see [why Mailchimp DMARC alignment does not require adding Mailchimp to SPF](/learning/why-does-mailchimp-dmarc-alignment-not-require-adding-mailchimp-to-spf). The [Palisade learning center](/learning) also has protocol guidance for SPF, DKIM, and DMARC operations. ## Troubleshooting ### Brevo shows the domain as authenticated, but SPF is unaligned This can be expected with Brevo's standard infrastructure. Inspect the delivered message to determine whether DKIM passes and aligns with the visible From domain. If it does, DMARC can pass through DKIM. If you require aligned SPF, check whether the Brevo account offers branded-subdomain setup. Do not treat an unaligned SPF pass as evidence that the standard configuration is broken. ### DKIM passes, but DMARC fails Compare the visible From domain with the DKIM `d=` domain. A valid DKIM signature does not supply a DMARC pass unless the signing domain aligns under the domain's current `adkim` mode. Then check whether the message came from the Brevo stream you configured. A message from another ESP, CRM, or relay can have different signing behavior. ### Brevo cannot verify the DNS records Compare the exact owner name and record type against the current Brevo account screen. Check whether the DNS provider automatically appends `yourdomain.com` to a host field. A fully qualified name entered into a zone editor that appends the zone can create a duplicated name. Query authoritative DNS before assuming propagation is the cause. Then check that no conflicting CNAME, TXT, or stale record exists at the same owner name. ### SPF fails after an SPF change Restore the prior SPF record if the change removed an existing authorized sender. Review all applications that send with the envelope domain before merging a provider instruction. An SPF policy affects the envelope domain it is published for. Changing the visible From domain's SPF record does not change a Brevo message's generic return path. ## Check the published SPF record, then close the ongoing gap Use the SPF checker to inspect the public SPF record for the domain involved in the Brevo configuration. Compare that result with the delivered Brevo header before changing DNS. [Check the SPF record](/tools/spf) A public record check cannot prove that Brevo is using the expected return path, repair DKIM alignment, or show how every sending source authenticates over time. When Brevo is one of several senders and aggregate reports reveal recurring alignment exceptions, Palisade can analyze DMARC aggregate-report data, identify sending sources and authentication or alignment issues, and create prioritized remediation tickets. It proposes the next policy step from the evidence, while your team reviews the evidence and applies any DNS or DMARC policy change. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=vendor_setup&utm_content=brevo-spf-alignment) Palisade does not change the DMARC policy for you, control Brevo's return path, or guarantee delivery or inbox placement. ## Sources and further reading - [Brevo: Domain setup for better email deliverability](https://help.brevo.com/hc/en-us/articles/35852083084178-Domain-setup-for-better-email-deliverability) - [Brevo: Authenticate your domain with Brevo](https://help.brevo.com/hc/en-us/articles/12163873383186-Authenticate-your-domain-with-Brevo-Brevo-code-DKIM-DMARC) - [RFC 9989: Domain-based Message Authentication, Reporting, and Conformance](https://www.rfc-editor.org/rfc/rfc9989.html) - [Palisade SPF checker](/tools/spf) ## Frequently asked questions ### Does Brevo require an SPF record for ordinary domain authentication? No. Brevo's ordinary domain-authentication guidance says SPF and MX records are not required for that flow. Brevo documents SPF and MX requirements in dedicated-IP setup contexts, so use the instructions shown for the specific account configuration. ### Can Brevo messages pass DMARC when SPF is unaligned? Yes. DMARC passes when either SPF or DKIM both passes and aligns with the visible From domain. A Brevo message with an unaligned SPF pass can still pass DMARC through an aligned DKIM signature. ### Does adding Brevo to my SPF record create SPF alignment? No. SPF alignment depends on the domain Brevo uses in the SMTP envelope sender and on its relationship to the visible From domain. Adding an include to a different domain does not change the envelope identity that Brevo uses. ### Is branded-subdomain setup available to every Brevo account? No. Brevo says its branded-subdomain domain setup is rolling out gradually. Check the current options in the affected Brevo account before planning DNS changes around that workflow. ### Should I enable strict SPF alignment for Brevo? Only after new delivered messages show that every legitimate sender using the domain has an exactly aligned SPF identity where strict alignment is required. Strict SPF alignment does not replace Brevo domain authentication or repair an unaligned return path. ### Can an SPF checker prove that Brevo is configured correctly? No. An SPF checker can inspect public DNS for the domain entered. It cannot prove Brevo account verification, the envelope domain used by a delivered Brevo message, DKIM signing, DMARC alignment, or a recipient's inbox decision. --- # Cloudflare DKIM setup Canonical: https://www.palisade.email/learning/cloudflare-dkim-setup > Cloudflare DKIM setup starts with sender-generated DNS values, then requires DNS, sender, delivered-message, and DMARC validation for each sending path. Cloudflare DKIM setup means publishing the exact DKIM DNS record generated by the email sender for one sending domain. Cloudflare is the DNS publishing layer. It does not provide a universal DKIM selector, public key, CNAME target, or sender-verification process. Because current official Cloudflare DNS workflow documentation was not available for this guide, confirm the authenticated DNS controls and your sender's current instructions before you save any change. ## Quick takeaways - Obtain the DKIM record from the service that sends the mail, not from another Cloudflare account or tutorial. - Keep the sender's record type, owner name, and value together as one account-specific instruction set. - Stop if an active record already uses the same owner name. - A public DNS result does not prove the sender signed a production message. - A sender verification status does not replace inspection of a newly delivered message. - Cloudflare belongs in the DNS-publication part of the broader [vendor email authentication workflow](/learning/esp-setup). ## Scope and prerequisites Choose one production sending path before changing DNS. Employee mail, marketing mail, transactional mail, and mail that passes through a security gateway can each have separate DKIM settings. Record the visible From domain, the sender platform, the DNS zone owner, the person authorized to approve DNS changes, and a test mailbox that can show full message headers. The email sender must provide the record values for the exact domain and account in scope. Those values can include a selector, record owner, record type, public-key value, CNAME target, or verification token. Do not borrow any of them from another account. Public DNS can expose a DKIM public key, but the sender's private signing key must stay in the sending system. Confirm that the domain's authoritative DNS is actually managed in the Cloudflare account you plan to use. Cloudflare's public site confirms that it has a [Login entry point](https://cloudflare.com), but that page does not document the current DNS dashboard path, record-entry fields, or DKIM-specific behavior. Verify the current path in Cloudflare's authenticated documentation or in the account that owns the zone. If the visible From address uses a subdomain, determine whether that subdomain is a separate sending identity before you request records. Does a subdomain need its own DKIM setup? covers that decision in more detail. Set a rollback condition before opening the DNS editor: if the sender's supplied owner name already has a record that supports active mail, or if you cannot identify the sender and domain that generated the new value, do not replace it. Get the sender's documented rotation or migration procedure first. > Do not overwrite an existing selector, CNAME target, or TXT value because a new sender asks for DKIM. An active record may still be needed to verify mail already in transit or mail from another production path. ![Checklist showing the account-specific evidence to collect before publishing a DKIM record in Cloudflare](/images/editorial/cloudflare-dkim-setup/cloudflare-dkim-setup-evidence-checklist.webp "1200x524") _Source: Palisade._ ## Choose the implementation approach Use the exact approach the sending service generated for the selected domain. The record shape is sender-specific. Do not convert a sender-provided CNAME instruction into a TXT instruction, and do not invent a value because another sender used a similar selector. Use these decision rules: - If the sender gives a complete DNS record set, publish that record set only after confirming it belongs to the selected account and domain. - If the sender gives more than one record, treat the set as one configuration request. Do not assume one record is optional. - If the sender asks you to edit an existing record, compare the current DNS answer with the sender's documented migration instructions before making any replacement. - If the sender also supplies SPF guidance, handle it as a separate review. Do not replace an existing SPF TXT record without understanding how the existing policy and the sender's required authorization fit together. - If the sender cannot identify the domain it will sign with, pause the DNS change. DNS publication alone cannot answer that question. ![Four-layer validation flow for a Cloudflare DKIM setup: DNS, sender, message, and DMARC evidence](/images/editorial/cloudflare-dkim-setup/cloudflare-dkim-setup-validation-layers.webp "1200x676") _Source: Palisade._ Cloudflare-specific interface labels and record-entry behavior can change. This guide therefore does not prescribe a dashboard menu path, proxy setting, field name, or save control. Use the current authenticated Cloudflare experience and the sender's official domain-authentication instructions as the source of those details. For a comparable DNS-provider workflow, see [how to add a DKIM record in GoDaddy](/learning/add-dkim-record-godaddy). The record values must still come from your own sender account. ## How to configure Cloudflare DKIM ### 1. Identify the exact sending path Select one application or sender that produces mail with the domain you are configuring. Confirm the From domain used by that path and the person responsible for the sender account. Do not group unrelated mail streams into one unverified change. A successful configuration for a marketing sender does not establish that transactional messages, employee mail, or gateway-relayed mail use the same signing identity. ### 2. Obtain the sender-generated DKIM instructions Open the domain-authentication or DKIM configuration area in the sender that sends the selected mail. Collect the complete instruction set for the account and domain: record type, owner name, content or target, expected signing domain, and the sender's own verification action. The sender generates these values. Cloudflare publishes them in the DNS zone. If the sender's instructions conflict with an old ticket, screenshot, or copied record, use the sender's current account-generated values and investigate the discrepancy before publishing. The following is an illustrative shape only. It is not a Cloudflare record and must not be published. ```text Illustrative only Record type: <sender-generated TXT or CNAME> Owner name: <sender-generated selector or owner under yourdomain.com> Value: <sender-generated public key, target, or verification value> Expected signing domain: <sender-generated domain> ``` > Do not publish placeholders or substitute a selector, target, token, or public key from another tenant. Copy the real values only from the sender account that will sign this domain's mail. ### 3. Open the authoritative Cloudflare DNS zone Sign in to the Cloudflare account that controls the authoritative zone for the selected domain. Confirm the zone name before creating or editing a record. The current authenticated navigation path, record form, supported record types, and save behavior were not verified by the available primary source. Confirm those details in current Cloudflare documentation or directly in the authenticated account. If the account does not clearly show that it controls the intended zone, stop and identify the authoritative DNS provider before making a change. ### 4. Publish the sender's record without altering its meaning Enter only the sender-generated record type, owner name, and value or target. Check the final owner name that the Cloudflare interface displays before saving, especially if the sender supplied a fully qualified name. Do not merge separate DKIM records into one value. Do not place another record beside a sender-provided CNAME at the same owner name without confirming that the sender's documentation permits it. If a record already exists at the owner name, compare it with the sender's documented rotation path rather than overwriting it. Keep the DNS change narrowly scoped. Record the time, the intended owner name, the sender account, and the approver. These details let you match later sender status and message-header evidence to the change you actually made. ### 5. Use the sender's current verification action Return to the sending service after the DNS record is visible as expected. Use the verification action and status described by that sender's current documentation or account interface. Treat the sender's status as sender-specific evidence. It can show what that service sees for its domain configuration. It cannot prove that every production mail path signs with the intended identity or that a recipient accepted a particular message. ## How to validate the setup A working Cloudflare DKIM setup needs separate evidence at four layers. Do not mark the change complete from a single green status or public lookup. - **DNS:** Inspect the published owner name through the authoritative DNS path and at least one public resolver. Compare the observed record type and value or target with the sender-generated instruction. A public lookup can show only public DNS state. - **Sender:** Record the sender's current verification or authentication status for the exact account and domain. This connects the published record to the service that is expected to sign. - **Message:** Send a new message through the exact production path. Inspect its complete headers in the receiving mailbox and retain a redacted copy of the authentication evidence. Do not use an older message that predates the DNS change. - **DMARC:** After reports accumulate, review the source and authentication results for the configured mail stream. A delivered-message check is evidence for one tested path and time. Reporting helps identify whether additional sources or alignment problems remain. Use a compact acceptance record so the evidence stays tied to the intended sender: ```yaml sending_path: <application or sender> from_domain: <visible From domain> dns_owner: <sender-generated owner name> dns_result: <observed record type and value or target> sender_status: <sender-reported result> test_message: <timestamp and redacted header reference> dmarc_reporting: <observed source and status after reports accumulate> rollback_status: <unchanged or restored prior configuration> ``` The [DKIM checker](/tools/dkim) can inspect public DKIM DNS after publication. Compare the result with the sender's record instruction, then continue with sender status and a delivered-message test. A DNS lookup cannot prove that the private key is installed, that the intended application signed a production message, that DMARC aligned, or that a receiver will place future mail in the inbox. A correct DKIM record also does not replace SPF. The two controls evaluate different parts of the sending path. Keep their evidence separate when you review the final message. ## Troubleshooting ### The sender cannot verify the published record Start with the sender-generated instruction set and the DNS answer for the exact owner name. Confirm that the selected Cloudflare zone is the authoritative zone and that the record type matches the sender's current instruction. Then compare the owner name and complete value or target with the sender account. Do not assume that a copied value, a record from a prior domain, or a record from another account is interchangeable. ### The DNS result differs from the sender's instruction Stop before making another change. Confirm whether the Cloudflare interface rendered a different final owner name than intended, whether an existing record is still present, and whether the sender generated a replacement as part of a rotation. Use the sender's documented migration guidance for any replacement. Avoid deleting a known working record while the cause is unknown. ### The sender reports success but the delivered message lacks expected evidence Send a new message through the exact application and route you configured. Check that the message was not sent by a different platform, alias, or gateway. Collect the raw headers in redacted form and compare the visible From domain, sending route, and authentication evidence with the sender configuration. Do not conclude that Cloudflare DNS is wrong from sender status alone. ### DKIM evidence exists but the DMARC result remains unresolved Keep the DNS, sender, message, and reporting layers separate. A published record or a sender status does not show how every source using the domain behaves over time. Review the mail stream in DMARC aggregate reports once data accumulates. For recurring multi-sender or multi-domain work, Palisade autonomously analyzes DMARC aggregate-report data, identifies sending sources and authentication or alignment issues, and creates prioritized remediation tickets. It proposes the next policy step based on evidence, while a human reviews the evidence and applies any policy change. ## Inspect the published DKIM record before the message test Check the exact domain after you publish the sender-generated record, then compare the public result with the sender's account instructions. This catches an incorrect public DNS owner or value before you rely on the sender's status. [Check the DKIM record](/tools/dkim) The checker inspects public DNS only. It does not repair a record, monitor later DNS drift, prove that a specific sender signed production mail, or guarantee recipient placement. If your team needs to follow the same unresolved sources and alignment issues across domains after reports arrive, [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=vendor_setup&utm_content=cloudflare-dkim-setup). Palisade analyzes report data and proposes remediation work for human review. It does not autonomously change your DNS or DMARC policy. ## Sources and further reading - [Cloudflare public site](https://cloudflare.com) - [Palisade DKIM checker](/tools/dkim) - [Vendor email authentication guide](/learning/esp-setup) - [RFC 9989: Domain-based Message Authentication, Reporting, and Conformance](https://www.rfc-editor.org/rfc/rfc9989.html) ## Frequently asked questions ### Can Cloudflare generate my DKIM record? No. The sending service that signs the mail must generate the account-specific DKIM record instruction. Cloudflare's role in this setup is publishing the sender-provided DNS record in the authoritative zone. ### Can I copy a DKIM selector from another Cloudflare account? No. A selector, public key, CNAME target, or verification value can be tied to a different sender account or domain. Use only the values generated for the exact sender and domain you are configuring. ### Does a public DKIM lookup prove my sender is working? No. A public lookup can inspect the published DNS record. It cannot prove that the sender has the matching private key, that the application signed a new production message, or that DMARC aligned. ### Should I replace an existing DKIM record with a new sender's value? Not without the sender's documented rotation or migration procedure. An existing selector can support active mail, delayed messages, or another sending path. Compare the sender-generated owner name with the current record before changing anything. ### Does Cloudflare DKIM setup also configure SPF? No. SPF and DKIM are separate sender-authentication controls. Review any SPF instruction separately and do not replace an existing SPF record until its effect on the current policy is understood. --- # How to set up DKIM keys in Salesforce Canonical: https://www.palisade.email/learning/dkim-keys-salesforce > DKIM keys in Salesforce: create primary and alternate CNAME records, activate signing, and validate DNS, headers, and DMARC reporting for Salesforce email. To set up DKIM keys for Salesforce platform email, open **Setup > DKIM Keys**, select **Create New Key**, then publish the primary and alternate CNAME records Salesforce generates before activation. This path is verified from Salesforce's [Create a DKIM Key documentation](https://help.salesforce.com/s/articleView?id=sf.emailadmin_create_secure_dkim.htm&language=en_US&type=5). The selectors and CNAME targets are specific to your Salesforce org and sending domain. Do not reuse values from another org, example, or Salesforce product. ## Quick takeaways - Salesforce platform email creates a primary and alternate DKIM CNAME record for each configured key. - Both CNAME records need to remain published for Salesforce-managed key rotation. - Salesforce documents a 2048-bit RSA key recommendation unless a particular application requires a smaller key. - This workflow covers Salesforce platform email, not Marketing Cloud or Salesforce-connected mailbox integrations. - A Salesforce active status does not prove that a new production message has a valid DKIM signature. - DKIM supports DMARC only when the DKIM signing domain aligns with the visible From domain. ## What should I check before configuring Salesforce? Confirm that Salesforce platform email is the sender you need to authenticate. This guide does not cover Marketing Cloud, Marketing Cloud Advanced, Gmail or Office 365 integrations, Einstein Activity Capture, or Salesforce-owned sending domains. Those paths can use different sender-verification and authentication controls. Salesforce lists the **Customize Application** permission for managing DKIM keys in its [DKIM setup instructions](https://help.salesforce.com/s/articleView?id=sf.emailadmin_create_secure_dkim.htm&language=en_US&type=5). You also need access to the authoritative DNS zone for the domain in the visible From address, or an approved DNS owner who can publish the records. Record the Salesforce org, the sending domain, the DNS zone, the approver, and a test mailbox where you can inspect raw headers. If Salesforce sends from a subdomain, treat it as separate scope. Salesforce says that sending subdomains need separate DKIM keys. For broader context on vendor-managed authentication, see the [vendor email authentication hub](/learning/esp-setup). > Copy DNS values from the account and domain you are configuring. Do not publish selectors, targets, tokens, or hostnames from another account or from an online example. ## Which setup method should I use? Use the primary and alternate CNAME records generated by Salesforce for the selected domain. Salesforce manages the signing key material. Your DNS records delegate the public-key lookup location to Salesforce instead of publishing a DKIM TXT key directly. Choose selectors that do not collide with existing selectors for another sender. Salesforce documents primary selector, alternate selector, domain, RSA key size, and domain match pattern fields. For a domain you own, Salesforce instructs administrators to use an exact domain match pattern rather than a wildcard. A dedicated IP does not replace DKIM. IP assignment and domain signing are separate controls. Select the domain that appears in the visible From address for the Salesforce platform email path under review. ![Salesforce DKIM Keys page showing the key list and Create New Key control](/images/editorial/dkim-keys-salesforce/salesforce-dkim-keys-list.png "1920x1080") *Source: [Create a DKIM Key](https://help.salesforce.com/s/articleView?id=sf.emailadmin_create_secure_dkim.htm&language=en_US&type=5), checked 2026-07-29.* ## How do I configure SPF and DKIM for Salesforce? Salesforce platform DKIM setup creates CNAME records. It does not add an SPF record to your DNS zone. Do not publish a second SPF TXT record. SPF permits one record per domain, so review the existing [SPF policy](/tools/spf) separately if Salesforce is expected to send mail using that domain. ### 1. Open DKIM Keys in Salesforce Setup In Salesforce, open **Setup**, enter `DKIM Keys` in Quick Find, select **DKIM Keys**, then select **Create New Key**. This is the path in Salesforce's [current setup documentation](https://help.salesforce.com/s/articleView?id=sf.emailadmin_create_secure_dkim.htm&language=en_US&type=5). Check that you are in the intended Salesforce org before creating a key. Sandbox and production orgs can generate different configuration values. ### 2. Select the sending domain and selectors Enter the domain used in the visible From address. Choose a primary selector and an alternate selector that do not already exist in the DNS zone. Select the RSA key size and domain match pattern Salesforce documents for the type of domain you are configuring. The Salesforce form below shows the key-creation fields. It is evidence of the interface path, not a source of reusable selector names or CNAME targets. ![Salesforce Create a DKIM Key form showing selector, alternate selector, RSA key size, and domain match pattern fields](/images/editorial/dkim-keys-salesforce/salesforce-create-dkim-key-form.png "1920x1080") *Source: [Create a DKIM Key](https://help.salesforce.com/s/articleView?id=sf.emailadmin_create_secure_dkim.htm&language=en_US&type=5), checked 2026-07-29.* ### 3. Publish both Salesforce-generated CNAME records Open the new key's details page and copy both generated record pairs: the primary CNAME owner and target, then the alternate CNAME owner and target. Salesforce documents both records as part of the setup and says its corresponding records usually finish publishing within 15 minutes. Your DNS provider and resolver caches can add delay. The following shapes are illustrative only. They are not Salesforce values and cannot authenticate mail. - Record type: `CNAME` - Host: `primary1._domainkey.example.com` - Value: ```text primary1.salesforce-generated.example.net ``` - Record type: `CNAME` - Host: `alternate1._domainkey.example.com` - Value: ```text alternate1.salesforce-generated.example.net ``` > Do not publish these examples. Copy both complete hosts and targets from the DKIM Key Details page in your own Salesforce org. Some DNS providers append the zone name automatically. If the zone is `example.com`, entering `primary1._domainkey.example.com` in a host field that appends the zone can create a duplicated owner name. Inspect the final fully qualified owner before saving. A CNAME cannot coexist with a TXT record or other DNS data at the same owner. If a selector already belongs to another sender, do not overwrite it. Choose a different Salesforce selector or use that sender's documented rotation process. For more detail on this record type, see [how DKIM CNAME records work](/learning/dkim-cname). ![Illustrative primary and alternate Salesforce DKIM CNAME record structure](/images/editorial/dkim-keys-salesforce/dkim-keys-salesforce-records.webp "1200x466") *Source: Palisade.* ![Salesforce DKIM Key Details view showing generated CNAME fields and key status](/images/editorial/dkim-keys-salesforce/salesforce-dkim-key-details.png "800x404") *Source: [Create a DKIM Key](https://help.salesforce.com/s/articleView?id=sf.emailadmin_create_secure_dkim.htm&language=en_US&type=5), checked 2026-07-29.* ### 4. Verify DNS and activate the key Query both CNAME owners after publishing them. Compare the authoritative DNS response and at least one public resolver with the complete targets shown in Salesforce. Activate the key only after Salesforce detects the records. Salesforce warns that DNS changes can take up to 72 hours to propagate in relevant cases. A DNS-provider confirmation screen is not enough evidence. If Salesforce cannot detect the records, compare the complete owner and target before changing the zone again. ### 5. Send a real message through Salesforce Send a new message through the exact Salesforce production path to a mailbox where you can view raw source. Do not use a message sent before activation. Inspect the message for a `DKIM-Signature` header with the expected selector and signing domain. Then inspect the receiver-added authentication result. [RFC 8601 defines Authentication-Results and its trust boundary](https://www.rfc-editor.org/rfc/rfc8601.html). ## Investigate this with your coding agent Use this after Salesforce generates both CNAME pairs when your DNS zone is managed as code. Provide only the generated host and target values and current public DNS answers. ```agent Problem: The Salesforce DKIM primary and alternate CNAME records must be present in the authoritative DNS source without selector collisions. Evidence: PRIMARY_HOST, PRIMARY_TARGET, ALTERNATE_HOST, ALTERNATE_TARGET, ZONE, and redacted current authoritative and public CNAME answers. Repository scope: The DNS zone configuration, its tests, and the deployment runbook. Constraints: Inspect before editing. Do not apply changes until I approve the proposed diff. Do not access Salesforce, credentials, private keys, tokens, or make changes outside the two Salesforce-generated CNAME records. Requested output: Current-state diagnosis, minimal proposed change, selector collision checks, rollback steps, missing inputs, and unknowns. Verification: Query both CNAME owners against the authoritative server and a public resolver, then compare the answers with the Salesforce-generated targets before activation. Stop if: Generated values are missing, a selector collision exists, the DNS zone is outside the repository, credentials or private data are required, or any production mutation is needed. ``` ## How does this setup affect DMARC? A valid DKIM signature supports DMARC only when the `d=` domain aligns with the visible From domain. [RFC 9989 defines DKIM identifier alignment for DMARC](https://www.rfc-editor.org/rfc/rfc9989.html#section-4.4.1). A passing Salesforce signature for an unrelated domain does not create a DKIM-aligned DMARC pass. Salesforce documents that it rotates active DKIM keys every 30 days through the alternate key. Keep both generated CNAME records published so the alternate key remains available during rotation. Review [DKIM key rotation guidance](/learning/cloudflare-dkim-setup) separately when another DNS-managed sender also uses the domain. Use the [DMARC checker](/tools/dmarc) to inspect the domain's published DMARC policy before changing enforcement. A public policy lookup does not prove that Salesforce messages pass alignment. ## How do I validate the setup? ### Check public DNS Look up each exact CNAME owner generated by Salesforce. Confirm the authoritative DNS server and at least one public resolver return the expected target. ```bash dig +short CNAME <primary-selector>._domainkey.<sending-domain> dig +short CNAME <alternate-selector>._domainkey.<sending-domain> ``` ### Check the Salesforce status Return to the DKIM Key Details page and confirm the selected key is active. This confirms that Salesforce accepted the DNS configuration for that key. It does not prove a particular production route is signing messages. ### Inspect a delivered message Inspect a new message sent through Salesforce. Confirm that `DKIM-Signature` includes the expected `s=` selector and `d=` signing domain, then check the trusted receiver-added result for `dkim=pass`. Accept the message-level result only when the signing domain aligns with the visible From domain if DKIM is expected to satisfy DMARC. ### Review DMARC reports After DMARC reports accumulate, review Salesforce traffic separately from other sources using the domain. DMARC aggregate reports can show whether the source passes DKIM and aligns over a reporting window. They do not replace the immediate DNS, Salesforce, and delivered-message checks. ## Troubleshooting ### Salesforce does not show Activate Confirm that both generated CNAME records resolve publicly to the exact targets shown in the Salesforce key details. Check for a duplicated zone suffix and compare the authoritative answer before waiting for propagation. ### A CNAME record cannot be saved Inspect the existing DNS owner. A CNAME cannot share its owner name with a TXT record, another CNAME, or other DNS data. Do not delete another sender's selector to make room for Salesforce. ### Salesforce is active but DKIM fails in a message Verify that the message came through the Salesforce path that the key covers. Compare its `s=` selector and `d=` domain with the key details, then inspect whether an outbound gateway modified the message after signing. ### DKIM passes but DMARC fails Compare the `d=` value in the DKIM signature with the visible From domain. A valid DKIM signature can still fail DMARC alignment when the domains do not align. ### The alternate selector is missing Restore the alternate CNAME from the values generated by the same Salesforce org. Salesforce uses the alternate key for its documented rotation process. Do not substitute a target from another org. ## Check both Salesforce selectors before activation Run the sending domain and each Salesforce selector through the [Palisade DKIM checker](/tools/dkim), then compare the public CNAME result with the account-generated values in Salesforce. This resolves the public-DNS question left after you publish the two records. A point lookup cannot inventory every sending source or show authentication behavior across a reporting window. Palisade is agentic DMARC software that analyzes DMARC aggregate reports, identifies authentication and alignment issues, and creates prioritized remediation tickets for a human to review. It does not change Salesforce settings or DNS, activate a key, guarantee signing or alignment, or control a receiver's decision. If you need that ongoing report-based view after the selector check, [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=vendor_setup&utm_content=dkim-keys-salesforce). A DNS lookup cannot prove production signing, message-level alignment, or receiver handling. ## Sources and further reading - [Salesforce: Create a DKIM Key](https://help.salesforce.com/s/articleView?id=sf.emailadmin_create_secure_dkim.htm&language=en_US&type=5) - [Salesforce: Considerations for DKIM Keys](https://help.salesforce.com/s/articleView?id=emailadmin_considerations_dkim.htm&language=en_US&type=5) - [Salesforce: Requirements to send email from Salesforce](https://help.salesforce.com/s/articleView?id=xcloud.security_email_verification_requirements.htm&language=en_US&type=5) - [RFC 8601: Authentication-Results](https://www.rfc-editor.org/rfc/rfc8601.html) - [RFC 9989: Domain-based Message Authentication, Reporting, and Conformance (DMARC)](https://www.rfc-editor.org/rfc/rfc9989.html) ## Frequently asked questions ### Does Salesforce DKIM use TXT records? No. Salesforce platform email generates primary and alternate CNAME records for its DKIM configuration. Copy both account-generated CNAME owners and targets from the Salesforce DKIM Key Details page. ### Do I need both Salesforce DKIM CNAME records? Yes. Salesforce generates primary and alternate CNAME records, and its documented key rotation uses the alternate key. Keep both records published after activation. ### Can I use the same selector for Salesforce and another email sender? No. A selector owner cannot contain a Salesforce CNAME alongside another DNS record. Choose a unique selector or follow the existing sender's rotation process without overwriting active DNS data. ### Does an active Salesforce DKIM key mean DMARC passes? No. Salesforce activation confirms its key configuration, but DMARC also requires DKIM alignment with the visible From domain. Inspect a delivered message and later review DMARC aggregate reports. ### Does this Salesforce DKIM setup apply to Marketing Cloud? No. This guide covers Salesforce platform email. Marketing Cloud and other Salesforce-connected sending paths have separate configuration and verification behavior. ### How often does Salesforce rotate DKIM keys? Salesforce documents a 30-day rotation for active DKIM keys. The alternate CNAME record must remain published so Salesforce can use the alternate key during that process. --- # DMARC for Google Workspace Canonical: https://www.palisade.email/learning/dmarc-google-workspace > Set up DMARC for Google Workspace: turn on DKIM in the Admin console, publish one TXT record at _dmarc in your DNS host, then verify before enforcing. **To set up DMARC for Google Workspace, turn on DKIM in the Admin console under Apps, Google Workspace, Gmail, Authenticate email, then publish one TXT record at `_dmarc.yourdomain.com` in your DNS host with a value such as `v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com`.** The record does not live in the Admin console. Google's own wording is that a DMARC record is a line of text you add to your domain, following your domain provider's instructions. ## Quick takeaways - The Admin console is where DKIM is turned on. The DMARC record itself goes wherever your domain's nameservers point, which may be a different company from your registrar. - Google documents the sequence as four steps: set up a mailbox for reports, make sure third-party senders authenticate, decide the record, then add it to your domain. - Google requires SPF or DKIM before DMARC will do anything useful, because DMARC only evaluates their results. - Since 1 February 2024, senders of close to 5,000 or more messages a day to personal Gmail accounts must publish a DMARC record. Google states the policy can be set to `none` to comply. - Google's own published example record still contains `pct=100`, a tag [RFC 9989](https://www.rfc-editor.org/rfc/rfc9989.html) removed in May 2026. Leave it out of new records. ## Inventory your senders first DMARC is evaluated against the domain in the visible `From` header, not against Google Workspace. So the policy reaches every system that sends as your domain, and Workspace is usually only one of them. Before touching DNS, write down each one: ticketing systems, marketing platforms, transactional services like invoicing or password resets, outbound gateways, and anything a department signed up for on its own. A policy published without that list is how a `p=reject` takes down a billing system nobody remembered. Alongside the list you need: - Access to the authoritative DNS zone for the `From` domain. - A named owner for each sending system who can check its authentication settings and send a test message. - The current SPF record, and the current DKIM status for each sender rather than for the domain as a whole. - A mailbox or reporting service ready to receive aggregate reports before the record goes live. - A rollback owner who can restore the previous DMARC value if enforcement exposes a sender the inventory missed. If the relationship between the `From` domain, SPF, DKIM, and policy is still unclear, [what DMARC is](/learning/what-is-dmarc) covers it. The protocol is domain-wide even when the immediate task is Google Workspace. ## Before you start: turn on DKIM DMARC performs no authentication of its own. It reads the results of SPF and DKIM and asks whether the domain that passed matches the domain in the visible `From` header. Publishing a DMARC record before either is in place produces reports of your own mail failing, and nothing else. Google Workspace signs outbound mail with DKIM once you generate a key and publish it, and [setting up DKIM for Google Workspace](/learning/dkim-google-workspace) covers that on its own. The [documented path](https://support.google.com/a/answer/174124) is: 1. In the Google Admin console, go to **Menu**, then **Apps**, **Google Workspace**, **Gmail**. This requires the Gmail Settings administrator privilege. 2. Click **Authenticate email**, then choose the domain in the **Selected domain** menu. 3. Click **Generate New Record**. Google recommends a 2048-bit key where the domain provider supports it. Its [sender guidelines](https://support.google.com/a/answer/81126) add that sending to personal Gmail accounts requires a key of at least 1024 bits. 4. Publish the generated TXT record at the host `google._domainkey` in your DNS, then return to **Authenticate email** and click **Start authentication**. When it is working, the status at the top of that page changes to "Authenticating email with DKIM". Google notes that you cannot verify DKIM by sending yourself a test message, so send to a separate Gmail or Google Workspace mailbox instead. Google asks you to allow 48 hours after SPF or DKIM is in place before setting up DMARC, so that both are authenticating real mail first. SPF is a separate record in the same DNS zone. If Google Workspace is your only sender, `v=spf1 include:_spf.google.com ~all` is the [shape Google documents](https://support.google.com/a/answer/10684623), but every other service that sends as your domain has to be represented too. ## How to set up DMARC for Google Workspace Google's [Set up DMARC](https://support.google.com/a/answer/2466580) page breaks the work into four steps, and they are worth following in that order. ### 1. Set up a mailbox or group for reports Aggregate reports arrive as XML, one file per receiver per day. Point the `rua` tag at a mailbox you control. Gmail does not support the `ruf` tag at all, so a forensic address on a Workspace domain collects nothing from Google. On a domain of any size, reading them by hand stops being practical almost immediately, which is why most people point the reporting address at a monitoring service rather than a person's inbox. If you send reports to an address on a different domain, that domain has to publish an authorization record before receivers will send anything. This is the quietest failure in the whole setup: the record looks correct, and no reports ever arrive. ### 2. Make sure third-party senders authenticate Authenticating third-party senders is the step that decides how long the rest takes. A CRM, a billing platform, a help desk, a marketing tool, and a form on the website can all use the same `From` domain while authenticating differently, or not at all. Each one needs either an SPF authorization or a DKIM signature that aligns with your domain. Work through the inventory you built above, sender by sender. ### 3. Decide the record Start at `p=none`. Receivers deliver everything exactly as before and send you reports naming every source using the domain, which is the evidence the later steps depend on. ```text v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com ``` One caveat about Google's own documentation. The example record on Google's Set up DMARC page includes `pct=100`, and RFC 9989 removed the `pct` tag in May 2026, along with `rf` and `ri`. A record carrying it is not broken, but new records should leave it out. Google's example also sets `adkim=s; aspf=s`, which is strict alignment on both. Relaxed alignment is the default and suits nearly every domain, because legitimate services routinely send from subdomains. Choose strict only when you know exactly which senders exist. ### 4. Add the record to your domain Publish it as a TXT record in the DNS zone that answers for the domain. Google documents the fields as the record type `TXT`, the host `_dmarc.yourdomain.com`, and the value being the DMARC string itself. Two details cause most of the confusion here. The first is that this is not an Admin console setting: there is no DMARC page in Google Workspace to switch on. The second is that your registrar may not be your DNS host. Running `dig NS yourdomain.com` settles it. Whichever nameservers come back is where the record belongs, and the provider guides for [Cloudflare](/dmarc-setup/cloudflare), [GoDaddy](/dmarc-setup/godaddy), [Namecheap](/dmarc-setup/namecheap) and [Amazon Route 53](/dmarc-setup/route-53) cover the click paths. For the provider-neutral version of this whole sequence, see [how to set up DMARC](/dmarc-setup). ## What Gmail actually requires Google's [Email sender guidelines](https://support.google.com/a/answer/81126) set two tiers, and the distinction matters because a lot of writing on this subject collapses them. ![Two columns comparing what Gmail requires from every sender against the additional requirements for bulk senders, meaning close to 5,000 or more messages to personal Gmail accounts in 24 hours](/images/editorial/dmarc-google-workspace/gmail-sender-requirements.webp "1200x533") *Source: Palisade.* Every sender to Gmail, at any volume, must set up SPF or DKIM, have valid forward and reverse DNS records for sending domains or IPs, use TLS, keep the spam rate reported in Postmaster Tools below 0.30%, and format messages to RFC 5322. Google's [sender guidelines FAQ](https://support.google.com/mail/answer/14229414) defines a bulk sender as one sending **close to 5,000 messages or more** to personal Gmail accounts within a 24-hour period, counted by primary domain, and says the status does not expire once assigned. "Close to" is doing real work there. Google publishes no lower bound, so treat a domain steady at 4,700 a day as inside the rule rather than outside it. Bulk senders must, since 1 February 2024, additionally set up both SPF and DKIM, publish a DMARC record, align the `From` header domain with either the SPF domain or the DKIM domain, and support one-click unsubscribe on marketing and subscribed messages. Google states plainly that the DMARC enforcement policy can be set to `none` to meet this requirement. That last sentence is the one worth internalizing. Publishing `p=none` satisfies the letter of Google's rule while leaving the domain fully spoofable, which is why so many domains stop there and report themselves as compliant. ## How to validate the setup Validation runs at four layers, and a pass at one says nothing about the others. ![Checklist of DNS, sender, delivered-message, and reporting evidence needed before a Google Workspace DMARC decision](/images/editorial/dmarc-google-workspace/dmarc-google-workspace-evidence-checklist.webp "1200x524") *Source: Palisade.* - **Public DNS.** Query `_dmarc.yourdomain.com` as a TXT record at a public resolver with `dig +short TXT _dmarc.yourdomain.com @8.8.8.8`. Confirm exactly one policy record comes back and that its value is the one you intended. If two come back, [multiple DMARC records](/learning/multiple-dmarc-records) is its own failure mode: receivers treat the domain as having no usable policy. - **Google Workspace.** Confirm the **Authenticate email** page shows "Authenticating email with DKIM" for the domain in scope. - **A delivered message.** Send a message through each production sender and read the `Authentication-Results` header the receiving system added. This is the only layer that shows whether a sender actually authenticates. - **Aggregate reports.** Review reports across enough normal sending to cover every known source. This is what decides whether it is safe to tighten the policy. You can inspect the published record with the [DMARC checker](/tools/dmarc), and read what the reports are telling you with the [DMARC report analyzer](/tools/dmarc-report-analyzer). ## Moving past monitoring ![Three-stage DMARC policy progression from monitor to quarantine to reject](/images/editorial/dmarc-google-workspace/dmarc-google-workspace-policy-progression.webp "1200x589") *Source: Palisade.* Move in stages and read the reports at each one. `p=quarantine` sends failing mail to spam, which is recoverable if you missed a sender. `p=reject` refuses it, which is not. If subdomains send mail and are not ready, the `sp` tag gives them their own policy so the parent domain can enforce without breaking them. ## Troubleshooting ### The record is missing from a public lookup Query `_dmarc.yourdomain.com` rather than the root domain, and check for a duplicated zone suffix such as `_dmarc.yourdomain.com.yourdomain.com`, which happens when the DNS host appends the zone to a fully qualified name. If a different provider is authoritative for the domain, the record you added elsewhere will never resolve however correct it looks. ### DKIM shows as not authenticating Google notes that a newly created Google Workspace account may need to wait before a key can be generated, and that generating a key is not the same as turning authentication on. Publish the `google._domainkey` TXT record first, then return to **Authenticate email** and click **Start authentication**. Verify by sending to a different mailbox, since a message to yourself does not prove DKIM is working. ### Mail from another application fails after enforcement Compare the visible `From` domain against the SPF `smtp.mailfrom` domain and the DKIM `d=` domain for an affected message. An SPF or DKIM pass that does not align with the `From` domain is not a DMARC pass. Return the policy to the last known-good value while you fix that sender, rather than deleting the record, which also removes the reporting you need to diagnose it. ### Gmail returns a 4.7.31 rate-limit error Google's wording is that the message "has been rate limited because the sending domain doesn't have a DMARC record, or the DMARC record doesn't specify a DMARC policy". It is a throttle, not a bounce, and it names the two conditions that trigger it: no record at `_dmarc`, or a record without a usable `p=` tag. Publish a record with an explicit policy, starting at `p=none`, and confirm it resolves before retrying the send. ### No aggregate reports are arriving Check that the `rua` address is valid and accepts external mail, and that it matches the published record. If it is on a different domain, that domain has to authorize it. Some receivers never send reports at all, so silence from one receiver is not evidence of a broken record. ## Where Palisade fits Palisade is agentic DMARC software. It reads the aggregate reports the record generates, identifies every sending source and the authentication or alignment issues behind each one, and files prioritized remediation tickets. It proposes the next policy step when the evidence supports it, and a person reviews and applies every change. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=existing_content_migration&utm_content=dmarc-google-workspace) ## Sources and further reading - [Set up DMARC, Google Workspace Admin Help](https://support.google.com/a/answer/2466580), checked 21 August 2026 - [Turn on DKIM for your domain, Google Workspace Admin Help](https://support.google.com/a/answer/174124), checked 21 August 2026 - [Email sender guidelines, Google Workspace Admin Help](https://support.google.com/a/answer/81126), checked 21 August 2026 - [Email sender guidelines FAQ, Gmail Help](https://support.google.com/mail/answer/14229414), checked 24 August 2026, for the bulk-sender definition and the `4.7.31` error - [RFC 9989: Domain-based Message Authentication, Reporting, and Conformance](https://www.rfc-editor.org/rfc/rfc9989.html) - [How to set up DMARC](/dmarc-setup) and [what a DMARC record is](/learning/dmarc-record) ## Frequently asked questions ### Does Google Workspace have DMARC? Google Workspace supports DMARC, but it does not host the record for you. The Admin console is where you turn on DKIM signing, under Apps, Google Workspace, Gmail, Authenticate email. The DMARC record itself is a DNS TXT record you publish at your domain's DNS host. Google's own documentation describes it as a line of text you add to your domain following your domain provider's instructions. ### How do I add DMARC to Google? Publish a TXT record at `_dmarc.yourdomain.com` in the DNS zone that answers for your domain, with a value such as `v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com`. Do it after SPF or DKIM is working, because DMARC only evaluates their results. Bulk senders, meaning close to 5,000 or more messages a day to personal Gmail accounts, need both. There is no setting inside Google Workspace that publishes this record for you. ### Why am I getting a DMARC report from Google? Because your DMARC record asks for one. The `rua` tag names the address receivers send daily aggregate reports to, and Gmail is one of the receivers that sends them. The report is an XML summary of the messages Gmail saw claiming to be from your domain, and whether each one passed SPF, DKIM, and alignment. It is the evidence the whole rollout depends on, not a warning. ### Does Gmail require DMARC now? For bulk senders, yes, since 1 February 2024. Google defines those as senders of close to 5,000 or more messages to personal Gmail accounts in 24 hours, and its sender guidelines require them to set up SPF and DKIM, publish a DMARC record, and align the `From` domain with the SPF or DKIM domain. Google states the DMARC policy can be set to `none` to comply. Below that volume, SPF or DKIM is required but a DMARC record is not, though unauthenticated mail increasingly lands in spam regardless of volume. ### Should I use the example record from Google's documentation? Use its shape, not its contents. Google's published example includes `pct=100`, a tag RFC 9989 removed in May 2026, and sets strict alignment on both SPF and DKIM. Start with relaxed alignment, which is the default, and leave `pct` out. The reporting address in any example is someone else's, so replace it with a mailbox you control. ### Can a DMARC checker prove Google Workspace is configured correctly? No. A checker reads the public DNS record and parses it. It cannot tell you whether Google Workspace signed a particular message, whether another application sharing your domain authenticates, or how a receiver will treat future mail. Only a delivered message's `Authentication-Results` header and the aggregate reports answer those. --- # How to set up SPF and DKIM for Brevo (formerly Sendinblue) Canonical: https://www.palisade.email/learning/how-do-i-set-up-spf-and-dkim-for-brevo > How to set up SPF and DKIM for Brevo: authenticate the sending domain, publish Brevo's account-generated DNS records, then validate a real message. To set up email authentication for Brevo, open **Settings > Senders, Domains, IPs > Domains**, add the domain used in your From address, then choose Brevo's automatic or manual authentication flow. Manual authentication displays account-generated Brevo code, DKIM, and DMARC DNS records. Do not add an SPF include unless Brevo's dedicated-IP configuration for your account explicitly supplies one. ## Quick takeaways - Brevo's documented domain-authentication flow starts at **Settings > Senders, Domains, IPs > Domains**. - Automatic authentication connects Brevo to a supported DNS provider, while manual authentication gives you records to publish yourself. - Brevo can display either one DKIM TXT record or two DKIM CNAME records for an account. - Copy every Brevo DNS value from the selected account and domain, not from an online example. - A domain must have one SPF TXT record, so merge mechanisms into an existing record instead of creating a second SPF record. - A vendor verification result does not prove that a real message passed DKIM or DMARC. ## What should I check before configuring Brevo? Confirm which mail stream Brevo sends. This guide applies to messages sent through Brevo, such as marketing campaigns or transactional mail configured in Brevo. It does not automatically authenticate employee mail sent through Microsoft 365, Google Workspace, or another mailbox provider. You need access to the Brevo account that owns the sender domain and permission to change its authoritative DNS zone. Confirm the visible From domain before adding records. A subdomain used for campaign mail can have a different DNS zone and authentication plan from the parent domain. Brevo's [domain authentication instructions](https://help.brevo.com/hc/en-us/articles/12163873383186-Authenticate-your-domain-with-Brevo-Brevo-code-DKIM-DMARC) document the current settings path and authentication options. The path was verified from official documentation. The DNS values displayed in the account are the configuration source for the selected domain. > Copy DNS values from the account and domain you are configuring. Do not publish selectors, targets, tokens, or hostnames from another account or from an online example. Also check for existing SPF and DMARC records before making a DNS change. Publishing a second SPF policy at the same domain can create an SPF PermError. Replacing an existing DMARC record can remove reporting destinations or weaken an established policy. ## Which setup method should I use? Use automatic authentication when the approved DNS provider account can be connected to Brevo and the domain has no existing records that require a manual review. Use manual authentication when DNS changes go through an IT approval process, DNS-as-code workflow, external administrator, or an existing DMARC policy that must remain intact. Choose the records Brevo presents for the selected domain. Brevo documents automatic and manual flows, plus the option to have another person authenticate the domain when they control DNS access. ![Brevo domain authentication dialog showing the flow for adding a domain](/images/editorial/how-do-i-set-up-spf-and-dkim-for-brevo/brevo-add-domain.jpg "2642x1054") *Source: [Authenticate your domain with Brevo: Brevo code, DKIM, DMARC](https://help.brevo.com/hc/en-us/articles/12163873383186-Authenticate-your-domain-with-Brevo-Brevo-code-DKIM-DMARC), checked 2026-08-10.* For a dedicated IP, stop at Brevo's account-specific setup instructions. Dedicated-IP routing can require a different DNS configuration, including SPF details supplied for that sending path. Do not assume that a shared-IP domain-authentication record set applies to dedicated IP mail. ## How do I configure SPF and DKIM for Brevo? ### 1. Open the Brevo domain settings In Brevo, open **Settings > Senders, Domains, IPs > Domains**. Select the domain already listed, or choose the option to add a domain. Enter the domain shown after `@` in the From address used by the Brevo campaign or transactional sender. Check the spelling and domain suffix before continuing. Authentication records for `mail.yourdomain.com` do not automatically apply to `yourdomain.com`. ### 2. Select the sending domain and authentication method Choose automatic authentication if Brevo can connect to the DNS provider account that is authorized to make the change. Review the records before approving the change, especially if the domain already has a DMARC policy. Choose manual authentication if you need to review the DNS change outside Brevo. Keep the Brevo page open so you can compare the host and value against the DNS record before saving. Brevo's manual flow can show a Brevo code record, DKIM records, and a DMARC record. Its documentation states that the DKIM configuration may appear as one TXT record or two CNAME records. The record format depends on the selected account and domain. ### 3. Publish the Brevo-generated DNS records Add the exact records shown by Brevo to the authoritative DNS zone. The following shapes are illustrative only. They are not Brevo configuration values and cannot authenticate mail. **Brevo code record:** `TXT` **Host:** Copy the host Brevo displays. **Value:** Copy the unique verification value Brevo displays. **DKIM record:** `TXT` or `CNAME`, as shown by Brevo. **Host:** Copy the generated selector host. **Value or target:** Copy the complete Brevo-generated value or target. ```text Illustrative only Brevo code Type: TXT Host: <host-shown-by-brevo> Value: <account-generated-verification-value> DKIM Type: CNAME or TXT Host: <selector>._domainkey.yourdomain.com Value: <account-generated-target-or-public-key> ``` > Do not publish this example. Generate and copy the real host, selector, target, and verification value from the Brevo account that sends your mail. Some DNS providers append `yourdomain.com` to the host field automatically. If Brevo displays a fully qualified host and the DNS provider also appends the zone, entering the complete host can create a duplicated name such as `selector._domainkey.yourdomain.com.yourdomain.com`. Check the final owner name in the DNS provider before saving. Do not overwrite an active DKIM selector without confirming its owner and rotation plan. [RFC 6376's DKIM key-record format](https://www.rfc-editor.org/rfc/rfc6376.html#section-3.6.1) uses a selector-specific DNS name, so the selector identifies which public key a receiver retrieves. ![Brevo domain authentication record area showing a DKIM record](/images/editorial/how-do-i-set-up-spf-and-dkim-for-brevo/brevo-dkim-record.jpg "1774x492") *Source: [Authenticate your domain with Brevo: Brevo code, DKIM, DMARC](https://help.brevo.com/hc/en-us/articles/12163873383186-Authenticate-your-domain-with-Brevo-Brevo-code-DKIM-DMARC), checked 2026-08-10.* ### 4. Handle SPF only when Brevo supplies an SPF requirement Brevo's standard domain-authentication flow should be followed as displayed in the account. Do not add `include:spf.brevo.com`, a legacy Sendinblue include, or another SPF mechanism based only on an example from a different account or setup. If Brevo's dedicated-IP setup gives you an SPF mechanism, inspect the existing SPF TXT record first. SPF evaluation uses one policy record for the domain. [RFC 7208](https://datatracker.ietf.org/doc/html/rfc7208#section-3.2) specifies that multiple SPF records cause a PermError. Merge only the mechanisms required by the actual senders into the existing SPF policy. Preserve its terminal qualifier unless the approved change specifically requires it. ```text Illustrative SPF structure only v=spf1 include:<existing-authorized-sender> include:<brevo-value-from-account> ~all ``` Do not publish the example as written. Use the exact mechanism Brevo provides, retain only valid mechanisms for your sending sources, and have the proposed merged record reviewed before replacing production DNS. ### 5. Verify in Brevo and send a real test message Return to the selected domain in Brevo and use its verification or authentication action after public DNS answers with the records you published. Record the domain, change time, DNS approver, and the Brevo status shown for the change record. Then send a new message through the exact Brevo sending path. Use a test mailbox where you can inspect the raw source. A vendor status can show that Brevo accepted DNS, but it cannot prove what a receiving mailbox evaluated for a delivered message. ## How does this setup affect DMARC? DKIM supports DMARC when the `d=` domain in the message's DKIM signature [aligns with the visible From domain](/learning/glossary/dmarc-adkim-aspf). [RFC 9989's DMARC alignment rules](https://datatracker.ietf.org/doc/html/rfc9989#section-3.1) explain that a DKIM pass for an unrelated domain does not satisfy DKIM alignment. SPF can also satisfy DMARC, but only when the authenticated SPF domain aligns with the visible From domain. Do not infer alignment from the presence of an SPF record alone. The delivered message is the evidence for the actual path. After publishing or changing DNS, use the [DMARC checker](/tools/dmarc) to inspect the public DMARC policy. A public check cannot prove Brevo's production return path, a receiver's private decision, or future inbox placement. For broader context, see Palisade's [email authentication learning center](/learning). ![Example DNS record relationships for Brevo domain authentication](/images/editorial/how-do-i-set-up-spf-and-dkim-for-brevo/how-do-i-set-up-spf-and-dkim-for-brevo-records.webp "1200x533") *Source: Palisade.* ## How do I validate the setup? ### Check public DNS [Look up the exact owner names](/tools/dns-lookup) Brevo generated with the authoritative DNS provider and at least one public resolver. Confirm that the record type, owner, and complete value or CNAME target match Brevo's current account screen. For an SPF record, use the [SPF checker](/tools/spf) as a public lookup after the DNS change. It can inspect the published SPF policy, but it cannot prove that Brevo sent a message through the intended return path. ### Check the Brevo status Return to the selected domain in Brevo and confirm the domain's current authentication status. Capture the status and time in the change record. This validates Brevo's view of the configuration at that moment. It does not prove that every sender using the domain has the same authentication result. ### Inspect a delivered message Open raw source for a newly delivered Brevo message. Check the `DKIM-Signature` field for the expected `d=` domain and selector, then review the receiver-added `Authentication-Results` field. [RFC 8601](https://www.rfc-editor.org/rfc/rfc8601.html) defines `Authentication-Results` and explains that a result is meaningful only in the context of the receiver that added it. Confirm `dkim=pass`, then compare the signing domain with the visible From domain for DMARC alignment. ### Review DMARC reports After aggregate reports have accumulated, review the Brevo sending source separately from other sources that use the same domain. Look for DKIM and SPF alignment results, unexpected source domains, and failures that occur only on a particular path. ## Troubleshooting ### Brevo cannot verify the domain Compare the exact DNS owner and value in Brevo with the authoritative DNS answer. Check for a duplicated zone suffix, a truncated TXT value, or a CNAME entered as TXT. Do not create replacement records until you know which record differs. Repeated edits can extend propagation time and obscure the original change. ### The DKIM record exists but the message does not pass DKIM Confirm that the tested message was sent after Brevo showed the domain as authenticated. Then compare its `d=` and `s=` values with the published record for that selector. If the message used another selector or signing domain, the DNS record you added may belong to a different sending path. Keep the raw headers, redact recipient data, and compare the path with the selected Brevo domain. ### SPF is failing after a DNS change Check whether two SPF TXT policies now exist at the same domain. If so, restore the single approved policy and merge only the authorized mechanisms. Do not remove existing mail-system mechanisms just to add Brevo. Removing an existing provider can break SPF for mail that does not pass through Brevo. ### DKIM passes but DMARC fails Compare the DKIM `d=` value and the SPF authenticated domain with the visible From domain. A valid signature without DMARC alignment does not produce a DKIM-aligned DMARC pass. ### Brevo shows authenticated but recipients still see failures Treat the vendor indicator and the delivered-message result as separate checks. Inspect a new message sent through the same production campaign, sender identity, and route. If the result differs, use the receiver's headers and the relevant Brevo configuration as evidence rather than relying on a public DNS lookup alone. ## Check the DMARC policy after authenticating Brevo Once Brevo accepts the domain and a real Brevo message has passed DKIM, inspect the published DMARC record before changing enforcement. The remaining gap is visibility into other production senders that use the same From domain. A Brevo-specific repair does not inventory those sources or show whether they align. [Check the DMARC record](/tools/dmarc). A public DMARC record check cannot repair Brevo configuration, monitor all sending sources over time, or guarantee delivery. Palisade is agentic DMARC software that analyzes DMARC aggregate-report data, identifies authentication and alignment issues, and proposes prioritized remediation work. A human reviews the evidence and applies any DNS or policy change. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=vendor_setup&utm_content=how-do-i-set-up-spf-and-dkim-for-brevo). For a provider-specific implementation of these authentication checks, see [How do I set up SPF and DKIM for Amazon SES?](/learning/how-do-i-set-up-spf-and-dkim-for-amazon-ses). ## Sources and further reading - [Brevo: Authenticate your domain with Brevo: Brevo code, DKIM, DMARC](https://help.brevo.com/hc/en-us/articles/12163873383186-Authenticate-your-domain-with-Brevo-Brevo-code-DKIM-DMARC) - [RFC 6376: DomainKeys Identified Mail](https://www.rfc-editor.org/rfc/rfc6376.html) - [RFC 7208: Sender Policy Framework](https://datatracker.ietf.org/doc/html/rfc7208) - [RFC 9989: Domain-based Message Authentication, Reporting, and Conformance](https://datatracker.ietf.org/doc/html/rfc9989) - [RFC 8601: Message Header Field for Indicating Message Authentication Status](https://www.rfc-editor.org/rfc/rfc8601.html) ## Frequently asked questions ### Do I need to add an SPF record for standard Brevo domain authentication? No. Follow the records shown in the selected Brevo account. Add or merge SPF only when Brevo's applicable configuration, such as a dedicated-IP setup, explicitly provides an SPF requirement. ### Can I create a second SPF TXT record for Brevo? No. Multiple SPF records at one domain cause SPF PermError under RFC 7208. Merge the approved Brevo mechanism into the existing SPF policy when it is required. ### Does Brevo use a DKIM TXT record or CNAME records? Yes. Brevo can display one DKIM TXT record or two DKIM CNAME records. Use the record type, host, and value or target displayed for your selected account and sending domain. ### Does a green Brevo authentication status prove DMARC passes? No. It shows Brevo accepted the DNS configuration, but it does not prove a receiving mailbox evaluated a specific delivered message as DKIM-aligned or SPF-aligned for DMARC. ### Can I replace an existing DMARC record with the one Brevo shows? Only after reviewing the existing DMARC policy and reporting addresses. Replacing an existing record can remove monitoring or change the policy that other senders on the domain depend on. --- # How do I set up SPF and DKIM for Customer.io? Canonical: https://www.palisade.email/learning/how-do-i-set-up-spf-and-dkim-for-customer-io > Customer.io SPF and DKIM setup: add a sending domain, publish its account-generated DNS records, verify delivery, and check DMARC alignment. Set up SPF and DKIM for Customer.io built-in delivery at [Settings > Workspace Settings > Email in Customer.io](https://docs.customer.io/messaging/channels/email/deliverability/authentication/). Add the domain used in your From address, choose automatic or manual setup, then publish and verify the account-generated DNS records. Customer.io generates values for the selected workspace and domain, so copy them only from the account you are configuring. ## Quick takeaways - This workflow covers Customer.io's built-in delivery service, not custom SMTP. - Customer.io puts its built-in delivery records on an account-specific subdomain. - Automatic setup uses Entri when the DNS provider and change process support it. - Manual setup requires the exact MX, SPF, and DKIM values Customer.io displays. - A verified Customer.io domain does not prove a real production message passed authentication. - DMARC still depends on an aligned SPF or DKIM pass for the visible From domain. ## What should I check before configuring Customer.io? Confirm that the messages in scope use Customer.io's built-in delivery service. Customer.io's [sending-domain authentication documentation](https://docs.customer.io/messaging/channels/email/deliverability/authentication/) says custom SMTP senders authenticate with their SMTP provider instead. Link tracking and custom SMTP are separate configuration tasks. You need access to Customer.io Workspace Settings, permission to add a sending domain, and access to the authoritative DNS zone. Select the domain that will appear in the production From address before adding records. Customer.io also requires a From address as part of its sending-domain setup. Check the existing root-domain DNS records before making changes. Customer.io's built-in delivery records belong on an account-specific subdomain, so they should not replace the root SPF record used by other senders or your normal inbound MX records. For broader protocol context, see [what email authentication is and why it matters](/learning/what-is-email-authentication-and-why-does-it-matter). > Copy DNS values from the account and domain you are configuring. Do not publish selectors, targets, tokens, or hostnames from another account or from an online example. ## Which setup method should I use? Use automatic setup if Customer.io offers your DNS provider through Entri and you are authorized to approve the DNS changes. Review the proposed records and their owners before authorizing them. Automatic setup reduces transcription errors, but public DNS, a Customer.io verification state, and a delivered message still need separate checks. Use manual setup if another team controls DNS, the DNS provider is unavailable in the automatic flow, or your organization requires a reviewed DNS change. Customer.io displays the record set for the selected domain. Keep that page open while you enter the records. ![Customer.io sending-domain setup options showing automatic setup and manual setup choices](/images/editorial/how-do-i-set-up-spf-and-dkim-for-customer-io/customerio-domain-setup-options-redacted.png "2458x1236") *Source: [Authenticate a sending domain](https://docs.customer.io/messaging/channels/email/deliverability/authentication/), checked 2026-08-10.* Do not select a method solely because it is faster. The correct method is the one that preserves DNS ownership and review requirements while publishing the exact Customer.io values. ## How do I configure SPF and DKIM for Customer.io? ### 1. Open the sending-domain settings Open [Settings > Workspace Settings > Email](https://docs.customer.io/messaging/channels/email/deliverability/authentication/) and select **Add Sending Domain**. Enter the domain, display name, and From address used by the Customer.io messages you intend to send. Check the workspace and domain before continuing. A workspace can contain more than one sending domain, and each configuration can produce different records. ![Customer.io Sending Domains page showing the Add Sending Domain control](/images/editorial/how-do-i-set-up-spf-and-dkim-for-customer-io/customerio-email-sending-domains-redacted.png "2484x838") *Source: [Authenticate a sending domain](https://docs.customer.io/messaging/channels/email/deliverability/authentication/), checked 2026-08-10.* ### 2. Select automatic or manual setup Choose automatic setup if the Entri connection is available and approved for your DNS provider. Otherwise, choose manual setup and display the generated records. Copy each record's type, owner, value, and MX priority exactly as Customer.io shows them. The displayed values are configuration data for that Customer.io account and selected sending domain. ### 3. Publish the account-generated DNS records Customer.io documents an account-specific set of MX, SPF, and DKIM records for manual built-in-delivery setup. The following shapes are illustrative only. Get the real owners, targets, selector, and key from Customer.io. **Return-path record** - **Record type:** `MX` - **Host:** the Customer.io-generated subdomain - **Priority and value:** the exact generated values **SPF record** - **Record type:** `TXT` - **Host:** the Customer.io-generated subdomain - **Value:** the complete generated SPF policy **DKIM record** - **Record type:** `TXT` - **Host:** the Customer.io-generated DKIM owner - **Value:** the complete generated public key ```text Illustrative only MX cio.yourdomain.com <priority> <Customer.io-generated-target> TXT cio.yourdomain.com v=spf1 include:<Customer.io-generated-include> ~all TXT <selector>._domainkey.cio.yourdomain.com v=DKIM1; k=rsa; p=<Customer.io-generated-public-key> ``` > Do not publish this example. Copy the complete values from Customer.io for the exact workspace and sending domain. Do not merge its SPF value into the root-domain SPF record unless Customer.io specifically displays that root owner for your configuration. Some DNS providers append the DNS zone automatically. If the zone is `yourdomain.com`, entering `cio.yourdomain.com` in a field that appends the zone can create `cio.yourdomain.com.yourdomain.com`. Confirm the final fully qualified owner after saving. Do not overwrite a record at an existing DKIM selector. A CNAME cannot coexist with other DNS data at the same owner, and multiple unrelated DKIM keys at one selector can prevent a usable lookup. If the generated owner conflicts with an active record, stop and review the Customer.io record set and your DNS change plan. ![Customer.io sending-domain page showing a verified domain status](/images/editorial/how-do-i-set-up-spf-and-dkim-for-customer-io/customerio-domain-verified-redacted.png "2485x734") *Source: [Authenticate a sending domain](https://docs.customer.io/messaging/channels/email/deliverability/authentication/), checked 2026-08-10.* ### 4. Verify the domain in Customer.io After the DNS records answer publicly, return to the sending-domain page and select the available verification action. Customer.io documents `Verified`, `Unverified`, and `Undetermined` states and notes that verification can take up to 72 hours. Record when the DNS change was published and when Customer.io last checked it. If the status remains unverified, compare the authoritative DNS response with the complete Customer.io value before making another edit. ### 5. Send a real test message Send a new message through the same Customer.io workspace, sending domain, and From address that production uses. Deliver it to a mailbox where you can inspect the raw message source. Do not use a message sent before the domain was verified. If different campaigns, message types, or routing settings use different From domains, test each materially different path. ## How does this setup affect DMARC? Customer.io's account-specific return-path and signing identifiers can support relaxed alignment when they are organizationally aligned with the visible From domain. [RFC 9989 defines DMARC evaluation](https://www.rfc-editor.org/info/rfc9989): DMARC needs at least one passing SPF or DKIM result that aligns with the author domain. Strict `aspf=s` or `adkim=s` alignment requires an exact domain match. Do not loosen an alignment mode to clear a status warning before inspecting a delivered Customer.io message. Confirm the SPF `smtp.mailfrom` domain and the DKIM `d=` domain first. Use the [DMARC checker](/tools/dmarc) to inspect the published root-domain policy. A public record check cannot prove which Customer.io identifier was used in a delivered message or predict a receiver's future placement decision. ## How do I validate the setup? ### Check public DNS Query the exact MX, SPF, and DKIM owners generated by Customer.io through the authoritative DNS provider and at least one public resolver. Check the root-domain DMARC record separately. ```bash dig +short TXT cio.yourdomain.com dig +short TXT selector1._domainkey.cio.yourdomain.com dig +short TXT _dmarc.yourdomain.com ``` Use Palisade's [SPF checker](/tools/spf) and [DKIM checker](/tools/dkim) for public DNS inspection. These checks do not prove Customer.io is using the expected return path or selector on a real message. ### Check the Customer.io status Confirm that Customer.io reports the selected sending domain as verified. This shows Customer.io accepted the current DNS configuration for that domain. It does not establish that all production message paths are authenticated. ### Inspect a delivered message Open the raw source of the new test message. Inspect `DKIM-Signature` for the expected `d=` domain and selector, then examine the receiver-added `Authentication-Results` field. [RFC 8601 defines Authentication-Results and its trust boundary](https://www.rfc-editor.org/rfc/rfc8601.html). Accept the setup only when the trusted receiver result shows the expected passing result and either SPF or DKIM aligns with the visible From domain for DMARC. Keep a redacted header copy with the DNS change record. ### Review DMARC reports After aggregate reports arrive, review Customer.io traffic separately from other sending sources. Look for SPF and DKIM pass rates, alignment outcomes, and any unexpected identifiers that use the same visible domain. A single Customer.io repair does not inventory every sender that uses the domain. For another vendor setup pattern, compare this workflow with setting up SPF and DKIM for Amazon SES. ## Troubleshooting ### Customer.io cannot verify the domain Compare each public DNS answer with the exact record Customer.io generated. Check the record type, MX priority, owner, target, SPF value, DKIM public key, and selected workspace domain. Customer.io documents that verification may take up to 72 hours. ### The DNS owner name contains the domain twice Check whether the DNS provider appends the zone name. Enter the relative label when the interface expects one, or the full owner only when the interface explicitly requires it. Query the final fully qualified name before requesting verification again. ### The SPF record is at the root domain Move only the Customer.io-generated SPF record to the account-specific owner Customer.io displayed. Do not create a second root SPF TXT record. SPF evaluation can produce a permanent error when a domain publishes multiple SPF records. ### The DNS provider does not accept the DKIM owner Some providers have restrictions around underscores or present an alternate input format. Confirm whether the provider expects the relative owner label and whether it supports the required DKIM TXT owner. Do not substitute a different selector or remove the underscore. ### Customer.io is verified but DMARC fails Inspect a fresh delivered message. Compare the visible From domain with `smtp.mailfrom` and the DKIM `d=` value. The Customer.io status confirms its DNS check, while DMARC depends on aligned results seen by the receiving system. ### A test message passes but another campaign fails Compare the workspace, sending domain, From address, and message route for both messages. Different Customer.io configurations can use different identifiers. Test the failing path rather than treating one header as evidence for every campaign. ## Check the domain posture after Customer.io verification After the Customer.io domain is verified, run the [Email Security Score](/tools/email-security-score) for the visible sending domain to inspect its public authentication posture. Compare the result with the delivered Customer.io headers and the root-domain DMARC policy. A public score cannot prove Customer.io used the configured records, monitor future DNS drift, or explain a receiver's private delivery decision. If Customer.io is one of several senders using the domain, [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=vendor_setup&utm_content=how-do-i-set-up-spf-and-dkim-for-customer-io) to have the DMARC Agent analyze aggregate-report data, identify sources and alignment issues, and create prioritized remediation tickets. Palisade does not change Customer.io settings, guarantee delivery, or autonomously apply a DMARC policy change. ## Sources and further reading - [Customer.io: Authenticate a sending domain](https://docs.customer.io/messaging/channels/email/deliverability/authentication/) - [RFC 9989: Domain-based Message Authentication, Reporting, and Conformance](https://www.rfc-editor.org/info/rfc9989) - [RFC 8601: Message Header Field for Indicating Message Authentication Status](https://www.rfc-editor.org/rfc/rfc8601.html) - [Palisade DMARC checker](/tools/dmarc) ## Frequently asked questions ### Do I need Customer.io SPF and DKIM if I use custom SMTP? No. Customer.io's sending-domain authentication workflow applies to its built-in delivery service. Authenticate the sending domain with the custom SMTP provider instead, then validate the delivered message from that provider's production path. ### Should I add Customer.io to my root-domain SPF record? No. Customer.io documents its built-in delivery SPF record on an account-specific subdomain. Add the generated record at the owner Customer.io displays and preserve the existing root SPF record unless the generated configuration explicitly says otherwise. ### Do I need both SPF and DKIM for Customer.io? Yes. Publish the complete Customer.io-generated record set and validate both mechanisms. DMARC can pass through one aligned mechanism, but a full setup should not assume one passing result makes the other configuration unnecessary. ### Can I authenticate more than one Customer.io sending domain? Yes. Add and authenticate each sending domain in the Customer.io workspace. Treat each domain as a separate DNS and message-validation task because the generated records and production From addresses can differ. ### Does a verified Customer.io domain guarantee DMARC passes? No. Customer.io verification confirms its DNS check for the selected domain. DMARC pass depends on a real receiving system seeing an aligned SPF or DKIM pass for the visible From domain. --- # How do I set up SPF and DKIM for Klaviyo? Canonical: https://www.palisade.email/learning/how-do-i-set-up-spf-and-dkim-for-klaviyo > How to set up SPF and DKIM for Klaviyo: configure a branded sending domain, publish Klaviyo's DNS records, verify it, and validate DMARC alignment. Set up SPF and DKIM for Klaviyo by enabling a branded sending domain in Klaviyo's account settings, selecting the sending subdomain and routing method, then publishing the exact DNS records Klaviyo generates. Return to Klaviyo to verify the records and send a new campaign for header-level validation. The documented path is through Klaviyo's account domain settings, and the DNS values are specific to the selected account and domain. ## Quick takeaways - Klaviyo's branded sending-domain workflow supplies the DNS records needed for its sending configuration. - Copy each DNS host and value from the Klaviyo account that will send the campaigns. - Choose the routing option Klaviyo offers for the selected domain and DNS provider. - Do not create a second SPF record for Klaviyo unless Klaviyo specifically instructs you to do so in its generated records. - A verified Klaviyo domain does not prove a delivered campaign has SPF, DKIM, and DMARC results you expect. - DMARC needs alignment with the visible From domain, not only a passing authentication result. ## What should I check before configuring Klaviyo? First, confirm the mail path in scope. This workflow covers marketing messages sent through Klaviyo. It does not configure authentication for employee mail, transactional messages sent by another platform, or mail sent directly by an application. You need access to the Klaviyo account that owns the sending domain, permission to manage its domain settings, and access to the authoritative DNS zone for the domain or subdomain. Identify the From domain that campaigns use and a mailbox where you can inspect the raw source of a delivered test message. If another team manages DNS, prepare a change request that includes the exact record type, host, and value shown in Klaviyo. Do not use a screenshot, another brand's records, or an online example as the source of the final values. > Copy DNS values from the account and domain you are configuring. Do not publish selectors, targets, tokens, or hostnames from another account or from an online example. For related vendor workflows, see the [Amazon SES SPF and DKIM setup guide](/learning/how-do-i-set-up-spf-and-dkim-for-amazon-ses) and the [Customer.io SPF and DKIM setup guide](/learning/how-do-i-set-up-spf-and-dkim-for-customer-io). ## Which setup method should I use? Use the branded sending-domain routing option that Klaviyo presents for your domain and DNS provider. Klaviyo's domain settings start the branded sending-domain process and direct you to the applicable DNS setup steps in its [branded sending-domain guidance](https://help.klaviyo.com/hc/en-us/articles/360004059711). Dynamic routing delegates part of a sending subdomain to Klaviyo through the generated DNS records. Static routing uses the generated records directly in your DNS zone. The right choice depends on what your DNS provider accepts and what Klaviyo displays for the selected route. Do not choose a route based on a record count from another account. Generate the records first, then review the complete set before making the DNS change. ![Klaviyo account setting showing the control to enable a branded sending domain](/images/editorial/how-do-i-set-up-spf-and-dkim-for-klaviyo/klaviyo-enable-branded-sending-domain.jpg "800x251") *Source: [Klaviyo Help Center, "Understanding the default account, email, and list settings"](https://help.klaviyo.com/hc/en-us/articles/360004059711), checked 2026-08-10.* ## How do I configure SPF and DKIM for Klaviyo? ### 1. Open the branded sending-domain settings Open the account domain settings in Klaviyo and begin the branded sending-domain workflow described in Klaviyo's [domain settings documentation](https://help.klaviyo.com/hc/en-us/articles/360004059711). Confirm that you are in the intended account before selecting a domain. Use a subdomain dedicated to Klaviyo when that is what the account workflow requests, such as `send.yourdomain.com`. Keep a record of the selected From domain, DNS zone owner, and test mailbox. ### 2. Select the sending domain and routing method Enter or select the domain or subdomain that Klaviyo will authenticate. Choose the available routing method that suits your DNS provider. Klaviyo then generates the DNS records for that domain. Those values can include delegation, verification, or authentication-related records, depending on the route. Treat every generated value as account-specific configuration. ### 3. Publish the DNS records Klaviyo generates Add each record in the authoritative DNS zone exactly as Klaviyo displays it. The following shapes are illustrative only. They are not Klaviyo values and must not be published. **Record type:** `TXT` **Host (illustrative only):** ```text send.yourdomain.com ``` **Value (illustrative only):** ```text klaviyo-domain-verification=example-value ``` **Record type:** `CNAME` or `NS` **Host (illustrative only):** ```text selector1._domainkey.send.yourdomain.com ``` **Value (illustrative only):** ```text account-specific-target.example ``` > Do not publish these examples. Copy the complete record set generated in your Klaviyo account for the selected sending domain. Some DNS providers append the zone name automatically. If the zone is `yourdomain.com`, entering `send.yourdomain.com` in a host field can create `send.yourdomain.com.yourdomain.com`. Check the final fully qualified owner name before saving. Do not replace an existing SPF TXT record at the same owner with a second SPF policy. SPF evaluation expects one applicable SPF record. Follow Klaviyo's generated record set and resolve any conflict in the DNS zone before continuing. ![Example Klaviyo dynamic-routing DNS records and domain verification record](/images/editorial/how-do-i-set-up-spf-and-dkim-for-klaviyo/klaviyo-dynamic-routing-dns-records.jpg "860x906") *Source: [Klaviyo Help Center, "Troubleshooting branded sending domain issues"](https://help.klaviyo.com/hc/en-us/articles/4417768780827), checked 2026-08-10.* ### 4. Verify the domain in Klaviyo After DNS answers publicly, return to the branded sending-domain workflow and use Klaviyo's verification action. Klaviyo's [branded-domain troubleshooting guidance](https://help.klaviyo.com/hc/en-us/articles/4417768780827) covers DNS-record and verification issues. If verification fails, run a [DNS lookup on that hostname](/tools/dns-lookup) and compare the public DNS answer with the generated record one character at a time. Check the selected domain in Klaviyo, the DNS zone, record type, host, target, and any accidental duplicate suffix. ### 5. Send a real test campaign Send a new campaign through the exact production configuration to a mailbox where you can view raw message headers. Do not use a message sent before verification. Record the visible From domain, the return-path domain if present, the DKIM signing domain and selector, and the receiver's authentication result. That message is the evidence for the actual path, not the vendor status indicator alone. ## How does this setup affect DMARC? SPF and DKIM contribute to DMARC only when their authenticated domains [align with the visible From domain](/learning/glossary/dmarc-adkim-aspf) under the receiving system's DMARC evaluation. A Klaviyo domain can be verified while a particular campaign still needs message-level confirmation of its alignment. Use the [Palisade DMARC checker](/tools/dmarc) to inspect the public DMARC policy for the visible From domain before changing enforcement. A public record check cannot prove that a Klaviyo campaign used the expected return path, DKIM selector, or receiver evaluation. ![Example DNS record relationships for a Klaviyo branded sending domain and DMARC policy](/images/editorial/how-do-i-set-up-spf-and-dkim-for-klaviyo/how-do-i-set-up-spf-and-dkim-for-klaviyo-records.webp "1200x533") *Source: Palisade.* ## How do I validate the setup? ### Check public DNS Query the exact owners Klaviyo generated through the authoritative DNS service and at least one public resolver. Confirm that the returned record type and value match the Klaviyo account. ```bash dig +short TXT send.yourdomain.com dig +short CNAME selector1._domainkey.send.yourdomain.com ``` Replace these illustrative names with the actual owners Klaviyo generated. Public DNS confirms what is published. It does not prove that a campaign uses those records. ### Check the Klaviyo status Return to the selected branded sending domain in Klaviyo and confirm that its verification status is successful. This shows that Klaviyo accepted the current DNS configuration for that domain. A green vendor indicator is not a delivered-message check. It does not establish that every campaign path has the same authentication outcome. ### Inspect a delivered message Open the raw source of the new test campaign. Look for a `DKIM-Signature` header and the receiver's `Authentication-Results` header. Confirm that the receiver reports the expected SPF and DKIM outcome, then compare the authenticated domains with the visible From domain for DMARC alignment. Save a redacted header copy with the DNS change record. Remove recipient addresses, message content, tracking URLs, and identifiers before sharing it. ### Review DMARC reports After DMARC aggregate reports arrive, review whether Klaviyo traffic passes and aligns for the intended From domain. Keep Klaviyo separate from other sources that send with the same organizational domain. It analyzes DMARC aggregate-report data, identifies sending sources and alignment issues, and creates prioritized remediation tickets. It can propose a next policy step when evidence supports it, while a human reviews the evidence and applies the DNS change. ## Troubleshooting ### Klaviyo cannot verify the records Compare the public answer with the exact generated record set. A missing character, wrong record type, or duplicated DNS suffix can prevent verification. Klaviyo's [troubleshooting instructions](https://help.klaviyo.com/hc/en-us/articles/4417768780827) are the provider-specific reference for this state. ### The DNS provider rejects a generated record Check whether the DNS provider supports the route and record type Klaviyo generated. Do not substitute a different target or convert record types. Return to Klaviyo and select a supported route if the provider cannot host the required records. ### SPF passes but DMARC fails Inspect the receiver's message headers and compare the SPF authenticated domain with the visible From domain. A pass alone does not establish DMARC alignment. Check DKIM alignment as well before changing the DMARC policy. ### DKIM is absent or fails in a delivered campaign Confirm that the campaign was sent after domain verification and that it used the expected From domain. Compare the `d=` and `s=` values in the message with the current DNS records. If the test uses a different sending path than production, retest through the production path. ### The record looks correct but the domain still fails verification Check the authoritative DNS response, not only the DNS provider's editor. DNS changes may take time to appear to public resolvers. Avoid repeatedly replacing a record that already matches the Klaviyo-generated value. ## Check the DMARC policy after Klaviyo verification Once Klaviyo verifies the domain and you have a delivered test message, inspect the visible From domain's DMARC record. That check follows from the evidence you just collected because it shows the public policy that receives Klaviyo's aligned authentication results. [Check the DMARC record](/tools/dmarc) A DMARC record check cannot prove that Klaviyo signed a specific message, repair an incorrect DNS record, monitor later sender changes, or guarantee inbox placement. For an ongoing inventory of sending sources and DMARC alignment across domains, [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=vendor_setup&utm_content=how-do-i-set-up-spf-and-dkim-for-klaviyo). Palisade analyzes DMARC reports and proposes prioritized remediation work, but a human reviews the evidence and applies policy changes. ## Sources and further reading - [Klaviyo: Understanding the default account, email, and list settings](https://help.klaviyo.com/hc/en-us/articles/360004059711) - [Klaviyo: Troubleshooting branded sending domain issues](https://help.klaviyo.com/hc/en-us/articles/4417768780827) - [How to set up SPF and DKIM for Brevo](/learning/how-do-i-set-up-spf-and-dkim-for-brevo) - [Palisade learning center](/learning) - [RFC 9989: Domain-based Message Authentication, Reporting, and Conformance](https://www.rfc-editor.org/rfc/rfc9989.html) ## Frequently asked questions ### Does Klaviyo give me the SPF and DKIM values to publish? Yes. Start the branded sending-domain workflow in the Klaviyo account that sends the campaigns, then copy its generated DNS records exactly. Do not reuse values from another Klaviyo account or example. ### Do I need to add Klaviyo to my existing SPF record? Only if Klaviyo's generated instructions for your selected setup explicitly require it. Do not publish a separate second SPF TXT record at the same DNS owner because that can make SPF evaluation fail. ### Can a verified Klaviyo domain still fail DMARC? Yes. Klaviyo verification confirms its domain configuration, but DMARC also requires an aligned SPF or DKIM result for the visible From domain. Inspect a newly delivered campaign's headers to confirm the actual result. ### Should I use a root domain or a subdomain for Klaviyo? Yes. Use the domain or subdomain requested in Klaviyo's branded sending-domain workflow and approved by the team that owns your DNS and sender architecture. A dedicated sending subdomain can keep the Klaviyo configuration distinct from other mail paths. ### Does a public DNS lookup prove that Klaviyo is signing my campaigns? No. A public lookup shows the records that resolve in DNS. Send a new campaign and inspect its raw headers to confirm the DKIM signature, SPF result, and DMARC alignment for the production path. --- # How do I set up SPF and DKIM for Mailchimp? Canonical: https://www.palisade.email/learning/how-do-i-set-up-spf-and-dkim-for-mailchimp > Mailchimp SPF and DKIM setup: authenticate a sending domain with Entri or two CNAME records, preserve SPF, add DMARC, and validate a campaign. Set up Mailchimp domain authentication from **Account & billing > Domains**: verify the sending domain, select **Start authentication**, then use Entri or publish the records Mailchimp displays for that domain. Mailchimp's current manual workflow uses two account-specific CNAME records and a DMARC TXT record. It does not document a separate Mailchimp SPF record at the root domain, so preserve an existing SPF policy unless your account presents a specific change. ## Quick takeaways - Mailchimp domain verification proves access to an address, while authentication configures DNS for the sending domain. - Mailchimp recommends Entri when it supports your DNS provider and you can authorize the change. - Manual authentication requires two account-specific CNAME records and a DMARC TXT record. - Do not add a second SPF TXT record at the root domain because multiple SPF records can cause SPF evaluation problems. - A Mailchimp **Authenticated** status does not prove that a delivered campaign passed DKIM or DMARC. - Validate DNS, Mailchimp status, a newly delivered campaign, and DMARC reports as separate checks. ## What should I check before configuring Mailchimp? This workflow covers a domain your organization owns and uses in Mailchimp campaign From addresses. Confirm that the domain has already completed Mailchimp verification and that you can edit its authoritative DNS zone. Mailchimp distinguishes domain verification from domain authentication in its [email domain authentication instructions](https://mailchimp.com/help/set-up-email-domain-authentication/). Check which system sends the messages in scope. This guide covers Mailchimp campaign mail. It does not confirm authentication for transactional mail, employee mail, a CRM, or another platform that uses the same visible From domain. Record the selected Mailchimp account, sending domain, DNS zone, DNS approver, and mailbox for the production test. Review existing root-domain SPF and `_dmarc` TXT records before making changes. Mailchimp's documented manual method does not provide a root SPF record. An SPF policy is a single TXT record at its owner, so do not create another one to satisfy a generic SPF setup request. > Copy DNS values from the account and domain you are configuring. Do not publish selectors, targets, tokens, or hostnames from another account or from an online example. For background on how these controls work together, see [what email authentication means for senders](/learning/what-is-email-authentication-and-why-does-it-matter). ## Which setup method should I use? Use Entri if Mailchimp offers it for your DNS provider and you are permitted to authorize the connection. Mailchimp describes Entri as its recommended method. Review the selected domain and proposed records before you approve the DNS connection. Use manual authentication when Entri is unavailable, when your DNS provider is not supported, or when DNS changes must go through a separate change-control process. Keep the Mailchimp instructions open while editing DNS. The CNAME names and targets are generated for the selected account and domain. The Mailchimp manual screen below shows the two CNAME rows that the account provides. These values are examples from the documented interface, not reusable records. ![Mailchimp manual authentication screen showing two account-specific CNAME record rows](/images/editorial/how-do-i-set-up-spf-and-dkim-for-mailchimp/mailchimp-manual-cname-records.png "607x246") *Source: [Mailchimp Set Up Email Domain Authentication](https://mailchimp.com/help/set-up-email-domain-authentication/), checked 2026-07-20.* ## How do I configure SPF and DKIM for Mailchimp? ### 1. Open the sending-domain settings In Mailchimp, open **Account & billing**, select **Domains**, find the verified sending domain, and select **Start authentication**. This path is documented by Mailchimp, rather than inferred from an older interface. Verify the selected domain before proceeding. An account can contain more than one verified domain, and the authentication records belong to the domain you selected. ### 2. Choose Entri or manual authentication Select Entri when Mailchimp offers the option and your organization authorizes it. Sign in to the DNS provider only through the provider connection shown by Mailchimp, then review the domain and records before confirming. For a manual change, select **Or manually authenticate your domain**, choose the DNS provider if Mailchimp asks, and copy the record instructions for the selected domain. Do not replace an existing authentication record merely because an online example uses a similar host name. ### 3. Publish the two Mailchimp CNAME records Mailchimp's [manual authentication instructions](https://mailchimp.com/help/set-up-email-domain-authentication/) provide two CNAME Name and Value pairs. Publish both pairs exactly as shown in the account. **First record** - Record type: `CNAME` - Host: the first Mailchimp-generated Name or Host - Value: the matching Mailchimp-generated Value or Points To target **Second record** - Record type: `CNAME` - Host: the second Mailchimp-generated Name or Host - Value: the matching Mailchimp-generated Value or Points To target The record shape below is illustrative only. Generate the actual names and targets in the Mailchimp account for the domain being authenticated. ```text CNAME host: k1._domainkey.yourdomain.com value: k1.domainkey.example-mailchimp-target.net ``` > Do not publish this example. Copy both complete CNAME records from Mailchimp. They are account-specific and a target from another account will not authenticate your domain. Watch for the DNS-provider suffix trap. Some DNS interfaces append `yourdomain.com` after the value entered in the Host field. If you paste a full owner name into a field that expects only the relative label, the published owner can contain the domain twice. Check the final fully qualified name after saving. ### 4. Review the DMARC TXT record without creating duplicates Mailchimp's manual workflow also presents a DMARC TXT record step. The screen below shows the DMARC record area in that workflow. ![Mailchimp manual authentication screen showing the DMARC TXT record step](/images/editorial/how-do-i-set-up-spf-and-dkim-for-mailchimp/mailchimp-manual-dmarc-txt.png "321x265") *Source: [Mailchimp Set Up Email Domain Authentication](https://mailchimp.com/help/set-up-email-domain-authentication/), checked 2026-07-20.* Check whether `_dmarc.yourdomain.com` already has a valid TXT record. DNS should publish one DMARC policy at that owner. Do not create a second record or overwrite reporting addresses, alignment settings, subdomain policy, or enforcement settings without approval from the domain owner. A structural DMARC example looks like this: ```text TXT host: _dmarc.yourdomain.com value: v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com ``` > Do not publish this example as your production policy. Use the record Mailchimp displays only after comparing it with the existing domain policy and its approved reporting destination. ### 5. Confirm authentication and send a new campaign Return to **Account & billing > Domains** after public DNS answers for the records. Mailchimp can show **Authentication in progress** while it validates, then **Authenticated** after its checks pass. Mailchimp documents that authentication can take up to 48 hours. After the domain shows **Authenticated**, send a new campaign from the exact production account and From address to a mailbox where you can inspect raw source. Do not use a message sent before the DNS change or a test from another sending platform. ![DNS record shapes for a Mailchimp authenticated sending domain](/images/editorial/how-do-i-set-up-spf-and-dkim-for-mailchimp/mailchimp-authentication-records.webp "1200x533") *Source: Palisade.* ## How does this setup affect DMARC? DMARC evaluates whether SPF or DKIM passes with an identifier aligned to the visible From domain. [RFC 9989 defines DMARC alignment and evaluation](https://www.rfc-editor.org/info/rfc9989). For a Mailchimp campaign, the delivered message determines whether the Mailchimp DKIM signature passed and whether its `d=` domain aligned with the visible From domain. Do not infer a Mailchimp root SPF change from this article's title. Follow the record set displayed by the current Mailchimp account. If another service sends mail as the same domain, its SPF and DKIM configuration requires its own review. The related [Amazon SES SPF and DKIM setup guide](/learning/how-do-i-set-up-spf-and-dkim-for-amazon-ses) illustrates why vendor record sets differ. Use the [DMARC checker](/tools/dmarc) to inspect the published DMARC record before any approved policy change. A public lookup does not show which Mailchimp campaign path signed a message, a receiver's private decision, or future inbox placement. ## How do I validate the setup? ### Check public DNS Query the exact two CNAME owners Mailchimp generated and the DMARC owner. Compare the returned CNAME targets with the current Mailchimp instructions. A [DKIM record check](/tools/dkim) can help inspect public selector evidence, but it does not prove that Mailchimp used the selector for a campaign. ```bash dig +short CNAME <first-mailchimp-owner> dig +short CNAME <second-mailchimp-owner> dig +short TXT _dmarc.<sending-domain> ``` Check the authoritative DNS answer and at least one public resolver. If either CNAME owner has the domain appended twice, correct the DNS host field before restarting authentication. ### Check the Mailchimp status Return to **Account & billing > Domains** and confirm that the selected domain shows **Authenticated**. This confirms that Mailchimp accepted the DNS configuration it checked. A green status is not a delivered-message check and does not show whether every path using the domain authenticates. ### Inspect a delivered message Open raw source for the new campaign in the receiving mailbox. Look for `DKIM-Signature` and compare its `d=` and `s=` values with the expected Mailchimp path. Then inspect the receiver-added `Authentication-Results` field. [RFC 8601 defines Authentication-Results and its trust boundary](https://www.rfc-editor.org/rfc/rfc8601.html). Accept the change only when the trusted receiver result reports `dkim=pass` and the passing DKIM domain aligns with the visible From domain when DKIM is expected to satisfy DMARC. Keep a redacted copy of the headers with the DNS change record. ### Review DMARC reports After aggregate reports accumulate, confirm that Mailchimp appears as an expected source and that its traffic passes aligned SPF or DKIM. Review every other source using the same domain separately. A correct Mailchimp configuration does not inventory the other platforms that can send as the domain. ## Troubleshooting ### Mailchimp still shows Authentication in progress Wait for the public DNS records to answer, then allow the validation window Mailchimp documents. Compare each public CNAME target against the full account-generated value. Do not repeatedly replace records while DNS propagation or Mailchimp validation is still pending. ### Mailchimp asks me to resolve or restart authentication Check the selected domain, both CNAME owners, both targets, and the DMARC owner. A wrong owner name, truncated target, or duplicate domain suffix can prevent validation. Correct the published DNS record first, then use Mailchimp's documented restart option if it remains necessary. ### The CNAME owner contains the domain twice Your DNS provider likely appended the zone name to a full domain entered in a relative Host field. Delete or correct only the malformed owner after confirming the intended record. Enter the label format required by your DNS provider, then verify the final public owner name. ### The domain is verified but not authenticated Verification and authentication are separate Mailchimp states. Return to **Domains**, select the verified domain, and begin the authentication workflow. Verification alone does not publish the CNAME records or establish a DKIM signing result. ### DKIM passes but DMARC fails Compare the visible From domain with the DKIM `d=` domain in the delivered campaign's headers. A valid DKIM signature can still fail DMARC if it does not align. Also inspect other sources sending as the domain, because their traffic may account for the DMARC failure. ## Check the wider authentication posture after Mailchimp is verified After Mailchimp shows **Authenticated** and a delivered campaign has passed the message check, run the domain through the [Email Security Score](/tools/email-security-score) to inspect the public authentication posture around that sending domain. This follows the Mailchimp setup because other platforms can still send as the same domain and create alignment issues. [Check the email security score](/tools/email-security-score) A public score does not prove that Mailchimp signed a production campaign, repair another sender, monitor later DNS drift, or guarantee delivery. For ongoing DMARC aggregate-report analysis across Mailchimp and other sources, Palisade is agentic DMARC software that identifies sending sources and prioritizes authentication and alignment issues. A human reviews the evidence and applies policy changes. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=vendor_setup&utm_content=how-do-i-set-up-spf-and-dkim-for-mailchimp). ## Sources and further reading - [Mailchimp email domain authentication instructions](https://mailchimp.com/help/set-up-email-domain-authentication/) - [Mailchimp explanation of email domain authentication](https://mailchimp.com/help/set-up-email-domain-authentication/) - [RFC 9989, Domain-based Message Authentication, Reporting, and Conformance](https://www.rfc-editor.org/info/rfc9989) - [RFC 8601, Message Header Field for Indicating Message Authentication Status](https://www.rfc-editor.org/rfc/rfc8601.html) For a provider-specific implementation of these authentication checks, see [Why does Mailchimp DMARC alignment not require adding Mailchimp to SPF?](/learning/why-does-mailchimp-dmarc-alignment-not-require-adding-mailchimp-to-spf). ## Frequently asked questions ### Do I need to add an SPF record for Mailchimp? No. Mailchimp's current manual domain authentication workflow documents two account-specific CNAME records and a DMARC TXT record. It does not instruct you to add a separate Mailchimp SPF policy at the root domain. Preserve the existing SPF record unless the current Mailchimp account provides a specific DNS change. ### Is Mailchimp domain verification the same as authentication? No. Domain verification confirms that you can access an email address at the domain. Authentication is the separate DNS workflow that uses Entri or Mailchimp's manual record instructions. ### Should I use Entri or manual authentication in Mailchimp? Only use Entri when Mailchimp offers it for your DNS provider and you can approve the connection. Use manual authentication when Entri is unavailable or your organization requires a DNS administrator to publish records through its normal change process. ### Can I authenticate more than one Mailchimp sending domain? Yes. Authenticate each verified sending domain from its own Mailchimp Domains entry. Treat each domain as a separate DNS change because its account-generated CNAME values and existing DMARC policy can differ. ### How long does Mailchimp authentication take? Mailchimp documents that domain authentication can take up to 48 hours. Check that the records answer publicly and match the account-provided values before restarting the workflow. ### Does an Authenticated status prove my campaigns pass DMARC? No. The status shows that Mailchimp accepted the DNS configuration it checked. Send a new campaign, inspect the receiver-added Authentication-Results header, and review DMARC aggregate reports after data accumulates. --- # How do I set up SPF and DKIM for Zoho Campaigns? Canonical: https://www.palisade.email/learning/how-do-i-set-up-spf-and-dkim-for-zoho-campaigns > Set up SPF and DKIM for Zoho Campaigns by verifying the sender, publishing Zoho's DNS values, testing a delivered campaign, and checking DMARC. Set up SPF and DKIM for Zoho Campaigns through its domain-authentication workflow: verify the sender, copy the SPF and DKIM DNS values displayed for that domain, publish them in authoritative DNS, then complete Zoho's domain verification and send a new campaign test. The path and workflow are verified from [Zoho Campaigns' domain-authentication documentation](https://help.zoho.com/portal/en/kb/campaigns/user-guide/settings/domain-authentication/articles/authenticate-my-domain). Values shown in your account are specific to that account and domain. ## Quick takeaways - Zoho Campaigns requires sender verification and domain authentication before you can confirm SPF and DKIM for the sending domain. - Copy the SPF and DKIM values from the Zoho Campaigns account that will send the campaign. - Add Zoho to an existing SPF policy instead of publishing a second SPF TXT policy. - A successful Zoho verification does not prove that a delivered campaign passed SPF, DKIM, or DMARC. - Validate public DNS, Zoho's status, a new delivered message, and DMARC aggregate reports as separate checks. - Use the [email authentication learning center](/learning) for protocol guidance that applies across sending platforms. ## What should I check before configuring Zoho Campaigns? Confirm that Zoho Campaigns is the platform sending the marketing messages in scope. This setup does not automatically authenticate employee mail sent through a mailbox provider, transactional mail sent by another application, or messages sent through a separate marketing platform. You need access to the Zoho Campaigns organization that owns the sender domain, permission to complete its sender-verification workflow, and access to the domain's authoritative DNS zone. Identify the visible From domain you will use in the campaign and the mailbox that will receive your test. If another team owns DNS, prepare a change request that includes the exact record owner and value displayed by Zoho. Check the DNS provider's host-field behavior before submitting it. Some DNS interfaces automatically append the zone name, so pasting a full domain into a relative host field can create a duplicated name. > Copy DNS values from the account and domain you are configuring. Do not publish selectors, targets, tokens, or hostnames from another account or from an online example. Also inspect the current SPF record before editing it. SPF has one selected policy per domain. [RFC 7208 says receivers must treat selection of multiple SPF records as a permanent error](https://datatracker.ietf.org/doc/html/rfc7208#section-3.2). ## Which setup method should I use? Use Zoho Campaigns' current domain-authentication workflow for the selected campaign sender domain. Its official guide covers sender verification, copying the displayed SPF and DKIM values, publishing them in DNS, and verifying the domain. If the domain already sends through other services, preserve the existing SPF policy and add Zoho's required mechanism to that one policy. Zoho's current guide instructs domains with an existing SPF policy to add `include:zcsend.net`; compare that instruction with the exact value displayed in your account before publishing. DKIM values are account-generated. Use the selector and public-key value Zoho supplies, even if another provider uses a familiar selector name. Do not reuse a selector that already has a different active DKIM record. ![Zoho Campaigns domain authentication screen showing SPF and DKIM setup controls](/images/editorial/how-do-i-set-up-spf-and-dkim-for-zoho-campaigns/zoho-spf-dkim-setup.png "1051x637") *Source: [Zoho Campaigns Help, Authenticate my domain](https://help.zoho.com/portal/en/kb/campaigns/user-guide/settings/domain-authentication/articles/authenticate-my-domain), checked 2026-07-29.* ## How do I configure SPF and DKIM for Zoho Campaigns? ### 1. Open domain authentication for the campaign sender In Zoho Campaigns, open the domain-authentication workflow documented in [Authenticate my domain](https://help.zoho.com/portal/en/kb/campaigns/user-guide/settings/domain-authentication/articles/authenticate-my-domain). Select the sender domain used in the visible From address for the campaign. Confirm the domain carefully before copying DNS values. A parent domain and a sending subdomain can have separate records and different alignment outcomes. ### 2. Complete sender verification Complete Zoho's sender-verification step for the From address or domain selected in the workflow. This confirms control of the sender identity within Zoho Campaigns. It does not publish SPF or DKIM records, and it does not establish a delivered-message result. Keep the verification mailbox available until the domain-authentication process is complete. If the selected sender address differs from the From address used in production campaigns, resolve that difference before proceeding. ### 3. Publish the SPF record change Copy the SPF instruction from Zoho Campaigns. For a domain with an existing SPF record, Zoho documents adding its include mechanism to the existing policy. **Record type:** `TXT` **Host (illustrative only):** ```text yourdomain.com ``` **Value structure (illustrative only):** ```text v=spf1 include:existing-sender.example include:zcsend.net -all ``` > Do not publish this example. Use the exact SPF instruction displayed by Zoho Campaigns and retain mechanisms required by other authorized senders. Do not create a second `v=spf1` TXT record. Merge the required Zoho mechanism into the existing SPF policy, then check its total DNS lookup behavior. If the domain has no existing SPF policy, use the record shape Zoho displays for the selected domain. ![Example SPF and DKIM record shapes for a Zoho Campaigns sending domain](/images/editorial/how-do-i-set-up-spf-and-dkim-for-zoho-campaigns/zoho-campaigns-authentication-records.webp "1200x466") *Source: Palisade.* ### 4. Publish Zoho's DKIM record Copy the DKIM record owner and full value from the same Zoho Campaigns domain-authentication view. The selector, public key, and any record target must come from the active account. **Record type:** `TXT` **Host (illustrative only):** ```text selector1._domainkey ``` **Value structure (illustrative only):** ```text v=DKIM1; k=rsa; p=public-key-generated-by-zoho-campaigns ``` > Do not publish this example. Copy the complete owner and value generated for your Zoho Campaigns account. An incomplete key cannot authenticate mail. Do not shorten the public key or add quotes that the DNS provider does not require. Check for an existing record at the same selector before saving. If that selector is already in use, stop and choose a new selector or a documented key-rotation path rather than overwriting a working record. ### 5. Verify in Zoho Campaigns and send a new test After the records answer publicly, return to Zoho Campaigns and complete domain verification. The current Zoho workflow shows SPF and DKIM verification status for the configured domain. Send a new campaign from the exact production sender to a mailbox where you can inspect the raw message source. A message sent before the verification change is not evidence for the new configuration. ![Zoho Campaigns domain authentication view showing SPF and DKIM verification status](/images/editorial/how-do-i-set-up-spf-and-dkim-for-zoho-campaigns/zoho-spf-dkim-verification.png "1552x802") *Source: [Zoho Campaigns Help, Authenticate my domain](https://help.zoho.com/portal/en/kb/campaigns/user-guide/settings/domain-authentication/articles/authenticate-my-domain), checked 2026-07-29.* ## How does this setup affect DMARC? SPF and DKIM help DMARC only when the passing authenticated identifier aligns with the visible From domain. [RFC 9989 defines DMARC evaluation through SPF or DKIM identifier alignment](https://datatracker.ietf.org/doc/html/rfc9989). A DKIM pass for an unrelated signing domain does not make the campaign DMARC-aligned. Use the [DMARC checker](/tools/dmarc) to inspect the sender domain's published DMARC record before changing its policy. A public record check cannot show which Zoho Campaigns message path was used or how a receiving mailbox evaluated a particular campaign. For a related platform workflow, see [how to set up SPF and DKIM for Amazon SES](/learning/how-do-i-set-up-spf-and-dkim-for-amazon-ses). The DNS process changes by vendor, but the delivered-message and DMARC checks remain necessary. ## How do I validate the setup? ### Check public DNS Query the exact SPF domain and DKIM selector shown by Zoho. Compare the authoritative DNS answer with at least one public resolver. ```bash dig +short TXT yourdomain.com dig +short TXT selector1._domainkey.yourdomain.com ``` Confirm that the SPF policy contains the intended Zoho mechanism and that the DKIM owner returns the complete expected value. Public DNS confirms publication only. ### Check the Zoho Campaigns status Return to the domain-authentication workflow and confirm Zoho shows the selected domain as verified. This indicates that Zoho accepted the current DNS configuration for that domain. A green status is not a delivered-message check. It does not prove that every campaign route signs with the expected domain or that a receiver reported an aligned result. ### Inspect a delivered message Open the raw source of a new campaign test. Look for the `DKIM-Signature` field and the receiving mailbox's `Authentication-Results` field. [RFC 8601 defines Authentication-Results and its receiver trust boundary](https://www.rfc-editor.org/rfc/rfc8601.html). Check for `dkim=pass`, the expected DKIM `d=` domain, and an SPF result associated with the production campaign path. Then compare the passing SPF or DKIM identifier with the visible From domain for DMARC alignment. Save a redacted header copy with the DNS change record. ### Review DMARC reports After DMARC aggregate reports accumulate, check whether Zoho Campaigns traffic appears as expected and passes alignment. Separate it from other marketing, transactional, and mailbox-hosted sources that use the same domain. ## Troubleshooting ### Zoho Campaigns cannot verify SPF Inspect the domain's complete SPF TXT record. A common cause is publishing a second SPF policy instead of adding Zoho's required mechanism to the existing one. Restore one selected policy and retain every authorized sender mechanism. ### Zoho Campaigns cannot verify DKIM Compare the DNS answer character for character with the value displayed by Zoho. Check the final fully qualified owner name for a duplicated domain suffix, a truncated public key, or an existing record at the same selector. ### Zoho shows verified, but the campaign fails DKIM Send a new campaign and inspect its raw source. Confirm that the message actually includes the expected selector and signing domain. If it does not, verify the campaign sender domain selected in Zoho and escalate with the redacted message evidence. ### SPF or DKIM passes, but DMARC fails Compare the passing SPF domain or DKIM `d=` domain with the visible From domain. The authentication result may pass without satisfying DMARC alignment. Review the sender domain's DMARC record and the exact production campaign headers. ### The DNS host includes the domain twice Check whether the DNS provider automatically appends `yourdomain.com`. Enter only the relative host when that provider expects one, then query the fully qualified owner before returning to Zoho verification. ## Check the sender domain after the Zoho Campaigns test Use the [Email Security Score](/tools/email-security-score) to inspect the sender domain's public SPF, DKIM, and DMARC posture after publishing the Zoho Campaigns records. Compare its DNS findings with the delivered campaign headers you collected. A public score cannot prove that Zoho Campaigns used the intended selector, envelope sender, or visible From domain on a campaign. It also cannot monitor future sender changes. When aggregate reports show recurring source or alignment issues across domains, Palisade analyzes that evidence and creates prioritized remediation tickets for human review. It does not configure Zoho Campaigns or guarantee inbox placement. If that ongoing reporting gap applies to your team, [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=vendor_setup&utm_content=how-do-i-set-up-spf-and-dkim-for-zoho-campaigns). ## Sources and further reading - [Zoho Campaigns: Authenticate my domain](https://help.zoho.com/portal/en/kb/campaigns/user-guide/settings/domain-authentication/articles/authenticate-my-domain) - [Zoho Campaigns: Domain authentication techniques](https://help.zoho.com/portal/en/kb/campaigns/deliverability-guide/domain-authentication/domain-authentication-techniques) - [RFC 7208: Sender Policy Framework](https://datatracker.ietf.org/doc/html/rfc7208) - [RFC 9989: DMARC](https://datatracker.ietf.org/doc/html/rfc9989) - [RFC 8601: Authentication-Results](https://www.rfc-editor.org/rfc/rfc8601.html) ## Frequently asked questions ### Does Zoho Campaigns need its own SPF record? No. A domain should not publish a separate SPF policy for Zoho Campaigns when it already has one. Add Zoho's required mechanism to the existing SPF TXT policy, then preserve the mechanisms required by other authorized senders. ### Does Zoho Campaigns DKIM need to align with the From domain? Yes. DKIM can satisfy DMARC only when the passing DKIM signing domain aligns with the visible From domain under the domain's DMARC alignment mode. A valid signature from an unrelated domain does not satisfy DKIM alignment. ### Can I use a Zoho Campaigns DKIM value from another account? No. Copy the selector and DNS value from the Zoho Campaigns account and domain that will send the campaigns. Account-generated values from another account do not establish a valid signing path for your sender domain. ### Does a verified Zoho status prove inbox placement? No. Zoho verification shows that Zoho accepted the current DNS setup. It does not prove a receiving mailbox's spam decision, future delivery, or the result of every campaign path. Inspect a newly delivered message and then review DMARC aggregate reports. ### Should I test a campaign after publishing SPF and DKIM? Yes. Send a new campaign through the same sender and configuration used in production. Inspect the receiver-added Authentication-Results and the DKIM-Signature fields, then compare the authenticated domains with the visible From domain for DMARC alignment. --- # How do I set up SPF for Google Workspace? Canonical: https://www.palisade.email/learning/how-do-i-set-up-spf-for-google-workspace > How to set up SPF for Google Workspace: publish Google's SPF TXT record, merge other senders safely, and validate DNS and delivered mail safely. The SPF record for Gmail through Google Workspace is `v=spf1 include:_spf.google.com ~all` when Google Workspace is the domain's only approved sender. Publish it as a TXT record at the root of the sending domain. Make this change in authoritative DNS, not in the Google Admin console. If another service also sends mail using that domain, merge its approved SPF mechanism into the same record. Do not create a second SPF record. ## Quick takeaways - Google Workspace SPF is published as a DNS TXT record for the sending domain. - Google's documented SPF mechanism is `include:_spf.google.com`. - A domain needs one SPF record beginning with `v=spf1`. - Merge approved third-party senders into the existing SPF record before the final `~all` or `-all`. - Public DNS, vendor configuration, a delivered message, and DMARC reports answer different validation questions. - SPF authorizes an SMTP sending path. It does not by itself prove DMARC alignment or stop visible-From spoofing. ## What should I check before configuring Google Workspace? Confirm the exact mail stream in scope. This record covers messages sent by Google Workspace using the domain in the SMTP envelope sender, also called the return-path domain. It may not cover marketing platforms, help desks, website forms, or transactional services that send mail for the same organization. You need access to the DNS zone that is authoritative for the domain. You should also identify every approved sender before changing the final SPF qualifier. Google documents its Workspace SPF setup and explains that the record must include Google's published sending infrastructure through `include:_spf.google.com`. Run a [DNS lookup on the root domain](/tools/dns-lookup) to review the current TXT records before adding anything. A domain can have unrelated verification TXT records alongside SPF, but it must not have multiple records that begin with [`v=spf1`](/learning/glossary/spf-v-spf1). SPF evaluation can return a permanent error when multiple SPF records are present. > Copy DNS values from the account and domain you are configuring. Do not publish selectors, targets, tokens, or hostnames from another account or from an online example. Record the current SPF value before editing it. If DNS is managed through infrastructure as code, identify the repository and change process before updating the zone. The SPF value for Google Workspace is public DNS data, but your complete record can identify services your organization uses. ## Which setup method should I use? Use the Google Workspace [include mechanism](/learning/glossary/spf-include) when Google Workspace sends mail directly for the domain. It lets receivers evaluate Google's current sending infrastructure without copying individual IP addresses into your record. Use a merged record when another approved sender also uses the same envelope-sender domain. Obtain that sender's SPF mechanism from its current official documentation, then add it to the existing policy before the final `all` mechanism. Use a separate sending subdomain when a bulk or transactional platform can use one. That keeps the parent-domain SPF policy focused on its own mail streams and can make sender ownership easier to review. A subdomain has its own SPF scope. Publishing SPF at `yourdomain.com` does not authorize `mail.yourdomain.com`. The [SPF learning hub](/learning/spf) covers record syntax, mechanisms, lookup limits, alignment, and related troubleshooting outside this Google Workspace setup path. ![Illustrative SPF record shapes for a Google Workspace-only domain and a domain with an additional approved sender](/images/editorial/how-do-i-set-up-spf-for-google-workspace/how-do-i-set-up-spf-for-google-workspace-records.webp "1200x466") *Source: Palisade.* ## How do I configure SPF for Google Workspace? ### 1. Open the DNS zone for the sending domain Open the DNS provider that hosts the authoritative zone for the domain used in your employee From addresses. The SPF record is not created in the Google Admin console. The current configuration path was verified from [Google Workspace SPF documentation](https://knowledge.workspace.google.com/admin/security/set-up-spf). Check that you selected the correct zone before editing. A primary domain, an alias domain, and a sending subdomain can be separate DNS zones or have separate owners. ![Google Workspace Admin Help showing Google's published SPF alert when a primary-domain record does not include Google servers](/images/editorial/how-do-i-set-up-spf-for-google-workspace/google-workspace-spf-alert-official.png "1280x720") *Source: [Google Workspace Admin Help: SPF record doesn’t include Google servers](https://support.google.com/a/answer/12084902?hl=en), captured 2026-08-10. This is Google’s published warning screen, not a view of your account.* ### 2. Find any existing SPF record Search the root-domain TXT records for a value beginning with `v=spf1`. Preserve that record if it authorizes legitimate services. If no such value exists, create one TXT record. If one exists, edit it to add Google's include mechanism. Do not add a new `v=spf1` record beside the old one. > Publishing two SPF records for the same domain can cause SPF evaluation to return a permanent error. Merge authorized mechanisms into one record instead. ### 3. Publish the Google Workspace SPF mechanism For a domain that sends only through Google Workspace, publish this record structure. **Record type:** `TXT` **Host:** `@` or the provider's root-domain field **Value:** ```text v=spf1 include:_spf.google.com ~all ``` This example is the documented Google Workspace SPF shape. Your DNS provider may ask for `@`, a blank host field, or the zone name to represent the root. Check the provider's resulting fully qualified owner name before saving. Some DNS interfaces automatically append `yourdomain.com` to the host field. Entering `yourdomain.com` into a field that already appends the zone can create `yourdomain.com.yourdomain.com`, which leaves the intended root without an SPF record. Google's record uses `~all`, a soft fail for sending sources that do not match an earlier mechanism. Keep it. On a domain that sends mail, `~all` plus an enforcing DMARC policy blocks spoofing just as `-all` does, and it does not risk the SMTP-time rejections that lose forwarded mail. Reserve `-all` for domains that send no mail at all. ### 4. Merge other approved senders into the same record Add each approved sender's mechanism after Google's include and before the final qualifier. The following is illustrative only. Replace `include:spf.example-mailer.test` with the exact mechanism supplied by the relevant sender. **Record type:** `TXT` **Host:** `@` or the provider's root-domain field **Value, illustrative only:** ```text v=spf1 include:_spf.google.com include:spf.example-mailer.test ~all ``` > Do not publish the illustrative additional include. Copy the current SPF mechanism from the sender you have approved, and remove mechanisms for services that no longer send mail for the domain. SPF has a DNS lookup limit during evaluation. [RFC 7208](https://www.rfc-editor.org/rfc/rfc7208.html#section-4.6.4) requires implementations to "limit the total number of those terms to 10" and to return `permerror` past that. Each `include`, redirect, and some other mechanisms can add lookups. Keep an inventory of why every mechanism exists, and remove obsolete services before adding another sender. ### 5. Send a real test message After public DNS returns the intended value, send a new message from the exact Google Workspace mailbox and route that production users normally use. Send it to a mailbox where you can inspect message source. A test sent before the DNS change does not validate the new record. Test any materially different route separately, such as mail that passes through an outbound gateway or mail sent by a connected application. Those paths can use a different SMTP envelope sender. ![SPF setup validation path from DNS publication to a delivered Google Workspace message](/images/editorial/how-do-i-set-up-spf-for-google-workspace/how-do-i-set-up-spf-for-google-workspace-spf-validation-flow.webp "1200x676") *Source: Palisade.* ## Investigate this with your coding agent Use this when your DNS zone is managed through a repository. Prepare the current redacted SPF value, the proposed Google Workspace mechanism, and the DNS record file path. ```agent Problem: Google Workspace needs to be authorized in the SPF record for the production sending domain without creating a second SPF record. Evidence: Redacted current root TXT records, the domain name, the proposed include:_spf.google.com mechanism, and the current DNS lookup or message-header result. Repository scope: The DNS-as-code repository and files that define the sending domain's TXT records. Constraints: Inspect before editing. Do not apply changes until I approve the proposed diff. Preserve unrelated TXT records, keep exactly one v=spf1 record, and do not include secrets, tokens, private keys, or customer data. Requested output: Diagnosis, minimal proposed change, rollback, and unknowns. Verification: Query the authoritative DNS answer and a public resolver, then send a new Google Workspace message and inspect its Authentication-Results. Stop if: Credentials, private data, production mutation, or missing evidence is required. ``` ## How does this setup affect DMARC? SPF contributes to DMARC only when the SPF-authenticated domain aligns with the visible From domain under the domain's DMARC alignment policy. A Google Workspace message can pass SPF but still fail SPF alignment if its envelope-sender domain does not align with the visible From domain. DKIM can independently satisfy DMARC when its signing domain aligns. Configure and test both protocols for Google Workspace with the related guide on [setting up DKIM for Google Workspace](/learning/dkim-google-workspace). Use Palisade's [DMARC checker](/tools/dmarc) to inspect the published DMARC record before changing DMARC policy. A public record check cannot show whether a specific production message aligned, and it cannot predict a receiver's future delivery decision. ## How do I validate the setup? ### Check public DNS Query the root TXT records through the authoritative DNS service and at least one public resolver. Confirm that there is one SPF record and that it includes `_spf.google.com`. ```bash dig +short TXT yourdomain.com ``` You can also [check the SPF record](/tools/spf) to inspect the public policy and identify syntax or lookup concerns. A public DNS result does not prove that Google Workspace used the expected envelope sender for a delivered message. ### Check the vendor status in Google Workspace Confirm that the selected mailboxes and domains are active in Google Workspace and that the intended users send through the expected Google Workspace path. Google Workspace does not use an SPF status indicator as proof that every outbound message path is covered. ### Inspect a delivered message Open the raw source for a newly delivered message. Inspect the receiver-added `Authentication-Results` field. [RFC 8601 defines Authentication-Results and its trust boundary](https://www.rfc-editor.org/rfc/rfc8601.html). Look for `spf=pass` and compare the reported `smtp.mailfrom` domain with the visible From domain. A pass proves the receiver evaluated the tested SMTP path as authorized. It does not prove that a different application, gateway, or future sender will pass. ### Review DMARC reports After DMARC aggregate reports accumulate, review Google Workspace traffic separately from other sources using the domain. Look for SPF results, DKIM results, and alignment patterns. This is the layer that helps reveal senders that were not included in the original SPF inventory. ## Troubleshooting ### Public DNS has no SPF record Check the final owner name shown by the DNS provider. The common failure is a duplicated zone name caused by entering a fully qualified domain into a host field that appends the zone automatically. Query the bare sending domain again after correcting the record. Confirm the authoritative response before waiting for public resolvers to update. ### SPF returns a permanent error Look for more than one TXT value beginning with `v=spf1` at the root. Consolidate the approved mechanisms into one record and remove the duplicate SPF policy. Also inspect the record's lookup count. Excessive nested includes can cause SPF evaluation to exceed its lookup limit. Remove former services or move a suitable bulk sender to a dedicated subdomain. ### Google Workspace mail passes SPF but DMARC fails Inspect the message's `smtp.mailfrom` domain and visible From domain. SPF can pass for a domain that does not align with the visible From domain. Check DKIM alignment as well, because aligned DKIM can satisfy DMARC when SPF alignment does not. ### Some employee mail passes but application mail does not Compare raw headers from each path. An application, relay, or security gateway can use a different SMTP server or envelope sender than direct Google Workspace mail. Add only the approved sender's documented mechanism after confirming its ownership and purpose. ### Mail passes SPF but delivery is still poor SPF is an authorization check, not an inbox-placement guarantee. Review DKIM, DMARC, message content, recipient feedback, and the receiver's own diagnostics. For another vendor sending alongside Google Workspace, see [how to set up SPF and DKIM for Amazon SES](/learning/how-do-i-set-up-spf-and-dkim-for-amazon-ses). ## Check the SPF record before expanding DMARC coverage Check the published record after DNS answers publicly, then compare it with a new delivered Google Workspace message. Palisade's SPF checker can inspect the current public SPF policy and help identify record-level issues before you add more sending sources. For an ongoing domain portfolio, Palisade is agentic DMARC software that analyzes DMARC aggregate-report data, identifies sending sources and authentication or alignment issues, and creates prioritized remediation tickets. It proposes the next policy step when the evidence supports it, and a person reviews and applies every change. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=existing_content_migration&utm_content=how-do-i-set-up-spf-for-google-workspace) ## Sources and further reading - [Google Workspace SPF setup documentation](https://knowledge.workspace.google.com/admin/security/set-up-spf) - [RFC 7208: Sender Policy Framework](https://datatracker.ietf.org/doc/html/rfc7208) - [RFC 8601: Authentication-Results](https://www.rfc-editor.org/rfc/rfc8601.html) - [Palisade learning center](/learning) ## Frequently asked questions ### What SPF record should I use for Google Workspace? Use `v=spf1 include:_spf.google.com ~all` when Google Workspace is the only approved sender for the domain. If other services send mail using the same envelope-sender domain, merge their current approved mechanisms into that one record before the final qualifier. ### Should I add a second SPF record for Google Workspace? No. Add `include:_spf.google.com` to the existing SPF record if one already begins with `v=spf1`. Multiple SPF records for one domain can produce an SPF permanent error. ### Does Google Workspace SPF go in the Admin console? No. Publish the SPF TXT record with the DNS provider that hosts the authoritative zone for the sending domain. Google Workspace sends the mail, while DNS publishes the authorization policy receivers evaluate. ### Does SPF pass mean DMARC passes? No. SPF must also align with the visible From domain to satisfy DMARC through SPF. An aligned DKIM pass can satisfy DMARC independently, so inspect both results in the delivered message and later in DMARC reports. ### Should I use `~all` or `-all` for Google Workspace? Use `~all`. Google's documented Workspace SPF example ends in `~all`, and Google warns that a hard fail qualifier makes failing messages more likely to be rejected and unusable for troubleshooting the record. Reserve `-all` for a domain that sends no mail. --- # Set up DMARC for Office 365 (Microsoft 365) Canonical: https://www.palisade.email/learning/how-do-you-enable-dmarc-for-microsoft-365 > Set up DMARC for Office 365 and Microsoft 365: publish a monitoring record, validate aligned SPF or DKIM, and raise policy only after report evidence. To enable DMARC for Microsoft 365, still widely called Office 365, publish a DMARC TXT record for each sending custom domain in public DNS after confirming that its production mail can pass aligned SPF or DKIM. Begin with the monitoring policy, `p=none`, review aggregate-report and delivered-message evidence, then move to `p=quarantine` and `p=reject` only when legitimate senders are accounted for. Microsoft documents DMARC configuration for custom domains in its [DMARC configuration guidance](https://learn.microsoft.com/en-us/defender-office-365/email-authentication-dmarc-configure). ## Quick takeaways - Microsoft 365 custom-domain DMARC policies are published in the domain's public DNS zone. - DMARC passes when SPF or DKIM passes and aligns with the visible From domain. - Start active sending domains at `p=none` so aggregate reports can reveal legitimate senders. - Do not publish more than one DMARC TXT record at the same `_dmarc` owner name. - A public DNS result does not prove that a Microsoft 365 message passes DMARC. - Move from monitoring to quarantine and reject only after report and message evidence supports the change. ## Scope and prerequisites This setup applies to a custom domain that sends mail through Microsoft 365, such as `yourdomain.com`. It does not create a DMARC policy through an Exchange admin setting. The record belongs in the authoritative public DNS zone for the visible From domain, as described in [Microsoft's DMARC configuration guidance](https://learn.microsoft.com/en-us/defender-office-365/email-authentication-dmarc-configure). Before publishing the record, identify the domains and subdomains that appear in outbound From addresses. Include Microsoft 365 mailbox traffic, shared mailboxes, applications, ticketing systems, marketing platforms, and any outbound gateway. Each production route needs separate validation because a domain's DNS record does not prove how every sender authenticates. Assign clear owners for: - The DNS zone change. - Microsoft 365 domain and DKIM configuration. - The shared mailbox or service that receives aggregate reports. - Test-message delivery and header inspection. - Approval for policy changes and rollback. You need an SPF record and DKIM configuration appropriate to the sending domain before enforcement. [RFC 9989 describes DMARC alignment](https://www.rfc-editor.org/rfc/rfc9989.html) as the relationship between the visible From domain and the SPF or DKIM identity that passed. A passing SPF or DKIM result from an unrelated domain does not produce an aligned DMARC pass. Set a rollback condition before changing policy. If a legitimate production source fails DMARC after a policy increase, return to the last known-good policy while you correct that sender and gather new evidence. > Do not replace an existing DMARC record without reviewing it first. A domain should publish one DMARC record at `_dmarc`; adding a second TXT value can produce an invalid or ambiguous result for receivers. For background on policy tags and alignment, use the [Palisade DMARC learning hub](/learning/dmarc). ## Choose the implementation approach Use the domain's sending role to choose the first policy: - For an active domain with known and unknown senders, publish `p=none` and collect evidence before enforcement. - For a domain that is registered but must never send mail, use a restrictive policy only after confirming that no legitimate source uses it. - For a subdomain with a distinct mail stream, publish and validate its own DMARC record when you need a separate policy or reporting scope. - For a parent domain whose subdomains do not publish their own records, understand that DMARC policy inheritance can affect those subdomains. Validate their actual sending use before relying on the parent policy. Microsoft's guidance describes the policy values `none`, `quarantine`, and `reject`. The safe sequence for an active Microsoft 365 domain is monitoring first, then [quarantine](/learning/glossary/dmarc-p-quarantine), then reject. Do not treat this as a calendar-based rollout. Advance only when aggregate reports and production-path messages show that legitimate mail authenticates and aligns. If aggregate reports should go to an address outside the protected domain, check the external-report authorization requirements in [RFC 9989](https://www.rfc-editor.org/rfc/rfc9989.html). An external reporting destination may need an authorization record before receivers send reports to it. ## How to configure DMARC for Office 365 and Microsoft 365 ### 1. Inventory the domains and production senders Create an inventory for each visible From domain. Record the Microsoft 365 tenant or mail route, expected SPF identity, expected DKIM signing domain, DNS owner, and a test recipient for each route. Keep Microsoft 365 mailbox traffic separate from other senders that use the same From domain. A CRM or transactional service can use the same brand domain while authenticating through different infrastructure. ### 2. Confirm SPF and DKIM are ready for the domain [Look up the domain's published TXT records](/tools/dns-lookup) to confirm it has the intended SPF record, and check that [Microsoft 365 DKIM signing](/resources-post/dkim-for-office-365) is configured for the custom domain. Microsoft directs organizations to configure SPF and DKIM before deploying DMARC for sending domains in its [DMARC configuration guidance](https://learn.microsoft.com/en-us/defender-office-365/email-authentication-dmarc-configure). Do not merge records by guesswork. SPF has one policy record per domain, and DMARC has one record at its owner name. Preserve the existing SPF value and update it only after reviewing every authorized sender. ### 3. Publish an initial monitoring record Create one TXT record at `_dmarc.yourdomain.com`. In many DNS consoles for `yourdomain.com`, the host field is `_dmarc`, but confirm whether the console appends the zone name automatically. The following record is illustrative only. Replace the report address with a mailbox or reporting service your organization controls. ```text _dmarc.yourdomain.com TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com" ``` The `p=none` policy asks receivers to monitor DMARC evaluation without requesting quarantine or rejection. The `rua` tag requests aggregate reports. Record syntax and policy behavior are defined in [RFC 9989](https://www.rfc-editor.org/rfc/rfc9989.html). Do not copy an address, authorization value, or DNS host from another organization. If the report address uses another domain, obtain the required authorization from the owner of that destination domain. ![DMARC rollout decision flow for a Microsoft 365 custom domain, from sender inventory through monitoring, validation, quarantine, and reject](/images/editorial/how-do-you-enable-dmarc-for-microsoft-365/how-do-you-enable-dmarc-for-microsoft-365-dmarc-rollout.webp "1200x829") *Source: Palisade.* ### 4. Verify the published DNS answer Query the fully qualified record name at the authoritative DNS provider and with at least one public resolver. Confirm that the answer contains one intended DMARC policy beginning with `v=DMARC1`, [the tag that identifies a DMARC record](/learning/glossary/dmarc-v-dmarc1). ```bash dig +short TXT _dmarc.yourdomain.com ``` A resolver can show cached data after a DNS update. Compare the expected value with the authoritative answer before changing the record again. A TXT lookup proves only public DNS publication. It does not show whether Microsoft 365 signs a new message correctly or whether a receiver will accept the message. ### 5. Send a new message through Microsoft 365 Send a new message from the exact Microsoft 365 mailbox and custom From domain under review. Deliver it to a mailbox where you can inspect the full received headers. Look for the receiver's `Authentication-Results` header. [RFC 8601 defines Authentication-Results](https://www.rfc-editor.org/rfc/rfc8601.html) and explains that its results are assertions made by the receiving system. Confirm the delivered message reports `dmarc=pass` and that the passing SPF or DKIM identity aligns with the visible From domain. An old message cannot validate this configuration. Send after the DNS and Microsoft 365 signing state are in place. ### 6. Review reports before increasing policy Allow normal traffic to generate aggregate-report evidence. Compare reporting sources and domain identifiers with the sender inventory. Investigate legitimate sources that fail alignment before requesting enforcement. Reports show sending sources and outcomes over time, not tenant configuration. [Office 365 DMARC monitoring](/learning/dmarc-monitoring-o365) covers how the DNS, message, and report layers differ. When the evidence is clean, update the existing DMARC record from `p=none` to `p=quarantine`. Repeat the DNS, delivered-message, and report checks. Move to `p=reject` only after quarantine-stage evidence shows that legitimate senders remain accounted for. ## How to validate the setup Validation has four separate layers: - DNS: query `_dmarc.yourdomain.com` at the authoritative service and a public resolver. Confirm one intended DMARC TXT record. - Microsoft 365 sender state: confirm the custom domain and its DKIM configuration are the ones used by the production mailbox route. A green configuration status is useful evidence, but it is not message evidence. - Delivered message: inspect a newly delivered production-path message. Confirm the receiver reports an aligned SPF or DKIM pass and `dmarc=pass`. - DMARC reporting: compare aggregate-report data with the sender inventory after normal traffic accumulates. This identifies sources a one-message test did not cover. ![Microsoft 365 DMARC validation checklist covering DNS, sender state, delivered message, and aggregate reports](/images/editorial/how-do-you-enable-dmarc-for-microsoft-365/how-do-you-enable-dmarc-for-microsoft-365-validation-checklist.webp "1200x524") *Source: Palisade.* Record the result for each route: ```yaml from_domain: yourdomain.com sending_route: Microsoft 365 mailbox dns_record: v=DMARC1; p=none delivered_message: dmarc=pass aligned_identifier: example.com aggregate_report_status: reviewed policy_stage: monitoring ``` Use the [DMARC checker](/tools/dmarc) to inspect the public record before raising policy. The checker cannot confirm a tenant's DKIM state, a specific delivered message, future receiver decisions, or every production sending path. ## Troubleshooting ### The DMARC record does not resolve Check the DNS console's handling of zone suffixes. Entering `_dmarc.yourdomain.com` into a console that automatically appends `yourdomain.com` can create the wrong owner name. Query the full record owner and compare it with the DNS provider's displayed name. Also check for multiple TXT records at `_dmarc`. DMARC expects one policy record at the queried owner name. ### SPF or DKIM passes but DMARC fails Inspect alignment. SPF uses the authenticated MAIL FROM identity, while DKIM uses the signing `d=` domain. A message can pass SPF or DKIM and still fail DMARC when that identity does not align with the visible From domain. [RFC 9989's alignment rules](https://www.rfc-editor.org/rfc/rfc9989.html) explain this distinction. Test the exact Microsoft 365 path again after correcting the domain configuration. Do not infer alignment from a DNS record alone. ### Legitimate Microsoft 365 mail fails after a policy increase Return to the last known-good DMARC policy while you investigate the affected sender. Preserve the evidence: the published record, message headers, route owner, and report rows. Then correct the SPF, DKIM, or visible From-domain mismatch before retrying the policy change. If recipients report Microsoft 365 delivery failures, compare the message evidence with guidance on [Microsoft 365 outbound blocking](/email-deliverability/why-is-microsoft-365-blocking-outbound-emails) and [Microsoft 365 550 5.7.x rejections](/learning/fix-microsoft-365-550-5-7-x-access-denied). Those outcomes can require receiver-specific evidence beyond a DMARC DNS lookup. ### Aggregate reports do not arrive Confirm the `rua` address exists and can receive mail. If it is external to the protected domain, verify the applicable authorization record. Reports are generated by participating receivers, so an empty mailbox does not prove that the DMARC record is unused or that all senders pass. ## Check the DMARC record before raising the policy Use the [Palisade DMARC checker](/tools/dmarc) to inspect the public record that receivers can resolve. Compare the result with your intended DNS value and the delivered-message header before changing from monitoring to quarantine or reject. [Check the Microsoft 365 domain's DMARC record](/tools/dmarc) A public lookup does not identify every sender using the domain, repair an alignment failure, monitor later DNS drift, or predict a receiver's private delivery decision. For an ongoing Microsoft 365 rollout across multiple domains, Palisade is agentic DMARC software that analyzes aggregate-report data, identifies sources and alignment issues, creates prioritized remediation tickets, and proposes the next policy step for human review. It does not autonomously change the DMARC policy. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=existing_content_migration&utm_content=how-do-you-enable-dmarc-for-microsoft-365) ## Sources and further reading - [Microsoft: Configure DMARC for Microsoft 365](https://learn.microsoft.com/en-us/defender-office-365/email-authentication-dmarc-configure) - [RFC 9989: Domain-based Message Authentication, Reporting, and Conformance](https://www.rfc-editor.org/rfc/rfc9989.html) - [RFC 8601: Authentication-Results header field](https://www.rfc-editor.org/rfc/rfc8601.html) - [Palisade DMARC checker](/tools/dmarc) ## Frequently asked questions ### Do I enable DMARC in the Microsoft 365 admin center? No. For a Microsoft 365 custom domain, publish the DMARC TXT record in the domain's public DNS zone. Microsoft documents the DNS-based configuration in its [DMARC guidance](https://learn.microsoft.com/en-us/defender-office-365/email-authentication-dmarc-configure). ### Should I start Microsoft 365 DMARC with p=reject? No. Start an active sending domain with `p=none` while you identify legitimate sending sources and verify alignment. Move to quarantine and reject after aggregate reports and delivered-message tests support each change. ### Does passing SPF mean Microsoft 365 DMARC is configured correctly? No. SPF must both pass and align with the visible From domain to provide a DMARC pass. DKIM can also provide the aligned pass when its signing domain aligns. ### Can one DMARC record cover Microsoft 365 subdomains? Only when a subdomain does not publish its own DMARC record and the parent policy applies to it. Review each subdomain's sending use before relying on inherited policy, because a subdomain can have separate senders and risk. ### Does a DMARC checker prove Microsoft 365 mail will be delivered? No. A DMARC checker can inspect public DNS. It cannot prove that Microsoft 365 uses the expected signing configuration, that every sending route aligns, or that a recipient will make a particular delivery decision. --- # Multi-tenant DMARC remediation Canonical: https://www.palisade.email/learning/multi-tenant-dmarc-remediation > Multi-tenant DMARC remediation workflow for MSPs: turn report findings into owned, approved sender fixes, exception decisions, and policy gates. Multi-tenant DMARC remediation needs a repeatable way to turn report findings into client-owned decisions. An MSP should separate what a DMARC aggregate report observed from what a client has authorized, assign each gap to the party that controls it, and move each domain through repair and policy gates with documented approval. One portfolio view is useful, but each client domain still needs its own evidence, owner, exception status, and rollback condition. ## Quick takeaways - A reported sending stream is evidence, not proof that the client authorizes that sender. - Keep client approval, DNS publication, sender configuration, and receiving-provider handling as separate responsibilities. - Use one remediation record per client domain and one exception record per unresolved stream. - Require DNS, sender, delivered-message, and aggregate-report evidence before closing material remediation work. - Advance DMARC policy only after the client accepts the supporting evidence and remaining risk. - Report portfolio progress as open decisions and verified work, not as a universal protection score. ## Operating context and ownership Multi-tenant remediation differs from a single-domain DMARC project because the MSP must keep evidence and authority separate across client organizations. A report consumer may identify a stream that fails alignment, but the report cannot establish whether that stream belongs to a marketing platform, a retired application, an attacker, or another tenant. [RFC 9989 defines DMARC alignment and policy evaluation](https://www.rfc-editor.org/rfc/rfc9989.html), while [RFC 9990 defines aggregate-report data and handling](https://www.rfc-editor.org/rfc/rfc9990.html). Treat the following responsibilities as distinct: - The client confirms business ownership, accepts delivery risk, and approves policy changes. - The MSP collects evidence, maintains the remediation queue, coordinates handoffs, and proposes an evidence-based next step. - The DNS host publishes approved DMARC, SPF, DKIM, and related DNS changes. - The sending-platform owner enables or repairs the platform's authentication configuration. - The receiving mailbox provider makes its own delivery and enforcement decisions. This is a Palisade operating framework, not an RFC requirement. It prevents a common portfolio failure: an operator sees a stream in reports, assumes it is legitimate, and changes policy or DNS before anyone who owns the business process has confirmed it. Use [Palisade's MSP page](/for-managed-service-providers) as the service-level reference point for organizing a recurring portfolio workflow. A public [DMARC checker](/tools/dmarc) can confirm the currently published record for one domain, but it cannot prove which production systems send mail, whether a client authorizes them, or how a mailbox provider will handle future messages. For foundational protocol guidance, see Palisade's [DMARC learning resources](/learning/dmarc). ## Evidence to collect Create a working record for every in-scope domain. Record source and date for each finding so an onboarding statement, a DNS response, a delivered message, and a report observation do not become indistinguishable. ```yaml client: example-client domain: yourdomain.com evidence: - type: aggregate-report status: observed-unaligned-stream collected_on: 2026-08-10 owner: client-marketing-owner next_action: confirm-sender-and-request-authentication-settings review_on: 2026-08-17 ``` The working record should include: - Client name, technical approver, business owner, and incident contact. - Domain and subdomain scope. - DNS provider, DNS change owner, and required approval path. - Known sender inventory, including marketing, CRM, finance, support, transactional, and low-frequency systems. - The current DMARC policy and aggregate-report destination. - Evidence state for each stream: `client-confirmed`, `report-observed`, `message-verified`, `unknown`, `retired`, or `abusive`. - The affected authentication result, alignment result, owner, next action, review date, and rollback trigger. - Any business freeze period, high-risk sending window, or provider dependency. Aggregate reports can identify unauthenticated or unaligned streams. They do not confirm authorization. A client-confirmed sender may still require repair, and an unknown sender may require investigation before it is classified as unauthorized. Use a four-layer completion check for material fixes: - DNS: query the authoritative DNS server and at least one public resolver after publication. - Vendor: check the sender's current authentication or verification status where the vendor provides one. - Message: inspect a real delivered message from the exact production path and its `Authentication-Results` fields. - DMARC: review aggregate reports after enough report periods have accumulated. A green sender-platform indicator is not proof that a production message signs and aligns. A passing public DNS response is not proof that the application uses that record. ![Portfolio remediation decision flow separating observed streams from client authorization and policy approval](/images/editorial/multi-tenant-dmarc-remediation/multi-tenant-dmarc-remediation-decision-flow.webp "1200x980") *Source: Palisade.* ![Multi-client remediation queue with ownership, evidence, and review status](/images/editorial/multi-tenant-dmarc-remediation/multi-tenant-dmarc-remediation-queue.webp "1200x600") *Source: Palisade.* ## How to run the workflow ### 1. Triage the reported stream Owner: MSP remediation operator. Input: aggregate-report finding and current domain record. Output: an evidence record with a provisional classification. Record the reporting period, source identity available in the report, authentication result, alignment result, volume, and affected domain. Do not mark the source authorized because it has a familiar provider name or appears at high volume. Assign it `unknown` until the client or a delegated owner confirms its business purpose. ### 2. Confirm authority and business impact Owner: client technical or business owner. Input: the provisional evidence record. Output: an authorized, retired, abusive, or unresolved classification. Ask the client to identify the sending system, business function, system owner, and required sending window. If the client cannot confirm the source, leave the record open. A sender that appears once may be a legitimate low-frequency workflow, but it may also be unrelated to the client's approved systems. For an authorized sender, document who can change its configuration. For an abusive or unknown sender, document the client decision and retain the evidence that led to the classification. ### 3. Assign the repair to the controlling party Owner: MSP service owner. Input: confirmed sender classification and evidence gap. Output: an owner-specific remediation ticket. The ticket should name the observed condition and the completion test. For example, an authorized marketing sender with an unaligned DKIM identifier needs a sender-platform owner to configure the provider-generated authentication values, then provide a delivered-message sample for review. Do not use a ticket title such as "fix DMARC." The DMARC policy evaluates SPF and DKIM alignment, so remediation must identify the actual failed path. [RFC 9989 describes how aligned SPF or DKIM contributes to DMARC pass](https://www.rfc-editor.org/rfc/rfc9989.html). > Do not publish a stricter DMARC policy to compensate for an unverified sender inventory. A policy change can affect legitimate mail that has not yet been identified and repaired. ### 4. Validate the same production path Owner: sender owner with MSP verification. Input: proposed sender or DNS change. Output: four-layer validation evidence. First, confirm the published DNS record through the authoritative server and a public resolver. Next, check the sender platform's available verification status. Then send a real message through the exact production path and inspect its raw headers. `Authentication-Results` is the message-level evidence that shows how the receiving system evaluated authentication. [RFC 8601 defines the Authentication-Results header field](https://www.rfc-editor.org/rfc/rfc8601.html). Retain only redacted header evidence in the client record. Do not store credentials, private keys, tokens, or unredacted customer content in a shared portfolio queue. After report data arrives, compare the repaired path with the aggregate-report outcome. If the report still shows an unexpected result, reopen the work item rather than relying on a single test message. ### 5. Apply the policy gate with client approval Owner: client approver, supported by the MSP. Input: completed remediation record, open exceptions, and rollback condition. Output: an approved policy decision or a documented hold. A domain is ready for a policy-stage recommendation only when legitimate sources have been reviewed, material failures have an owner or accepted exception, and the client has approved the proposed change. The MSP may recommend the next policy stage from the evidence, but the client must approve the decision and the authorized party must apply the DNS change. Record the complete before and after DMARC TXT values, the effective time, the client approver, and the rollback trigger. Do not describe enforcement as a [percentage rollout with `pct`](/learning/glossary/dmarc-pct). [RFC 9989 removes the former `pct` tag and defines the current policy and testing-tag behavior](https://www.rfc-editor.org/rfc/rfc9989.html). ### 6. Close, defer, or escalate the record Owner: MSP service owner. Input: post-change evidence and client response. Output: closed work, a dated exception, or an escalation. Close a remediation item only when the defined evidence supports the requested result. Defer it only with a named owner and review date. If an authorized sender cannot support aligned SPF or DKIM, the client must decide whether to retain the risk, change the sending path, or delay a policy change. ## Exceptions and escalation Use the following decision model for every unresolved stream: - Reported stream with no client confirmation: keep it `unknown`, request an owner, and set a review date. - Client-confirmed sender with a repair path: assign the task to the sender or DNS owner and require same-path retesting. - Client-confirmed sender with no safe repair path: document the delivery risk, required business approval, and policy hold. - Source identified as abusive or unrelated: preserve the evidence and follow the client incident process. Do not treat a DMARC report as a complete incident investigation. - Missing DNS authority or sender access: escalate to the client sponsor with the blocked action and required access. - Post-change failure on a business-critical path: use the agreed rollback condition and incident contact. The decision flow is intentionally tenant-specific. An exception accepted by one client does not authorize the same source or risk decision for another client, even if the provider is the same. ## Reporting and success measures Run a monthly portfolio review and a client-specific operational summary. The report should distinguish work completed from decisions that remain open. Include these artifacts: - Domains grouped by remediation state: intake, evidence review, repair, validation, policy gate, or steady state. - Confirmed, unknown, retired, and abusive-source classifications. - Open work by controlling owner and review date. - Exceptions with client approval status, risk statement, and next review. - Policy changes with before value, approval, post-change evidence, and rollback result. - Report-delivery gaps that could hide a change in the domain's sending activity. Measure operational control, not a claim that every future message will pass DMARC. Useful measures include the age of unknown streams, overdue remediation records, domains without a named approver, and policy changes missing post-change evidence. Palisade is agentic DMARC software that can analyze DMARC aggregate-report data, identify sending sources and authentication or alignment issues, and create prioritized remediation tickets. It can propose the next policy step when the evidence indicates readiness. The MSP and client still review the evidence, authorize senders, and apply approved changes. ## Turn multi-client findings into an owned remediation queue After building the evidence record, use a recurring portfolio workflow to keep unknown streams, overdue repairs, and policy decisions visible across clients. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=msp_operations&utm_content=multi-tenant-dmarc-remediation) to organize DMARC report findings into prioritized remediation work and review domain readiness for the next policy stage. Palisade does not authorize a client's sender, change DNS or DMARC policy without human review and approved access, prove every production message will authenticate, or guarantee a receiving provider's delivery decision. ## Sources and further reading - [RFC 9989: Domain-based Message Authentication, Reporting, and Conformance](https://www.rfc-editor.org/rfc/rfc9989.html) - [RFC 9990: DMARC Aggregate Reporting](https://www.rfc-editor.org/rfc/rfc9990.html) - [RFC 8601: Message Header Field for Indicating Message Authentication Status](https://www.rfc-editor.org/rfc/rfc8601.html) - [Palisade documentation](https://docs.palisade.email/) ## Frequently asked questions ### Can an MSP treat every DMARC report source as an approved sender? No. A DMARC aggregate report shows observed authentication and alignment outcomes, but it does not establish business authorization. A client owner or delegated sender owner must confirm whether the source is legitimate. ### Does a passing DMARC record check prove the sending path works? No. A public record check confirms the published DNS response at that point in time. It does not prove that a production application signs with the expected domain, uses the intended return path, or will receive a particular mailbox-provider decision. ### Who should approve a DMARC policy change for a client domain? The client should approve the policy change because the client accepts the delivery risk and owns the business impact. An MSP can prepare evidence and recommend a policy step, while an authorized DNS owner applies the approved change. ### What evidence should close a multi-tenant remediation ticket? A material remediation ticket should include DNS confirmation, sender-platform status where available, a delivered-message header from the repaired path, and later aggregate-report evidence. The exact record should also identify the client, domain, owner, next action, and review date. ### Can Palisade automatically move a client to DMARC enforcement? No. Palisade can analyze aggregate-report data, identify authentication or alignment issues, create prioritized remediation tickets, and propose the next policy step. A human reviews the evidence and applies an approved policy change. --- # Email warmup software: how to evaluate your options Canonical: https://www.palisade.email/learning/email-warmup-software > Email warmup software can simulate inbox activity, but choose it only after verifying its scope, claims, controls, and deliverability tradeoffs. Choose Warmup Inbox if you specifically want a vendor-operated service that connects a sending inbox and generates mailbox activity through its network. Choose Palisade if the job is DMARC operations across one or many domains. They do not solve the same problem: Warmup Inbox describes warmup activity and placement tracking, while Palisade analyzes DMARC aggregate reports and helps teams prioritize authentication remediation. ## Quick takeaways - Warmup Inbox describes an automated email-warmup service that connects to a sending inbox and exchanges messages through its network. - The vendor states that its network uses opens, replies, and stars, but the vendor's public statements do not establish how every receiving provider treats that activity. - Warmup Inbox's placement and ramp guidance is vendor guidance, not a Gmail, Microsoft, or Yahoo requirement. - A blacklist result is evidence from the list checked at that time, not proof of universal sender reputation or future inbox placement. - Palisade is for ongoing DMARC analysis and remediation planning, not for generating warmup traffic. - Treat unverified pricing, account controls, provider exclusions, and rescue-process details as open questions before purchase. ## Who this comparison is for This comparison is for an operator evaluating email warmup software before connecting a production sending inbox. The immediate question is usually whether a service can help establish or rehabilitate a sending pattern before a campaign begins. That question needs a narrower answer than "which tool is best?" A warmup service and a DMARC platform address different evidence. A warmup vendor may describe simulated mailbox activity, while DMARC reporting identifies production sending sources and authentication or alignment failures. Neither category can guarantee inbox placement at a mailbox provider. Readers comparing commercial email tools can use the broader [Palisade comparison hub](/compare) for vendor-evaluation context. If the core problem is authentication, message quality, sender reputation, or receiving-provider behavior, start with the wider [email deliverability guide](/email-deliverability) before assigning the problem to a warmup product. ## How the options were evaluated The criteria below were applied on August 6, 2026, using each vendor's own published product statements. - Job fit: Whether the option addresses simulated warmup activity, DMARC operations, or another email-deliverability task. - Documented inputs: What the vendor says an operator connects or provides. - Documented evidence: What the product says it tracks, analyzes, or reports. - Operational boundary: What the available documentation does not establish. - Purchase readiness: Whether pricing, restrictions, setup controls, and terms are documented in the vendor's public materials. A documented vendor statement counts as a statement from that vendor. It does not establish a universal mailbox-provider rule, an independently verified placement result, or a guarantee that future messages will reach the inbox. ![Decision checklist for evaluating email warmup software claims, account access, measurement scope, and unresolved vendor questions](/images/editorial/email-warmup-software/email-warmup-software-evaluation-checklist.webp "1200x600") *Source: Palisade.* ## Warmup Inbox Warmup Inbox is the option in this comparison that positions itself as email warmup software. Its homepage calls the product "The email warmup tool that builds your sender reputation, automatically" and says a user can connect a sending inbox through Gmail, Outlook, or SMTP. The same page says its network has "30,000+ real inboxes" that exchange messages with opens, replies, and stars. These are [Warmup Inbox product statements](https://warmupinbox.com), checked August 6, 2026. - Best fit: A sender who wants a vendor-operated warmup service for a connected inbox and accepts the vendor's stated network-based approach. - Relevant evidence: Warmup Inbox states that it supports Gmail, Outlook, Google Workspace, Microsoft 365, custom SMTP, Yahoo, Zoho, ProtonMail, Fastmail, iCloud, AWS SES, and Mailgun. It also states that tracking includes inbox, spam, and bounce rates, plus DNS, SPF, DKIM, and blacklist checks. [Warmup Inbox's homepage](https://warmupinbox.com) is the source for those statements, checked August 6, 2026. - Tradeoff: This comparison could not verify current pricing, billing units, plan limits, cancellation terms, OAuth permissions, SMTP fields, provider exclusions, or the safeguards around its engagement network. Confirm each with the vendor before connecting an inbox. Warmup Inbox also says it watches more than 100 blacklists daily and runs an automatic rescue process if an inbox is listed. That is a vendor claim about its service. It is not evidence that the service can delist an IP address, change a receiver's private reputation decision, or restore inbox placement at every mailbox provider. You can [scan the domain against public blacklists](/tools/domain-reputation) yourself to see its current listing status. The vendor recommends a gradual rollout. It says initial improvements may appear in 3 to 7 days and that a full ramp takes at least 14 to 21 days. It also gives "under 20-50 emails per day" during the first weeks as an example of low campaign volume. Those are [Warmup Inbox recommendations](https://warmupinbox.com), not universal sending thresholds published by mailbox providers. Warmup Inbox's homepage also contains placement figures, including "+15% more email in Primary," "90% Primary placement by day 14," and "98% in Primary." The page labels at least one placement statement as an internal benchmark. Treat those figures as vendor-reported internal benchmarks, not as a forecast for a specific domain or campaign. ## Palisade Palisade is not email warmup software. It is agentic DMARC software for teams that need to understand which sources send for their domains, which sources fail authentication or alignment, and what to address before moving a DMARC policy forward. - Best fit: An IT team or MSP that needs ongoing DMARC aggregate-report analysis and a remediation workflow across one domain or thousands. - Relevant evidence: Palisade analyzes DMARC aggregate-report data, identifies sending sources and authentication or alignment issues, creates prioritized remediation tickets, and can propose the next DMARC policy step when evidence indicates readiness. A human reviews the evidence and applies the change. - Tradeoff: Palisade does not generate warmup traffic, alter a mailbox provider's reputation decision, guarantee delivery, or autonomously change the DMARC policy. That distinction matters when the sending domain has unresolved authentication issues. A warmup workflow cannot prove that all production sources pass DMARC alignment. DMARC aggregate reports and real delivered-message headers answer different questions than a point-in-time public DNS result. For a focused public check, use the [DMARC checker](/tools/dmarc) to inspect the published DMARC record. The result can show the public record available at the time of the lookup. It cannot prove the production sending path, monitor future changes, or show why a specific receiver placed a message in spam. ## How to choose Choose Warmup Inbox only if its vendor-stated operating model matches the inbox you intend to connect and the vendor can answer the unresolved questions that matter to your risk review. Ask for current pricing, account-access requirements, provider-specific exclusions, network controls, and the exact scope of any blacklist rescue process before connecting a production mailbox. Choose Palisade when the recurring task is DMARC visibility and remediation across production sending sources. It is a different operating category. It does not replace a warmup service for teams committed to generated warmup traffic. Use this evidence record to keep the decision tied to documented facts: ```yaml option: Warmup Inbox checked_on: 2026-08-06 best_fit: Vendor-operated inbox warmup for a connected sending mailbox verified_evidence: - Connects through Gmail, Outlook, or SMTP, according to the vendor - Vendor states its network exchanges emails with opens, replies, and stars - Vendor states it tracks inbox, spam, bounce, DNS, SPF, DKIM, and blacklist signals open_question: - Current pricing, account permissions, service limits, exclusions, and rescue-process details option: Palisade checked_on: 2026-08-06 best_fit: Ongoing DMARC analysis and prioritized remediation for IT teams and MSPs verified_evidence: - Analyzes DMARC aggregate-report data - Identifies sending sources and authentication or alignment issues - Proposes next policy steps for human review open_question: - It does not provide email warmup traffic ``` Before deciding, separate public DNS, vendor status, real-message evidence, and DMARC reporting. A vendor dashboard indicator is not a delivered-message check. A public checker is not proof that the application signed a message or used the expected return path. The related article [Does email warmup work?](/learning/does-email-warmup-work) can help frame that evidence boundary. ## Assess the deliverability problem before buying warmup software If the underlying issue is unknown, evaluate the sending and authentication basics before treating warmup as the answer. Review the domain's published controls, a real message from the production path, and the mailbox-provider evidence available for the issue. Read the [email deliverability guide](/email-deliverability) to map the problem to the right layer of evidence. It can help distinguish a public DNS configuration issue from an inbox-placement concern that requires real-message or provider-specific evidence. A deliverability guide cannot prove that a particular warmup vendor will improve placement, repair a sender's reputation, or control a receiver's private filtering decision. ## Sources and further reading - [Warmup Inbox homepage](https://warmupinbox.com), checked August 6, 2026. - [Palisade email deliverability guide](/email-deliverability). - [Palisade DMARC checker](/tools/dmarc). ## Frequently asked questions ### Is Warmup Inbox email warmup software? Yes. Warmup Inbox describes its product as an email warmup tool and says users can connect a sending inbox through Gmail, Outlook, or SMTP. Its homepage also states that its network exchanges messages with opens, replies, and stars. ### Does email warmup software guarantee inbox placement? No. No warmup product can guarantee placement at Gmail, Microsoft, Yahoo, or another mailbox provider. Placement decisions depend on receiver-controlled signals and the actual sending path. ### Does Warmup Inbox support Google Workspace and Microsoft 365? Yes. Warmup Inbox lists Google Workspace and Microsoft 365 among the providers it says it supports. Confirm each connection's setup conditions, permissions, and exclusions with the vendor during setup; the statements cited here do not cover them. ### Can a blacklist check prove that a sender has good reputation everywhere? No. A blacklist result applies to the list and input checked at that time. It does not expose every blocklist, a mailbox provider's private reputation data, or future delivery outcomes. ### Is Palisade an email warmup service? No. Palisade is DMARC software that analyzes aggregate-report data, identifies authentication and alignment issues, and helps teams prioritize remediation. It does not send warmup traffic or change a mailbox provider's private placement decision. --- # Is Gmail filtering my emails and how do I tell and fix it? Canonical: https://www.palisade.email/learning/is-gmail-filtering-my-emails > Is Gmail filtering your emails? Learn how to tell spam-foldering from a bounce or the Promotions tab, and the exact authentication and reputation fixes. Gmail is almost certainly filtering your mail if messages you send arrive in recipients' **Spam** folder, land in the **Promotions** or **Updates** tab instead of the primary inbox, or never appear at all while your logs show them as "sent." Gmail does not silently drop mail without a reason: it filters on three things it can measure: whether your domain is properly authenticated with SPF, DKIM, and DMARC; your sending domain and IP reputation; and how recipients engage with what you send. Fix those, and the filtering stops. This guide shows how to confirm Gmail is the one filtering, tell the different outcomes apart, and work through the fixes in order. ## Quick takeaways - **Filtered ≠ bounced.** Spam-foldering, the Promotions tab, and an outright `550` rejection are three different outcomes with different fixes. Identify which one you have first. - The single biggest lever is **authentication**: Gmail expects valid [SPF](/learning/what-is-spf), [DKIM](/learning/what-is-dkim), and an aligned DMARC record on every domain you send from. - Gmail publishes your **spam-complaint rate and [domain reputation](/tools/domain-reputation)** in Google Postmaster Tools, the closest thing to seeing what Gmail sees. - Bulk senders (over ~5,000 messages a day to Gmail) must meet [Google's sender requirements](/learning/google-is-making-email-sender-requirements-stricter-starting-nov-2025) or be filtered or rejected outright. - The **Promotions tab is not spam**. It is a category, and mail there is still delivered. Chasing it can hurt more than it helps. ## How do I know it is Gmail filtering and not a bounce? Gmail filtering and a bounce look similar from the sender's side but mean different things. Start by separating the three outcomes: - **Filtered to Spam**: the message was *accepted* by Gmail and delivered, just to the Spam folder. Your logs show a successful delivery (a `250` response). The only way to confirm is to check a real Gmail recipient's Spam folder or send a test to your own Gmail account. - **Sorted into a tab**: the message reached the inbox but under **Promotions** or **Updates**. This is categorization, not filtering, and it is normal for marketing and transactional mail. - **Rejected**: Gmail refused the message with a `550-5.7.x` error and your mail server logged a bounce. That is not filtering; it is a hard block, usually for failed authentication or a bad reputation. Our guide on [why Gmail rejects emails with a 550 error](/learning/smtp-error-codes/550-5-7-26) covers that path. If your logs show delivery but recipients cannot find the mail, you have a filtering problem. If your logs show a bounce, you have a rejection problem. The rest of this guide is about filtering. ## Why is Gmail sending my emails to spam? Gmail's spam filter weighs three families of signal, and a weakness in any one can push you to the Spam folder: 1. **Authentication.** If Gmail cannot verify that you are authorized to send for your domain, it distrusts the message. You need SPF *or* DKIM to pass **and align** with your `From:` domain, plus a DMARC record. A message that fails all authentication is a prime spam candidate, and it is the most common fixable cause. 2. **Reputation.** Every sending domain and IP carries a reputation score with Gmail based on past behavior: complaint rates, spam-trap hits, and how much of your mail users delete unread. New or dormant domains have *no* reputation, which Gmail treats cautiously until you build one by [warming up the domain](/learning/how-do-you-warm-up-a-new-sending-domain-safely). 3. **Engagement and content.** If recipients rarely open your mail, mark it as spam, or you send to addresses that no longer exist, Gmail learns your mail is unwanted. Spam-trigger content (deceptive subject lines, link shorteners, mismatched display names) compounds it. The order matters: fix authentication first because it is binary and within your control, then reputation and engagement, which take time. When the symptom affects a sending stream rather than one message, the [Gmail spam filter sender guide](/learning/gmail-spam-filter) orders DNS, delivered-header, Postmaster, and same-path retest evidence without claiming to expose Google's private classifier. ## How do I check what Gmail sees about my domain? Two tools show you Gmail's own view, and you should use both: - **Google Postmaster Tools.** Register and verify your sending domain at [postmaster.google.com](https://postmaster.google.com), and after a day or two of volume it reports your **domain reputation**, **IP reputation**, **spam-complaint rate**, and **authentication pass rates** for SPF, DKIM, and DMARC. A "Low" or "Bad" reputation, or a spam rate creeping toward Google's 0.3% ceiling, tells you exactly why you are being filtered. - **The received message headers.** Send a test to a Gmail account you control, open the message, and choose "Show original." Read the `Authentication-Results` line: `spf=pass`, `dkim=pass`, and `dmarc=pass` are what you want. Our [Email Header Analyzer](/tools/email-header-analyzer) parses that header for you, and [why Gmail reports an SPF error](/learning/why-does-gmail-report-an-spf-error) covers the most common failure. Between the two, Postmaster Tools tells you *whether* Gmail trusts you and the headers tell you *why* a specific message passed or failed. ## What are Gmail's requirements for senders? Since early 2024 Gmail has enforced a baseline for anyone sending in volume, and meeting it is no longer optional: - **Authenticate every message** with SPF and DKIM, and publish a **DMARC** record (at minimum `p=none`) that aligns with your `From:` domain. - **Keep spam complaints low**. Google's guidance is to stay under a **0.3%** user-reported spam rate, and ideally below 0.1%. - **Support one-click unsubscribe** (the `List-Unsubscribe` header) on bulk marketing mail. - **Send from a domain with valid forward and reverse DNS** (a PTR record) on your sending IP. Bulk senders (roughly 5,000+ messages a day to Gmail addresses) that miss these are filtered to spam or rejected. Smaller senders are held to a softer version of the same bar. You can see the official list on [Google's Email sender guidelines](https://support.google.com/mail/answer/81126). Run the [Email Security Score](/tools/email-security-score) to check where your domain stands against them in one pass. ## Common issues with Gmail filtering ### My email authenticates but still goes to spam Passing SPF and DKIM is necessary, not sufficient. If your **domain reputation** is low (because of past complaints, a spam-trap hit, or a cold domain) Gmail can filter authenticated mail anyway. Check Postmaster Tools for reputation, prune invalid addresses from your list, and give a cold domain time to warm. Authentication opens the door; reputation decides which folder you land in. ### Only some recipients see my mail in spam Gmail personalizes filtering. A recipient who has never interacted with you, or who once deleted your mail unread, may see it filtered while an engaged recipient gets it in the inbox. This is expected. The fix is list-level, not per-recipient: improve overall engagement, remove chronically unengaged contacts, and never buy lists. ### My mail lands in the Promotions tab, not Spam That is categorization, not filtering, the message *was* delivered to the inbox. Gmail sorts bulk, image-heavy, or marketing-shaped mail into [the Promotions tab](/learning/why-emails-land-in-gmail-promotions-tab) by design. For genuine one-to-one and transactional mail, plain-text-leaning formatting and a clean sending reputation help it reach the primary tab, but you cannot force a category. ### Gmail suddenly started filtering mail that used to deliver A sudden change usually means a reputation event: a spike in complaints, a compromised account sending spam from your domain, or a new sending service you added without authenticating it. Check Postmaster Tools for a reputation drop and audit every service that sends as your domain. A single unauthenticated stream can drag the whole domain down. ## Sources and further reading - [Google: Email sender guidelines](https://support.google.com/mail/answer/81126) - [Google: Get started with Postmaster Tools](https://support.google.com/mail/answer/9981691) - [Microsoft: Email authentication in Microsoft 365](https://learn.microsoft.com/en-us/defender-office-365/email-authentication-about), for the Outlook side of the same checks ## Frequently asked questions ### Can Gmail filter my emails even if I am not a spammer? Yes. Gmail filters on measurable signals, not intent. A legitimate sender with a cold domain, a missing DMARC record, or a list full of dead addresses can be filtered exactly like a spammer. The signals are what you fix. ### How long does it take to recover Gmail deliverability? Authentication fixes take effect as soon as DNS propagates, usually hours. Reputation recovery is slower: expect one to several weeks of consistent, low-complaint sending before Postmaster Tools shows the reputation climbing back. ### Does buying Google Workspace stop Gmail from filtering my outbound mail? No. Workspace is your own mailbox; it does not change how *other* Gmail recipients' filters judge your mail. You still need proper authentication and a healthy reputation to reach Gmail inboxes you send to. ### Will a DMARC record alone fix Gmail filtering? DMARC is required and it helps by proving alignment, but on its own it does not guarantee inbox placement. It works alongside SPF, DKIM, reputation, and engagement: [DMARC stops spoofing](/learning/does-dmarc-stop-phishing) of your domain, which protects reputation, but it is one part of the picture. ## Where Palisade fits Most Gmail filtering traces back to an authentication or alignment gap on one of the domains or services you send from, and those are easy to miss when mail is spread across a CRM, a help desk, and a marketing platform. Palisade deploys and monitors SPF, DKIM, and DMARC across every sending source, reads your aggregate DMARC reports to catch a stream that is failing or unsigned, and flags reputation-damaging misconfigurations before Gmail acts on them. Start with the [Email Security Score](/tools/email-security-score) to see what Gmail sees about your domain today. ## Related reading - [Why are my emails landing in spam and how can I fix it?](/learning/why-do-your-emails-go-to-spam-and-how-can-you-fix-it) - [Why is my email going to spam in Outlook but not Gmail?](/learning/why-is-my-email-going-to-spam-in-outlook-but-not-gmail) - [Why am I not receiving emails? How to troubleshoot](/learning/why-am-i-not-receiving-emails-how-to-troubleshoot) --- # What is an email spam bot and how do you stop one? Canonical: https://www.palisade.email/learning/what-is-an-email-spam-bot > An email spam bot harvests addresses and sends spam at scale, often forging your domain to do it. How botnets work, and what DMARC enforcement stops. An email spam bot is automated software that harvests email addresses and sends unsolicited mail at scale, with no human typing each message. Spammers run these bots (often thousands of infected machines working together as a botnet) to scrape addresses from the web and data breaches, then blast out spam, [phishing](/learning/what-is-phishing), and malware faster and cheaper than any person could. Spam bots matter to you in two ways: they fill *your* inbox with junk, and they can forge *your* domain to send spam to everyone else, torching your sending reputation. The good news is that the second problem, the one that actually damages your business, is fixable with email authentication. ## Quick takeaways - A spam bot is automated software that **collects addresses and sends bulk spam** without human effort, usually as part of a botnet of compromised computers. - Bots harvest your address by **scraping websites, buying breach dumps, and guessing** common names at your domain. - The bigger risk is a bot **spoofing your domain** to send spam as you, which burns your reputation and lands your real mail in spam. - [DMARC](/learning/does-dmarc-stop-phishing) at an enforcement policy is what stops bots from forging your domain, backed by [SPF](/learning/what-is-spf) and [DKIM](/learning/what-is-dkim). - Reducing spam *you receive* and stopping spam *sent as you* are two different jobs. This guide covers both. ## How does an email spam bot work? Spam bots automate the whole spam lifecycle, which is why spam is so cheap to produce: 1. **Harvesting.** The bot builds a target list. It crawls web pages, forums, and social profiles for anything shaped like `name@domain`, buys or downloads addresses exposed in [data breaches](/learning/is-have-i-been-pwned-safe-to-use), and runs *dictionary attacks*: guessing common local parts like `info@`, `sales@`, or `john@` against a domain to see which do not bounce. 2. **Distribution.** To avoid being blocked, spammers rarely send from one machine. They use a **botnet**, a network of malware-infected computers and servers, so the spam originates from thousands of IPs at once, spreading the volume and dodging simple rate limits. 3. **Forgery.** To slip past filters and trick recipients, the bot forges the `From:` address, often impersonating a trusted brand or a domain that has no protection. This is [email spoofing](/learning/what-is-email-spoofing-and-how-can-you-prevent-it), and an unprotected domain is an easy target. The economics are brutal: because sending costs almost nothing, a response rate of a fraction of a percent still turns a profit, so bots send in the millions. ## How do spam bots get my email address? Your address ends up on a bot's list through a handful of predictable routes: - **Web scraping.** A `mailto:` link or plain-text address on a website, forum post, or public directory. - **Data breaches.** When a service you use is breached, address lists are traded and reused for years. - **Dictionary and brute-force guessing.** Bots try common mailbox names against your domain; role addresses like `admin@` and `support@` are guessed first. - **Malware and contact-list theft.** A bot on someone else's infected machine reads their contacts, and yours is in them. You cannot un-harvest an address, which is why the defensive focus shifts to filtering what reaches you and, more importantly, stopping bots from *using your domain*. ## Why should a spam bot spoofing my domain worry me? Because it damages you even though the spam never touches your own network. When a bot forges your domain in the `From:` address and sends spam or phishing to the world: - **Your domain's reputation drops.** Recipients and mailbox providers see spam "from you," complaints rise, and your domain can land on a [blocklist](/learning/why-do-your-emails-go-to-spam-and-how-can-you-fix-it), so your *legitimate* mail starts going to spam. - **Your brand and customers get scammed.** Forged mail that looks like it comes from you is the engine behind [business email compromise](/learning/what-is-the-complete-guide-to-business-email-compromise-bec-attacks-in-2025) and brand-impersonation phishing. - **You may never see it.** The spam goes to third parties, so the first sign is often a spike in bounce-backs or a customer asking why you emailed them a fake invoice. This is the part of the spam-bot problem that is squarely within your control, and email authentication is how you take it back. ## How do I stop a spam bot from sending as my domain? You cannot stop a bot from *trying* to forge your address, but you can make receivers reject the forgery. Three DNS records, working together, do this: - **SPF** lists the servers authorized to send for your domain, so a bot sending from a random botnet IP fails the check. - **DKIM** cryptographically signs your real mail; a bot cannot reproduce the signature. - **DMARC** ties them together and tells receivers what to do with mail that fails. At an enforcement policy of [`p=quarantine`](/learning/glossary/dmarc-p-quarantine) or `p=reject`, it instructs them to junk or drop the forgery outright. The catch is that DMARC only protects you at enforcement. A record stuck at `p=none` monitors but blocks nothing, which is exactly [why spoofed mail still passes](/learning/why-do-phishing-emails-pass-spf-and-dkim) for many domains. Check where your domain stands with the [Email Security Score](/tools/email-security-score) or the [DMARC checker](/tools/dmarc). ## Common issues with stopping spam bots ### I set up DMARC but spam is still sent as my domain A DMARC record at `p=none` takes no action; it only reports. Bots keep forging your domain and receivers keep accepting the mail because you have not [told them to reject it](/learning/glossary/dmarc-p-reject). Move to `p=quarantine` and then `p=reject` once your reports confirm all your legitimate senders pass, and the forgeries start getting blocked. ### I still receive spam even after protecting my own domain Authentication stops bots forging *your* domain; it does not stop mail bots send from *their* domains. For inbound spam, lean on your mailbox provider's filtering, never reply or click unsubscribe on obvious spam (it confirms your address is live), and see [how to prevent spam email](/learning/what-is-spam-email-and-how-to-prevent-it) for practical filtering steps. ### Bots keep hitting role addresses like info@ and sales@ Dictionary attacks target predictable mailboxes, so those addresses attract the most spam. You cannot retire them if customers use them, but strong inbound filtering, rate limiting, and CAPTCHA on any web form that feeds them reduces the automated abuse. Publishing addresses as images or contact forms rather than plain `mailto:` links slows harvesting. ### My newsletter signup is being flooded with fake addresses That is a spam bot abusing your form to inflate your list or trigger confirmation emails at others (a "list bombing" attack). Add CAPTCHA, require double opt-in confirmation, and rate-limit submissions per IP so a bot cannot submit thousands of addresses. If the abused workflow is a Google Form, follow the evidence-first checks in [Google Forms spam](/learning/google-forms-spam). ## Frequently asked questions ### Is an email spam bot the same as a botnet? Not quite. A botnet is the network of infected machines; a spam bot is the software that harvests addresses and sends the spam. Spammers commonly run their spam-bot software *across* a botnet to distribute the sending and evade blocks. ### Can I find out if a bot is spoofing my domain? Yes. That is what DMARC aggregate reports are for. Once you publish a DMARC record with a reporting address, mailbox providers send you daily summaries showing every source sending as your domain, including the unauthorized ones. ### Does unsubscribing from spam stop the bot? No. On genuine spam, the unsubscribe link often just confirms your address is monitored, inviting more. Only use unsubscribe on legitimate mail you once opted into; report the rest as spam. ### Will DMARC stop me receiving spam? No. DMARC protects your domain from being *forged*, which stops spam sent as you. It does not filter the spam that arrives in your inbox; that is your mailbox provider's spam filter's job. ## Where Palisade fits Stopping a spam bot from abusing your domain means getting SPF, DKIM, and DMARC right across every service that sends as you, then moving DMARC to enforcement without breaking legitimate mail, the step most domains stall on. Palisade deploys those records, reads the DMARC reports to show you exactly which sources (including spam bots) are sending as your domain, and carries the policy safely from `p=none` to `p=reject`, with you approving each step. See where your domain stands with the [Email Security Score](/tools/email-security-score). ## Related reading - [What is email spoofing and how can you prevent it?](/learning/what-is-email-spoofing-and-how-can-you-prevent-it) - [What is spam email and how to prevent it?](/learning/what-is-spam-email-and-how-to-prevent-it) - [Does DMARC stop phishing?](/learning/does-dmarc-stop-phishing) --- # Phishing-resistant MFA: does it stop device code phishing? Canonical: https://www.palisade.email/learning/phishing-resistant-mfa > Phishing-resistant MFA (FIDO2/WebAuthn, PKI) blocks proxy phishing by binding to a site's origin, but it does not stop device code phishing. Here's why. Phishing-resistant MFA is a class of multi-factor authentication (FIDO2/WebAuthn security keys and passkeys, and PKI smart cards) that cannot be relayed through a fake login page, because the credential is cryptographically bound to the real site's web address. It defeats the adversary-in-the-middle proxy phishing that steals one-time codes and push approvals. But it does **not** stop device code phishing, because in that attack the victim signs in on the *genuine* provider page. The phishing-resistant check passes exactly as designed, and the attacker simply collects the resulting tokens. Closing that gap needs a policy control, not a stronger authenticator. ## Quick takeaways - Phishing-resistant MFA means **FIDO2/WebAuthn** (security keys, passkeys) or **PKI** (PIV/CAC smart cards), the only two forms [CISA](https://www.cisa.gov/sites/default/files/publications/fact-sheet-implementing-phishing-resistant-mfa-508c.pdf) counts as phishing-resistant. - It works by **origin binding**: the authenticator signs a challenge tied to the site's exact domain, so a proxy on a lookalike domain gets nothing usable. - SMS codes, authenticator-app TOTP, and push approvals are **not** phishing-resistant. All can be relayed by an adversary-in-the-middle kit. - Phishing-resistant MFA stops credential-relay (AiTM) phishing, but **not device code phishing**, because the victim authenticates on the real page and only *approves* an attacker-started session. - The fix for device code phishing is a **Conditional Access policy** that blocks the device code flow, not a different authenticator. ## What is phishing-resistant MFA? Phishing-resistant MFA is multi-factor authentication that an attacker cannot capture and replay by tricking the user into entering it on a fake page. The [US cybersecurity agency CISA names exactly two implementations](https://www.cisa.gov/sites/default/files/publications/fact-sheet-implementing-phishing-resistant-mfa-508c.pdf) that clear the bar: - **FIDO2/WebAuthn**: hardware security keys (like a YubiKey) and passkeys, built on an open standard from the FIDO Alliance and the W3C. - **PKI-based authentication**: smart cards such as the PIV and CAC cards government agencies issue. Everything else people call "MFA" falls short of *phishing-resistant*. A one-time code from SMS or an authenticator app, a push notification you approve, a magic link, a security question. Each can be handed to an attacker, either by a user typing it into a convincing fake page or by an adversary-in-the-middle relaying it in real time. Those methods still beat a password alone, and number matching blunts push-fatigue attacks, but none of them are phishing-*resistant*. For how the tiers compare and where each belongs, see which MFA types MSPs should deploy. ## Why is FIDO2/WebAuthn phishing-resistant? The defining property is **origin binding**. When you register a passkey or security key with a site, the authenticator generates a key pair that is scoped to that site's origin, its exact domain. At sign-in, the browser hands the authenticator a challenge along with the origin it is actually talking to, and the authenticator will only produce a signature if that origin matches the one the key was registered for. That single check is what breaks proxy phishing. In an adversary-in-the-middle attack, the victim lands on `login.micros0ft-verify.com`, which silently relays every request to the real Microsoft page and passes responses back. With a TOTP code or a push approval, the relay works: the victim completes MFA on the real service *through* the proxy, and the attacker captures the resulting session cookie. A FIDO2 authenticator refuses to sign, because the origin it sees is the attacker's domain, not the real one. There is no code to phish and no approval to relay, the [authentication cannot be forwarded](/learning/why-do-phishing-emails-pass-spf-and-dkim) to a domain it was not registered against. This is why passkeys are the recommended defense against credential theft, and why they also limit the blast radius when a [password is reused or leaked](/learning/threats): there is no shared secret to steal in the first place. ## Does phishing-resistant MFA stop device code phishing? No, and this is the gap most rollouts miss. Device code phishing abuses the OAuth 2.0 **device authorization grant** (RFC 8628), a legitimate flow built for input-constrained gadgets like smart TVs and conference-room devices that cannot show a full browser. The flow is simple: a device shows a short user code and a URL, and you approve it from your phone or laptop. An attacker turns that into a trap. They start a device code request themselves, receive a real user code and the genuine verification URL from the provider, and send both to the victim, often disguised as an IT prompt, sometimes delivered by [QR-code phishing](/learning/what-is-quishing-qr-code-phishing). The victim opens the *authentic* provider page, enters the code, and signs in. Here is the crucial part: **the sign-in is real**, so a passkey or security key works perfectly and the phishing-resistant check passes. Once the victim consents, the provider issues access and refresh tokens, to the attacker, who has been polling the token endpoint the whole time. In some cases they register a device to capture a long-lived Primary Refresh Token and stay in for [months](/learning/device-code-flow-exploitation). Origin binding provides no protection here because the attacker never proxied the login. The victim was on the correct domain with the correct credential; they just approved a session someone else initiated. Phishing-resistant MFA is answering "is this the right user on the right site?", and the honest answer is yes. The abuse lives one layer up, in the flow itself. The same blind spot applies to consent phishing, where a user grants a malicious OAuth app permissions with a fully valid, phishing-resistant login. ## How do you defend against device code phishing? Because a stronger authenticator does not close this route, the defense is a policy control that stops the flow from being available at all: - **Block the device code flow with Conditional Access.** In Microsoft Entra, an [authentication-flows Conditional Access policy can block the device code flow](https://learn.microsoft.com/en-us/entra/identity/conditional-access/policy-block-authentication-flows) outright. Microsoft's guidance is to block it wherever possible and grant narrow, account-based exceptions only for the shared-device resource accounts that genuinely need it. - **Scope exceptions tightly.** If some conference-room or IoT devices require device code sign-in, allow it only for those specific service accounts and, where possible, only from managed devices, not as a tenant-wide default. - **Alert on device code sign-ins.** Treat interactive device code authentications by ordinary user accounts as suspicious. A finance or admin user completing a device code flow is a strong signal worth investigating. - **Train for the specific lure.** The tell is being asked to enter a code you did not request into a real Microsoft or Google page. Teach users that a legitimate service never sends *them* a device code to approve on someone else's behalf. This is the same "authenticated does not mean safe" gap behind [ghost phishing and other DMARC-evading techniques](/learning/what-is-ghost-phishing). ## Frequently asked questions ### Are passkeys and security keys the same thing? Both are FIDO2/WebAuthn credentials, so both are phishing-resistant. A security key is a physical device you carry (like a YubiKey); a passkey is a FIDO credential synced or stored on a phone or laptop. The origin-binding protection is identical. The difference is portability and recovery, not resistance. ### Is Microsoft Authenticator with number matching phishing-resistant? No. Number matching stops push-fatigue attacks, where a user blindly approves a flood of prompts, but the approval can still be relayed by an adversary-in-the-middle proxy. CISA classifies app-based push, even with number matching, as MFA that is *not* phishing-resistant. ### If phishing-resistant MFA can be bypassed, is it still worth deploying? Yes. It eliminates the most common and scalable attack (adversary-in-the-middle credential and session theft) which no other authenticator type fully stops. Device code and consent phishing are narrower, require a policy control you can apply centrally, and are far easier to detect. Phishing-resistant MFA plus a device-code block covers both. ### Does phishing-resistant MFA protect against a compromised session token? No. Once a valid token or session cookie exists, MFA has already happened. Token theft (including the device code case) is handled by shortening token lifetimes, binding tokens to devices, and revoking sessions on suspicious activity, not by the authenticator. ## Where Palisade fits Palisade does not manage your MFA, but it closes the email side of the same impersonation problem: it deploys SPF, DKIM, and DMARC, moves your domains to enforcement, and reads the aggregate reports so attackers cannot forge your exact domain to deliver the lures (the fake IT prompts and code requests) that start attacks like these. Pair phishing-resistant MFA and a device-code Conditional Access block with a locked-down sending domain, and check where your domain stands today with the [Email Security Score](/tools/email-security-score). ## Related reading - Which MFA types should MSPs use to protect clients? - [How can attackers exploit OAuth device code login?](/learning/device-code-flow-exploitation) - [What is ghost phishing and can DMARC stop it?](/learning/what-is-ghost-phishing) --- # What is a domain's DMARC policy? Canonical: https://www.palisade.email/learning/domain-s-dmarc-policy > A domain's DMARC policy is the p tag in its DNS record. It requests how receivers handle messages that fail DMARC for the domain: none, quarantine, or. A domain's DMARC policy is the requested handling for messages that use its visible From domain but fail DMARC. The domain owner publishes that request in a DNS TXT record, usually at `_dmarc.example.com`. The `p` tag can request `none`, `quarantine`, or `reject`. Receiving systems make their own final decisions, so the published policy does not prove a particular message was rejected, delivered, or placed in an inbox. ## Quick takeaways - The `p` tag contains the DMARC policy requested by the domain owner. - `p=none` requests no specific handling for DMARC failures. - `p=quarantine` requests suspicious treatment for DMARC failures. - `p=reject` requests that receivers reject messages that fail DMARC. - A receiver can apply its own local policy when handling a failing message. - A DMARC record lookup shows published DNS, not the result for an individual email. ## How a domain's DMARC policy works [RFC 9989 defines DMARC policy records](https://www.rfc-editor.org/rfc/rfc9989.html) as DNS records through which a domain owner communicates requested handling for mail that fails DMARC evaluation. DMARC evaluates the visible Header From domain against SPF or DKIM authentication that also meets the relevant alignment rule. The policy takes effect only after DMARC fails. A valid SPF or DKIM result alone is not enough for DMARC when the authenticated domain does not align with the visible From domain. The `p` tag expresses the requested policy for the organizational domain: - `p=none` requests no specific handling action for a DMARC failure. - `p=quarantine` requests treatment as suspicious. - `p=reject` requests that a receiver reject the failing message. A receiving system decides how to apply the request. RFC 9989 permits receivers to use local policy, so `p=reject` is not evidence that every receiver rejects every failing message. It also does not guarantee inbox placement for messages that pass DMARC. For the broader protocol and alignment rules, see the [DMARC learning hub](/learning/dmarc). ![Record anatomy showing the DMARC version, requested policy, and aggregate-report destination in an illustrative TXT record](/images/editorial/domain-s-dmarc-policy/domain-s-dmarc-policy-record-anatomy.webp "1200x533") *Source: Palisade.* ## When the published policy changes Read the visible From domain before deciding which DMARC policy applies. A message from `alerts.yourdomain.com` can have a more specific DMARC record at `_dmarc.alerts.yourdomain.com`. If there is no usable record at that name, DMARC discovery can use the organizational domain's record, as specified in [RFC 9989 policy discovery rules](https://www.rfc-editor.org/rfc/rfc9989.html). The [`sp` tag](/learning/glossary/dmarc-sp) can request a separate policy for subdomains. When a record has no `sp` tag, the organizational domain's `p` value normally supplies the requested policy for subdomains. A subdomain with its own usable DMARC record can change the result. Use this decision rule: - If the visible From domain has its own usable DMARC record, read that record. - If it does not, identify the organizational domain and read its `p` value. - If the organizational-domain record contains `sp`, use that requested policy for the subdomain. - If `sp` is absent, use the record's `p` value as the requested subdomain policy. The policy record can also request aggregate feedback with `rua`. An `rua` address does not prove that reports are arriving, being parsed, or acted on. [DMARC policy for subdomains](/learning/dmarc-policy-for-subdomains) covers the subdomain case in more detail. ## Worked DMARC policy example The following is illustrative only. Publish the report destination approved for your own domain and reporting service. ```text v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@yourdomain.com ``` This record has three relevant parts: - `v=DMARC1` identifies the record as a DMARC policy record. - `p=quarantine` requests suspicious treatment for messages that fail DMARC. - `rua=mailto:dmarc-reports@yourdomain.com` requests aggregate reports at that destination. The record belongs at the DMARC hostname, not at the bare domain: ```text Host: _dmarc.yourdomain.com Type: TXT Value: v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@yourdomain.com ``` > Do not copy another organization's report address, selector, or DNS value into your record. Use values generated and approved for your own domain. A policy record cannot identify every legitimate sender that uses the domain. Before moving toward `quarantine` or `reject`, validate important production paths with delivered-message authentication results and aggregate-report data. The narrower choice between enforcement requests is covered in [DMARC reject vs. quarantine](/resources-post/dmarc-reject-vs-quarantine-whats-the-difference). ## Check the policy with the evidence you have If you have a domain name, inspect its public DMARC TXT record first. Query `_dmarc.yourdomain.com` through authoritative DNS and at least one public resolver, then compare the answer with the intended record in your DNS change history or DNS-as-code source. A public lookup is the DNS layer of validation. It does not show whether an application is signing mail, whether SPF or DKIM aligns on a live message, or how a receiver handled that message. For those questions, inspect a delivered message's authentication results, then review DMARC aggregate reports after data accumulates. [Check the published DMARC record](/tools/dmarc) If the record says `p=none`, do not assume enforcement is active. If it says `p=quarantine` or `p=reject`, do not assume every sender is ready. The record is the domain owner's request. Real message headers and aggregate reports show whether the production sending paths meet DMARC. ## Keep policy changes tied to sender evidence A one-time DNS lookup cannot reveal which production sources later fail alignment, whether DNS drifts, or whether a new sender begins using the domain. Palisade is agentic DMARC software that analyzes DMARC aggregate-report data, identifies sending sources and authentication or alignment issues, and creates prioritized remediation tickets. It can propose the next policy step when the evidence indicates readiness, while a human reviews the evidence and applies the DNS change. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=dmarc_policy&utm_content=domain-s-dmarc-policy) Palisade does not autonomously change the DMARC policy, prove every future message will authenticate, or determine a receiver's private delivery decision. ## Sources and further reading - [RFC 9989: Domain-based Message Authentication, Reporting, and Conformance](https://www.rfc-editor.org/rfc/rfc9989.html) - [Palisade DMARC checker](/tools/dmarc) - [DMARC policy for subdomains](/learning/dmarc-policy-for-subdomains) - [DMARC reject vs. quarantine](https://www.palisade.email/resources-post/dmarc-reject-vs-quarantine-whats-the-difference) ## Frequently asked questions ### How do I enable DMARC for my domain? Publish a DMARC TXT record at `_dmarc.yourdomain.com` with a valid `v=DMARC1` and `p` tag. Start by validating SPF and DKIM alignment for legitimate production senders, then use aggregate reports before requesting stronger handling with `quarantine` or `reject`. ### What does it mean if a domain doesn't have a DMARC policy? It means receivers cannot find a usable DMARC policy record through standard DMARC discovery for that domain. SPF or DKIM can still authenticate mail, but the domain is not publishing a DMARC handling request through a usable DMARC record. ### How do I check if DMARC is enabled for a domain? Look up the TXT record at `_dmarc.domain.example` and confirm it contains a usable DMARC record beginning with `v=DMARC1`. A public lookup confirms published DNS, but a delivered-message header is needed to confirm that a particular message passed or failed DMARC. ### Should the DMARC policy be enabled? Only after legitimate sending sources have been identified and their important message paths show aligned SPF or DKIM authentication. A stronger policy can protect the domain from unauthorized use, but publishing it before validating legitimate senders can disrupt wanted mail. ### Does `p=none` mean DMARC is disabled? No. `p=none` is a valid DMARC policy that requests no specific failure handling. It can still request aggregate reports through `rua`, which helps a domain owner inventory senders and prepare for stronger enforcement. ### Does `p=reject` guarantee that spoofed mail is blocked? No. `p=reject` asks receivers to reject messages that fail DMARC, but each receiver can apply its own local policy. DMARC also does not control messages that do not use the protected domain in the visible From field. --- # Why would an email bounce? Canonical: https://www.palisade.email/learning/why-would-an-email-bounce > Why would an email bounce? Preserve the original delivery notice, identify the sending path and provider, then use provider evidence to choose a repair. An email can appear to bounce when a delivery attempt produces a non-delivery notice, but the notice itself is the evidence needed to determine what happened. Do not guess from the word "bounce" alone. Preserve the original notice, identify the sending account and provider, and use the exact diagnostic text with that provider's current documentation before changing DNS, authentication, or recipient data. ## Quick takeaways - A bounce notice without its original diagnostic details does not establish a cause. - Preserve the complete notice and the message details before attempting a repair. - Do not treat an address-validation result as proof of what happened to an already sent message. - A public DNS or security check cannot prove a receiver's private delivery decision. - Unexpected notices for mail you did not send require evidence from the affected mail provider before you can distinguish possible causes. - Broader [email deliverability guidance](/email-deliverability) can help after the delivery notice identifies a deliverability-related issue. ## What does the failure mean? The supplied evidence does not include an official definition of a bounced email, a delivery-status notification, an SMTP response, or a provider bounce guide. It therefore cannot establish whether a particular notice is a delivery failure, what the failure means, or which system made the decision. The available address-validation source uses these result categories: ```text Deliverable, Undeliverable, Risky, or Unknown ``` Those categories are not a received bounce message. They describe verification outcomes, not the reason a specific sent message was not delivered. The same source lists the checks that may be involved in verification: ```text Syntax validation, domain / MX / DNS check, mailbox availability check ``` [Verifalia's email verification documentation](https://verifalia.com) supports using address verification before sending when that fits the sending workflow. It does not provide a diagnosis or repair for an already bounced message. ![Diagnostic flow showing preservation of the original delivery notice, identification of the sending provider, matching the exact provider documentation, and same-path retesting](/images/editorial/why-would-an-email-bounce/why-would-an-email-bounce-diagnostic-flow.webp "1200x829") *Source: Palisade.* ## What usually causes it? ### The original delivery notice is missing or incomplete Without the received notice and its diagnostic information, the cause is unknown. The supplied materials do not provide an approved mapping between generic bounce labels and a particular delivery failure. Start by locating the original notice in the mailbox that received it. Keep the full message available to the person handling the incident. A screenshot or a copied subject line may omit details that the sending provider needs to investigate. ### The sending path has not been identified A delivery notice may relate to a particular account, application, mail service, recipient, or message path. The supplied evidence does not document how any provider classifies these outcomes, so it is not safe to infer the cause from the sender name, recipient domain, or timing alone. Record which account sent the original message, which service submitted it, the approximate send time, and the intended recipient. These are incident details to provide to the relevant provider. They are not proof of a cause by themselves. ### A pre-send address result is being confused with delivery evidence Address verification can report an address as deliverable, undeliverable, risky, or unknown, according to [Verifalia's published result categories](https://verifalia.com). That does not establish why an already sent message produced a non-delivery notice. Use a verification result only for the purpose documented by the service. Do not use it to override the evidence in the original delivery notice. ### A temporary provider problem may be suspected but is not established Google's supplied Help Center guidance says: > You can check for outages and downtime on the Google Workspace Status Dashboard That guidance supports checking the [Google Workspace Status Dashboard](https://support.google.com) for possible temporary Google-product problems. It does not diagnose a particular bounce, identify a repair, or show that Google caused the notice. ## How do I diagnose the failure? ### 1. Preserve the original delivery notice Save the complete notice before changing the recipient address, sender configuration, DNS, or message content. Keep the notice associated with the message that triggered it. Record the sending account, sending service, intended recipient, approximate timestamp, and whether the message was sent by a person or an application. Redact private addresses and message content before sharing evidence outside the authorized team. ### 2. Identify the provider responsible for the sending path Determine which service submitted the original message. Use the account's sent-mail history, the application's delivery logs, or the provider's own delivery view where available. Do not assume that the visible From address identifies the sending provider. The supplied evidence does not support a universal method for identifying the responsible system, so use the records available for the exact message. ### 3. Match the notice to the provider's current documentation Search the sending provider's official documentation using the exact diagnostic text from the original notice. If the provider documents that exact message, follow only the repair and validation steps it specifies. If no provider documentation exists for the exact notice, treat the cause as unresolved. Escalate it through the provider's support or mail-trace process with the redacted original evidence rather than applying a generic bounce remedy. ### 4. Separate recipient data from public domain configuration If the provider's documented evidence points to recipient-address quality before a new send, an address-verification service may be relevant. [Verifalia describes syntax, domain, MX, DNS, and mailbox-availability checks](https://verifalia.com), but its published material does not diagnose the earlier message. If evidence instead points to public DNS or email-authentication configuration, keep that branch separate from recipient validation. Do not change a DMARC policy to suppress an unresolved delivery symptom. A policy change affects requested enforcement, not the underlying provider decision. ### 5. Keep the diagnostic boundary clear A public check can inspect public information, but it cannot prove the exact production sending path, continuous state, a receiver's private decision, or future placement. The related guide on [common email bounce messages](/learning/bounce-back-email) may be useful only when you have an exact message to compare against supported documentation. ## How do I fix it? ### Apply only the sending provider's documented repair The supplied evidence does not support a general repair sequence for bounced messages. Once the sending provider's official documentation identifies the observed diagnostic message, apply the narrowest repair it documents. > Do not change DNS records, authentication policy, recipient data, or sending configuration merely to test an unsupported theory. An unrelated change can interrupt legitimate mail and make the original evidence harder to interpret. Keep the repair scoped to the confirmed path. If the provider documentation does not identify the exact notice, do not present a guessed change as a fix. ### Use address verification before a future send when appropriate When the documented issue is limited to recipient-address quality and the sending workflow permits a pre-send check, address verification may help screen addresses before another attempt. [Verifalia's published checks](https://verifalia.com) include syntax, domain, MX, DNS, and mailbox availability. This action does not repair the original message or prove why it was not delivered. It changes pre-send validation only. ### Treat provider availability as a separate branch If the affected service is Google Workspace and there is reason to investigate a possible temporary Google-product problem, check the [Google Workspace Status Dashboard](https://support.google.com). The supplied guidance does not establish a connection between a status event and the notice in hand. Do not treat a status check as confirmation of a bounce cause. Retain the original notice and use the provider's incident or support process if the exact issue remains unresolved. ## How do I validate the repair? Repeat the same approved sending path only after the responsible provider's documentation identifies a repair. Use a newly sent test message and preserve the resulting delivery evidence. Check the applicable layers independently: - DNS: confirm any documented public DNS change through the authoritative server and at least one public resolver. - Vendor: confirm the sending provider's current status or verification result for the relevant configuration. - Message: inspect the delivered or returned evidence from the same production path. - DMARC: review aggregate reports after data accumulates when the confirmed issue involves DMARC authentication or alignment. A passing public DNS check is not proof that the sending application used the expected configuration. A successful test to one recipient also does not prove future delivery decisions at every receiver. ## Check public domain posture only when the evidence points there If provider evidence identifies a possible public DNS or email-authentication configuration issue, inspect the domain with the [email security score tool](/tools/email-security-score) before making a DNS change. [Inspect the domain's public email-security posture](/tools/email-security-score) A public domain check cannot diagnose a recipient-address issue, prove why one receiver returned a notice, repair the message path, or guarantee future delivery. ## Sources and further reading - [Verifalia email verification](https://verifalia.com) - [Google Workspace Help Center](https://support.google.com) - [Palisade email deliverability learning hub](/email-deliverability) - [Palisade email security score tool](/tools/email-security-score) ## Frequently asked questions ### How do I fix a bounced email? Only after the original delivery notice and the sending provider's documentation identify the exact issue. The supplied evidence supports pre-send address verification, but it does not support diagnosing or repairing an already bounced message. ### What are the signs that your email has been hacked? The supplied evidence does not document account-compromise indicators or a way to distinguish compromise from spoofing. Preserve the unexpected notice and investigate through the affected provider's security and mail-trace processes. ### Why am I getting bounced emails that I didn't send? The supplied evidence does not establish a cause for unexpected non-delivery notices. Do not infer account compromise, spoofing, forwarding, or a recipient-side issue without the original notice and provider-specific evidence. ### What does it mean when an email is bounced? The supplied evidence does not provide an official bounce or delivery-status definition. It means the notice needs to be examined with the sending provider's documentation before a cause can be stated. ### Can email validation explain a bounced message? No. Address verification can provide pre-send results such as Deliverable, Undeliverable, Risky, or Unknown, but it does not explain why a specific earlier message produced a notice. --- # Bounce-back email: how to read the error and fix the cause Canonical: https://www.palisade.email/learning/bounce-back-email > Bounce-back email errors identify a delivery failure. Read the SMTP status, repair the confirmed cause, and retest the same sending path now. A bounce-back email is a delivery-status notification that reports an SMTP delivery failure or delay. Read the original notification before changing DNS, sender settings, or recipient data. Its status code, diagnostic text, recipient, and remote mail server show whether the next action belongs with the recipient address, sending system, DNS, authentication, or the receiving provider. When the immediate question is which envelope return path receives the delivery notice, see [how to identify a bounce email address](/learning/bounce-email-address) before changing a sender configuration. ## Quick takeaways - A bounce-back email can report either a temporary delivery problem or a permanent failure. - The SMTP reply class matters: `4xx` indicates a transient condition, while `5xx` indicates a permanent failure for that delivery attempt. - A `5.1.1` status commonly points to a recipient-address problem, but the full diagnostic text and recipient system still matter. - A public DNS or authentication check cannot validate a private recipient mailbox or explain every receiver rejection. - Retest with a new message through the same application, sender domain, route, and recipient provider after a repair. - Do not loosen a DMARC policy to hide a bounce. A policy change affects requested enforcement, not the underlying delivery failure. ## What does the failure mean? A delivery-status notification, sometimes called an NDR, is evidence from a mail system about one message attempt. [RFC 3463 defines enhanced mail-system status codes](https://www.rfc-editor.org/info/rfc3463/), while [RFC 5321 defines SMTP reply classes](https://www.rfc-editor.org/rfc/rfc5321.html). The first digit distinguishes transient `4xx` responses from permanent `5xx` responses. This redacted delivery-status notification has a permanent reply and an enhanced recipient-address status: ```text Final-Recipient: rfc822; recipient@example.net Action: failed Status: 5.1.1 Remote-MTA: dns; mx.example.net Diagnostic-Code: smtp; 550 5.1.1 Recipient address rejected ``` The notification proves that the reporting system recorded a failed attempt to `recipient@example.net` and received the stated SMTP diagnostic from `mx.example.net`. It does not, by itself, prove why that recipient address was rejected. The recipient organization, its mail provider, or its mailbox configuration may hold details that are not exposed in the notification. A useful first classification is: - `4xx`: the receiving system says the condition may be temporary. Preserve the notification and retry only within your normal sending controls. - `5xx`: the receiving system rejected that attempt as permanent. Inspect the enhanced status and diagnostic text before retrying. - `x.1.x`: the status category concerns addressing or mailbox status. - `x.7.x`: the status category concerns security or policy status. The exact mapping still depends on the receiving system's diagnostic text. ![Decision flow for reading a bounce-back email by SMTP reply class, enhanced status, and the system that controls the repair](/images/editorial/bounce-back-email/bounce-back-email-diagnostic-flow.webp "1200x829") *Source: Palisade.* For a focused explanation of temporary and permanent outcomes, see [soft bounce vs hard bounce email](/learning/soft-bounce-vs-hard-bounce-email). ## What usually causes it? ### The recipient address or mailbox cannot accept mail A `5.1.1` enhanced status identifies an addressing or mailbox-status category under RFC 3463. The recipient address may be misspelled, removed, disabled, or unavailable under the recipient organization's rules. The exact string `Recipient address rejected` does not disclose which of those conditions applies. Treat any conclusion beyond the displayed evidence as an inference. Confirm the address through an approved recipient contact or the recipient organization's directory, not by repeated automated retries. ### The sending application used the wrong recipient data The application, CRM, form, or list source may contain an old address, an unintended alias, or a malformed address. This is more likely when the same recipient fails from one application but succeeds from another approved sender. Compare the `Final-Recipient` field in the delivery-status notification with the address stored in the sending application. Do not use a displayed name as evidence that the SMTP envelope recipient was correct. ### The recipient domain has a DNS or MX delivery problem If the notification identifies a recipient domain that cannot be resolved or lacks a usable mail route, the failure belongs to domain DNS or recipient mail routing. A missing MX record can affect delivery, though [SMTP permits a sender to use an address record when no MX record exists](https://www.rfc-editor.org/rfc/rfc5321.html#section-5.1). This differs from a mailbox rejection. The sending system may have reached the recipient domain's mail server before that server rejected the address. ### A receiving provider rejected sender authentication or policy An `x.7.x` enhanced status can indicate a security or policy condition. The receiver's diagnostic text may point to sender authentication, message policy, reputation, or another local rule. [Gmail's bounced and rejected email guidance](https://support.google.com/mail/answer/6596?hl=en) directs senders to use the returned error details when identifying the reason for rejection. Do not infer that every `x.7.x` response is a DMARC failure. Use the actual diagnostic text, the delivered-message headers when available, and the receiving provider's documented guidance. ### A temporary receiving-system condition delayed delivery A `4xx` response may result from a temporary recipient-system condition, rate limit, or other transient constraint. RFC 5321 distinguishes these temporary failures from permanent `5xx` failures. Your sending service's retry behavior and logs are the evidence for whether later attempts succeeded. Do not convert a temporary response into a permanent recipient-data repair unless later evidence supports it. ## How do I diagnose the failure? ![Five-step diagnostic sequence for a bounce-back email, from preserving the delivery-status notification to separating public configuration from message evidence](/images/editorial/bounce-back-email/bounce-back-email-diagnostic-steps.webp "1200x813") *Source: Palisade.* ### 1. Preserve the original delivery-status notification Save the unaltered notification and the original message identifier before editing recipient data or changing sender settings. Record these four fields: - `Final-Recipient` - `Status` - `Remote-MTA` - `Diagnostic-Code` Also record the sending application, visible From domain, envelope sender if available, timestamp, recipient provider, and route used. Redact recipient information before sharing the notification outside the team. ### 2. Classify the SMTP reply before retrying Read the first digit in the SMTP code. A `4xx` response calls for controlled retry behavior and provider-specific investigation. A `5xx` response calls for a targeted repair before another production attempt. Then read the enhanced status as a category, not as a complete diagnosis. For example, `5.1.1` narrows the issue toward recipient addressing. It does not establish whether the sender typed the address incorrectly or the recipient organization disabled the mailbox. ### 3. Identify who controls the next action Use the notification to assign ownership: - A recipient-address error belongs first with the recipient data owner or recipient organization. - A sender application or routing error belongs with the team operating that sending path. - A recipient-domain DNS or MX problem belongs with the recipient domain's DNS or mail administrator. - A sender authentication or policy diagnostic belongs with the sender-domain owner and the receiving provider's documented requirements. - A temporary `4xx` response belongs with the sending service's retry process and, when necessary, the receiving provider. [Microsoft's non-delivery details report documentation](https://learn.microsoft.com/en-us/exchange/monitoring/mail-flow-reports/mfr-non-delivery-details-report) shows how Exchange Online exposes delivery-failure details for message tracing. Use the provider dashboard or message-trace evidence when it is the system that reported the failure. ### 4. Inspect the same production path A test from a personal mailbox does not validate a failure from an application, CRM, transactional service, or corporate relay. Send a controlled message from the same application, using the same sender domain, route, and content type. For a possible recipient-address issue, use one approved corrected address or confirm the existing address through the recipient. For a suspected sender-domain issue, preserve the received message source and its trusted `Authentication-Results` fields. RFC 8601 describes the header field that reports message-authentication results and its trust boundary. ### 5. Separate public configuration from message evidence A public check can help only after the delivery-status notification points to a sender-domain authentication or configuration question. It cannot replace the original SMTP diagnostic or recipient-provider evidence. A sender-domain failure is different from a recipient-routing failure. For example, [an email rejected per DMARC policy](/learning/email-rejected-per-dmarc-policy) requires message-authentication and alignment evidence, not only a generic bounce classification. ## How do I fix it? ### Correct confirmed recipient data When the notification and an approved source confirm that the address is wrong, update the address in the system that sent the message. Remove or suppress a known-invalid address from future automated sends according to your organization's retention and consent rules. > Do not repeatedly send to a rejected recipient address to test whether it has recovered. Repeated attempts can create unnecessary traffic and do not prove that the address is valid. This repair changes recipient data. It does not change DNS, authentication, or DMARC enforcement. ### Repair the sending application's route or envelope data When logs show that the application constructed the wrong envelope recipient or used an unintended outbound route, correct that specific configuration. Retain the previous setting and record a rollback path before deploying the change. Confirm the repair with a new message from the affected application. A test from a different mail client does not prove that the application now uses the corrected route. ### Escalate recipient-domain DNS and MX failures to the domain owner When the evidence shows a recipient-domain routing issue, provide the recipient administrator with the exact domain, timestamp, remote-server result, and diagnostic text. Avoid publishing or guessing replacement MX hosts. The recipient administrator must repair its own DNS or mail-routing condition. Changing your sender's DMARC policy does not repair the recipient domain's route. ### Repair confirmed sender-domain authentication or public configuration issues When the DSN and provider guidance identify a sender-domain authentication or public-configuration question, inspect the published SPF, DKIM, and DMARC posture before changing records. ## Check sender-domain email security evidence If the bounce points to a sender-domain authentication or public-configuration issue, use the [Email Security Score](/tools/email-security-score) to inspect published domain evidence before proposing a DNS change. Compare the result with the failed message's trusted authentication results and the receiving provider's diagnostic. [Check sender-domain email security](/tools/email-security-score) A public score cannot validate a recipient address, reproduce a receiver's private policy, inspect the exact production message path, or explain every individual rejection. Palisade does not change DNS, authorize a sender, override a recipient policy, or guarantee delivery or inbox placement. ### Leave temporary failures to controlled retry handling For confirmed `4xx` conditions, use the retry behavior configured in the sending platform and investigate persistent failures with the receiving provider or recipient administrator. Do not recast a transient condition as a permanent hard bounce until later attempts or provider evidence establish that outcome. This action affects delivery attempts. It does not repair recipient data or sender authentication by itself. ## How do I validate the repair? Send a new test through the same production application, with the same sender domain, outbound route, recipient-provider type, and relevant content. Confirm that the sending platform records acceptance or delivery according to its normal telemetry. Validate each applicable layer: - DNS: for a sender-domain repair, check the published record through the authoritative DNS path and a public resolver. - Vendor: confirm the sending platform or provider shows the intended authentication or route status. - Message: inspect the newly delivered message's trusted `Authentication-Results` when the repair involved authentication. - DMARC: after aggregate reports accumulate, confirm that the relevant sending source authenticates and aligns as expected. A successful message to one test mailbox does not prove every recipient provider will make the same decision. Keep the original notification, corrected evidence, test result, and rollback details with the incident record. For broader operational context, see the [email deliverability learning hub](/email-deliverability). ## Sources and further reading - [RFC 3463: Enhanced Mail System Status Codes](https://www.rfc-editor.org/info/rfc3463/) - [RFC 5321: Simple Mail Transfer Protocol](https://www.rfc-editor.org/rfc/rfc5321.html) - [RFC 8601: Authentication-Results header field](https://datatracker.ietf.org/doc/html/rfc8601) - [Google Gmail Help: Fix bounced or rejected emails](https://support.google.com/mail/answer/6596?hl=en) - [Microsoft Learn: Non-delivery details report in Exchange Online](https://learn.microsoft.com/en-us/exchange/monitoring/mail-flow-reports/mfr-non-delivery-details-report) ## Frequently asked questions ### What is a bounce back email? A bounce-back email is a delivery-status notification reporting that a mail system could not deliver a message or has delayed delivery. It usually includes an SMTP reply, enhanced status code, recipient information, and diagnostic text that help identify the failure. ### How do you say an email bounced back? You can say, "The email bounced," "The message was rejected," or "We received a delivery-status notification." Use the actual SMTP diagnostic in an incident ticket because "bounced" alone does not identify whether the issue was temporary, recipient-specific, routing-related, or policy-related. ### How do I send a bounce back email? Only a mail system should generate a delivery-status notification in response to a delivery attempt. If you need to notify someone manually, send a normal message that includes the relevant redacted error details. Do not imitate a delivery-status notification or use it to contact an unintended recipient. ### How long until an email bounces back? It depends on the SMTP response and the sending provider's retry policy. A `5xx` rejection can be reported immediately for that attempt, while a `4xx` temporary failure may be retried before the sender reports final non-delivery. Check the sending provider's logs for the actual retry timeline. ### Can a DMARC record cause a bounce back email? Yes, if the receiving provider rejects a message because it fails the sender domain's published DMARC policy or the provider's authentication requirements. Confirm that cause with the full diagnostic text and the received message's trusted authentication results. A bounce alone does not prove DMARC caused it. --- # Business email compromise vs phishing Canonical: https://www.palisade.email/learning/business-email-compromise-vs-phishing > Business email compromise vs phishing: classify a suspicious request by its identity and payment or access objective before acting, using the message. Business email compromise and phishing should be assessed by the evidence in the message, the identity it claims, and the action it requests. Do not treat either label as a finding on its own. A suspicious email can involve impersonation, a credential request, a payment request, or several of these at once. The safe operational response is to preserve the evidence and verify the request through a trusted, separate channel. ## Quick takeaways - A threat label does not prove who sent a message or whether a requested transaction is legitimate. - A claimed executive, vendor, customer, or employee identity needs independent verification before a sensitive action. - A request for credentials, MFA approval, payment details, or a bank-account change needs evidence from the exact message and business process. - A reply to the suspicious email thread is not an independent verification channel. - Email authentication results can help assess domain authorization, but they do not prove the sender's real-world identity or payment instructions. - Preserve the original message, headers, request details, and verification record before changing accounts or payment data. ## How the distinction works in practice Use the terms only after you have separated the message's identity evidence from its requested outcome. Identity evidence includes the visible From address, reply address, display name, sending domain, message headers, and the result of a delivered-message authentication check. These details can show that a message uses an unexpected domain or that a domain did not authenticate as expected. They do not establish that a payment request, bank-account change, or executive instruction is genuine. Outcome evidence includes what the recipient is being asked to do. Examples include entering credentials, approving an MFA prompt, opening a file, changing a vendor record, sending a payment, or disclosing information. The requested action determines which internal owner and verification process should be involved. This distinction matters because one message can contain more than one signal. A request may claim to come from a known person while also directing the recipient to a credential page. Another may contain no link or attachment but request a change to payment instructions. Record the observable facts first. Apply a threat label only when your incident process has enough evidence to support it. For broader context on controls and response planning, see the [email security learning hub](/learning). A separate guide on [how business email compromise can threaten a business](/learning/what-is-the-complete-guide-to-business-email-compromise-bec-attacks-in-2025) covers the operational consequences that can follow a fraudulent request. ## When the answer changes The same apparent message type can require different handling depending on the requested action and the evidence available. If the message asks for credentials, an MFA approval, or access to a service, treat identity and account-access evidence as the immediate priority. Preserve the full message and use the organization's approved account-recovery or security-reporting path. Do not enter credentials or approve an unexpected authentication request while the message remains unverified. If the message asks for a payment, a bank-account update, gift-card purchase, invoice change, or release of sensitive data, treat the transaction as the immediate priority. Stop the requested change until the requester is verified through contact information obtained from a trusted system, contract record, vendor master record, or previously known phone number. If the message appears to come from a known domain, do not treat domain familiarity as transaction approval. An authenticated message can still contain a request that conflicts with the established payment process. Conversely, an unauthenticated message is an important signal, but it does not by itself identify the person or system that sent it. Use this decision rule: - When the evidence concerns the sender's domain or message path, inspect the message and authentication evidence. - When the evidence concerns access, credentials, or payment authority, verify the request through a separate trusted business channel. - When both conditions apply, preserve the message and involve both the security owner and the business owner before any action. > Do not change payment instructions, release funds, reset access, or disclose sensitive information based only on an email thread. Use a contact route that was not supplied by the message under review. ## A two-axis classifier for suspicious requests The following classifier is an explanatory aid, not an official incident taxonomy. It helps route a message to the right verification step before someone acts. ![Two-axis classifier separating identity and access evidence from payment and business-task evidence for suspicious email requests](/images/editorial/business-email-compromise-vs-phishing/business-email-compromise-vs-phishing-classifier.webp "1200x676") *Source: Palisade.* ```text Illustrative only: classify the evidence before acting Identity or access signal: - Unexpected sender domain - Credential request - MFA approval request - Reply address differs from known contact details Payment or business-task signal: - Request to change bank details - Request to pay an invoice - Request to release confidential information - Request that bypasses the normal approval path Decision: - Identity or access signal only: preserve the message and use the security response path. - Payment or business-task signal only: verify through a trusted business contact route. - Both signals: stop the action and involve security plus the relevant business owner. ``` A worked example can make the boundary clearer. Assume a recipient receives an invoice-related email from a familiar display name. The email asks that future payments use new banking details and includes a phone number for confirmation. The payment-task signal is the instruction to alter payment details. The claimed identity is not verified by the display name, the email thread, or the contact number included in the message. The correct next step is to use approved vendor contact details held outside that message to confirm the change. Preserve the original email and provide it to the security team if the request cannot be verified. A different example is an email that directs a recipient to sign in to view a document. The immediate evidence object is the link destination, the message headers, and the requested credential action. Do not use the link to investigate. Preserve the message and inspect it through the approved security process. The [anti-phishing software comparison guide](/learning/anti-phishing-software) can help when the unresolved task is evaluating protection tools rather than classifying one message. ## What to do with the evidence you have Start with the evidence available to the recipient. - If you have the full suspicious message, preserve the original message and its headers. Record the visible From address, reply address, recipient, subject, requested action, links, attachments, and the time received. - If the message requests a payment or vendor-data change, pause the transaction and contact the known requester through an independently sourced channel. Record who verified the request and which trusted contact record was used. - If the message requests credentials or account access, do not interact with its links or attachments. Use the organization's established security-reporting and account-support process. - If you only have a sending domain, inspect its published posture with a public checker. That can help identify published DNS controls, but it cannot prove the production message path, sender identity, receiver decision, or future delivery outcome. - If a real message was delivered, compare the authentication results in that exact message with the expected sending domain and approved service. A DNS record alone cannot prove that an application signed the message or used the expected return path. For a wider treatment of attack patterns and response planning, see the [business email compromise attacks guide](/learning/what-is-the-complete-guide-to-business-email-compromise-bec-attacks-in-2025). ## Check the email-security signals around the request If you need a high-level view of a domain's publicly visible email-security posture, use Palisade's [email security score tool](/tools/email-security-score) after preserving the suspicious message and pausing the requested action. [Check a domain's email-security score](/tools/email-security-score) A public domain check cannot determine whether a specific payment request is genuine, prove the sender's real-world identity, inspect a private mailbox decision, or replace verification through an approved business contact channel. ## Sources and further reading - [FBI Internet Crime Complaint Center](https://www.ic3.gov/) - [CISA phishing guidance](https://www.cisa.gov/topics/cyber-threats-and-advisories/malware-phishing-and-ransomware) - [Palisade email security learning hub](/learning) ## Frequently asked questions ### What is a red flag for a business email compromise? A request to change payment details, release funds, disclose sensitive information, or bypass an established approval process is a red flag that needs independent verification. Treat the request as unverified until a trusted contact route confirms it. ### Who is liable for business email compromise? Liability cannot be determined from an email alone. It depends on the jurisdiction, contracts, payment method, parties involved, and the facts of the event. Preserve evidence and involve the appropriate legal, finance, insurance, and incident-response owners. ### What is an example of a business email compromise? An example is an email that appears to come from a vendor contact and asks an accounts-payable employee to use new bank details for future payments. The safe response is to pause the change and confirm it using contact information from a trusted vendor record rather than the email. ### How common is business email compromise? A current frequency claim needs a current primary-source report with a stated period, population, and measurement method. Do not use an unsourced number to decide whether a suspicious payment or access request needs verification. ### Does email authentication prove that a payment request is legitimate? No. Email authentication can provide evidence about domain authorization for a delivered message. It does not confirm the sender's real-world identity, authority to request a transaction, or the correctness of payment instructions. --- # DMARC reporting service: EasyDMARC vs PowerDMARC Canonical: https://www.palisade.email/learning/dmarc-reporting-service > DMARC reporting service comparison: assess EasyDMARC and PowerDMARC by reporting, support, tenant model, DNS controls, and key open questions. Choose EasyDMARC if managed DMARC, SPF, and DKIM configuration support is central to the buying decision. Choose PowerDMARC if a partner needs a documented white-label, multi-tenant reporting model. Neither vendor should be selected on marketing position alone: verify the reporting scope, retention, pricing, support terms, tenancy, and who can make DNS changes before committing. ## Quick takeaways - EasyDMARC describes smart dashboards, simplified reporting, and managed services for DMARC, SPF, and DKIM configuration through enforcement. - EasyDMARC says its managed-services offering includes support from "A dedicated DMARC Engineer supports you every step of the way." - PowerDMARC documents analyzer setup that includes a DMARC policy and aggregate reporting, followed by one to two weeks of visibility and analysis. - PowerDMARC documents a white-label, multi-tenant partner model for reselling services under a partner's branding. - Current pricing, report retention, API access, export options, support SLAs, and plan limits remain open questions for both vendors. - A public DMARC record check can inspect published DNS, but it cannot replace ongoing aggregate-report analysis or prove a production sender's behavior. ## Who this comparison is for This comparison is for an IT team or MSP choosing a DMARC reporting service for one or more domains. The buyer may already publish a DMARC record and need help turning aggregate-report data into an operational view of sending sources, authentication status, and policy progress. A reporting service has more than one job. It may collect and display DMARC reporting data, support a policy rollout, provide managed assistance, or provide a tenant model for an MSP. Those jobs affect the right choice. Read [what DMARC is](/learning/what-is-dmarc) before comparing services if the DMARC policy and reporting purpose are still unclear. A buyer who already has a record should also separate a DNS question from a reporting question. A public record lookup can show what is published today. It cannot show every sender that used the domain, prove a message passed DMARC, or establish future receiver placement. ## How the options were evaluated The criteria below were set before drawing a recommendation and checked against the vendors' public first-party pages on July 30, 2026. - Reporting position: What each vendor publicly says about DMARC reporting or analysis. - Operating model: Whether the documented offer emphasizes a managed service, a platform workflow, or a multi-tenant partner use case. - DNS and authentication scope: Whether the vendor publicly describes DMARC alone or related SPF, DKIM, MTA-STS, TLS-RPT, or BIMI services. - Support model: Whether the vendor publicly documents a named support resource. - Buyer controls: Whether pricing, retention, integrations, exports, data residency, APIs, and DNS-change authority are documented in the evidence reviewed. The comparison does not infer missing capabilities. If a vendor page does not document a feature, that feature remains an open question. This is a narrower companion to the broader [DMARC vendor comparisons](/compare) available for teams evaluating platform fit. The decision rule is an editorial inference from the documented positioning: choose only after the buyer verifies required reporting scope, tenancy model, support model, report retention, pricing, and DNS-change controls. A service can display useful reporting data and still be the wrong operating fit. ![DMARC reporting service selection checklist covering reporting scope, tenancy, support, retention, pricing, and DNS controls](/images/editorial/dmarc-reporting-service/dmarc-reporting-service-selection-checklist.webp "1200x582") *Source: Palisade.* ## EasyDMARC EasyDMARC publicly describes a platform with [smart dashboards and simplified reporting](https://easydmarc.com), alongside managed services for DMARC, SPF, and DKIM configuration through enforcement. That position fits a buyer who wants reporting and configuration support discussed together, rather than treating aggregate reports as a separate data feed. ![EasyDMARC public website showing its DMARC platform and managed-service positioning](/images/editorial/dmarc-reporting-service/dmarc-reporting-service-shot-1.webp "1600x900") *Source: [EasyDMARC homepage](https://easydmarc.com), checked 2026-07-30.* EasyDMARC also states: "A dedicated DMARC Engineer supports you every step of the way." That is evidence of a documented managed-service support position. It does not establish an SLA, onboarding timeline, availability by plan, or the exact work included. Its public EasySPF description says: "EasySPF eliminates issues like the 10 DNS lookup limit by dynamically flattening the record, converting domain includes into IP addresses." SPF flattening is adjacent to DMARC operations because SPF authentication and alignment can affect DMARC outcomes. The statement does not prove that every SPF configuration is suitable for flattening, or that a buyer can delegate DNS changes without reviewing the resulting record. - Best fit: Teams that want a vendor-documented combination of simplified reporting and managed DMARC, SPF, and DKIM configuration support. - Relevant evidence: [EasyDMARC's public platform description](https://easydmarc.com) describes smart dashboards, simplified reporting, managed services through enforcement, dedicated DMARC Engineer support, and EasySPF. - Tradeoff: The reviewed evidence does not establish current pricing, retention, API access, exports, data residency, plan limits, or support SLA terms. ## PowerDMARC PowerDMARC publicly describes an analyzer workflow that starts with configuring a domain, DMARC policy, and aggregate reporting. Its published process says: "Configure your domain, DMARC policy, and aggregate reporting" and then, "Over 1-2 weeks, you will get full visibility and analysis." That makes PowerDMARC relevant to a buyer whose evaluation starts with an analyzer workflow and an expected period for report data to accumulate. ![PowerDMARC public website showing its DMARC analyzer and reporting-service positioning](/images/editorial/dmarc-reporting-service/dmarc-reporting-service-shot-2.png "1600x900") *Source: [PowerDMARC homepage](https://powerdmarc.com), checked 2026-07-30.* PowerDMARC also lists "DMARC Aggregate and Forensic Reporting" and describes monitoring DMARC data in its analyzer dashboard. This is vendor-specific product positioning. It does not establish report retention, the report formats available to each plan, or how a particular receiving provider supplies failure-report data. For MSPs, PowerDMARC publicly describes a white-label, multi-tenant platform with a partnership model that can resell services under the partner's branding. It also lists hosted DMARC analysis with hosted SPF, DKIM, MTA-STS, TLS-RPT, and BIMI services. The reviewed material does not establish that every hosted service is included in every plan. - Best fit: MSPs or partners that specifically need a vendor-documented white-label, multi-tenant model for DMARC reporting services. - Relevant evidence: [PowerDMARC's public platform description](https://powerdmarc.com) describes analyzer setup, DMARC aggregate and forensic reporting, dashboard monitoring, multi-tenant white-label partnership positioning, and hosted authentication services. - Tradeoff: The reviewed evidence does not establish current pricing, retention, API access, export options, data residency, support SLAs, or entitlement by plan. ## Palisade Palisade cannot be assessed against EasyDMARC and PowerDMARC on the same factual criteria from the evidence available for this comparison. No current Palisade product documentation, pricing evidence, reporting workflow, tenant model, integration evidence, or operational-service detail was supplied for verification. - Best fit: Open question. Verify the current product workflow against the team's reporting, remediation, tenancy, and DNS-control requirements. - Relevant evidence: No Palisade-specific product evidence was available for this dated comparison. - Tradeoff: A buyer cannot make a defensible feature, pricing, retention, or workflow comparison until current Palisade documentation or a product demonstration answers those questions. ## How to choose Use the reporting service decision after establishing what problem the service must solve. If the team needs managed help for DMARC, SPF, and DKIM configuration through enforcement, EasyDMARC's documented managed-service position is the closer fit. If the buyer is an MSP that needs a documented white-label, multi-tenant partner model, PowerDMARC is the closer fit. Before purchasing, require written answers for each item below. - Confirm whether the service receives and displays the report types the team needs. - Confirm report retention, data residency, exports, APIs, and access controls. - Confirm which users or vendor personnel can request, prepare, or apply DNS changes. - Confirm support coverage, onboarding work, escalation terms, and service-level commitments. - Confirm pricing, domain limits, tenant limits, and any paid add-ons. - Confirm the reporting view with real aggregate-report data from a controlled production domain. > Do not move a DMARC policy to enforcement based only on a dashboard status. Validate the published DNS record, vendor status, a delivered message from each production path, and aggregate-report data after it accumulates. ```yaml option: EasyDMARC checked_on: 2026-07-30 best_fit: Managed DMARC, SPF, and DKIM configuration support with simplified reporting verified_evidence: - Smart dashboards and simplified reporting are publicly described - Managed services through enforcement are publicly described - Dedicated DMARC Engineer support is publicly described open_question: - Current pricing, retention, API access, exports, data residency, plan limits, and SLA terms ``` ```yaml option: PowerDMARC checked_on: 2026-07-30 best_fit: Analyzer-led reporting with a documented white-label multi-tenant partner model verified_evidence: - Analyzer setup includes DMARC policy and aggregate reporting - Aggregate and forensic reporting are publicly listed - White-label multi-tenant partner positioning is publicly described open_question: - Current pricing, retention, API access, exports, data residency, plan limits, and SLA terms ``` ```yaml option: Palisade checked_on: 2026-07-30 best_fit: Open question pending current product evidence verified_evidence: - No Palisade-specific reporting-service evidence was available for this comparison open_question: - Reporting workflow, pricing, retention, integrations, tenant model, support model, and DNS controls ``` ## Check the DMARC record before selecting a reporting service Inspect the current DMARC record before comparing reporting workflows. The result shows the public policy and reporting addresses that DNS publishes today, which helps frame the vendor questions around collection and rollout. [Check the DMARC record](/tools/dmarc) A record check cannot prove which production sources fail DMARC, show a service's retained report history, or control later DNS changes. Use [DMARC aggregate report format guidance](/learning/dmarc-aggregate-report-format) and the vendor's current documentation to evaluate the reporting workflow after the record check. If the buyer needs ongoing DMARC analysis across active sending sources, Palisade is positioned as DMARC software that analyzes DMARC aggregate-report data, identifies authentication or alignment issues, and creates prioritized remediation tickets. A human reviews the evidence and applies any DNS or policy change. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=tools_vendors_comparisons&utm_content=dmarc-reporting-service) ## Sources and further reading - [EasyDMARC](https://easydmarc.com) - [PowerDMARC](https://powerdmarc.com) ## Frequently asked questions ### What is the best DMARC reporting service? No single service is best for every buyer. EasyDMARC fits teams that prioritize its documented managed-service position for DMARC, SPF, and DKIM configuration. PowerDMARC fits partners that need its documented white-label, multi-tenant model. Verify retention, pricing, support, and DNS controls before selecting either service. ### Does EasyDMARC provide managed DMARC support? Yes. EasyDMARC publicly describes managed services for DMARC, SPF, and DKIM configuration through enforcement and states that "A dedicated DMARC Engineer supports you every step of the way." The reviewed evidence does not establish the current SLA, plan eligibility, or exact scope of that support. ### Does PowerDMARC support MSPs? Yes. PowerDMARC publicly describes a white-label, multi-tenant partnership model that allows partners to resell services with their own branding. Confirm current partner terms, tenant limits, support coverage, and pricing directly with PowerDMARC before making an MSP purchasing decision. ### Can a DMARC checker replace a DMARC reporting service? No. A DMARC checker can inspect the public DNS record at the time of the lookup. It cannot collect and analyze aggregate reports over time, identify every production sending source, or prove how a vendor's reporting workflow handles data. ### Should a team enforce DMARC after a dashboard shows a healthy status? No. A dashboard indicator alone does not prove every production message path authenticates correctly. Validate the DNS record, the vendor's status, a real delivered message from each production path, and DMARC aggregate-report data before changing the DMARC policy. --- # How to enable phishing and malware protection in Google Workspace Canonical: https://www.palisade.email/learning/enable-phishing-and-malware-protection > Enable phishing and malware protection in Google Workspace by configuring Gmail Safety controls, actions, organizational units, and message checks. Enable phishing and malware protection in Google Workspace from the Google Admin console under **Apps > Google Workspace > Gmail > Safety**. Select the organizational unit that should receive the policy, configure the relevant phishing, malicious-link, attachment, spoofing, and authentication protections, then save and verify the applied scope. The available controls and actions are documented in Google's [advanced phishing and malware protection guidance](https://knowledge.workspace.google.com/admin/gmail/advanced/advanced-phishing-and-malware-protection). Settings affect the selected Gmail scope. They do not guarantee that every malicious message will be detected. ## Quick takeaways - Gmail Safety settings can be applied to a selected organizational unit instead of every user in the Workspace account. - Google groups phishing, malicious-link, attachment, spoofing, and authentication-related protections in its advanced Gmail safety controls. - Choose an action that matches the risk and business impact of each protection, then test with approved, safe evidence. - A saved Admin console policy is different from proof that a real message was filtered as expected. - Sender authentication and inbound phishing protection solve different parts of email security. - Review the Gmail setting scope after changes so child organizational units do not inherit an unintended policy. ## What should I check before configuring Google Workspace? Confirm that the mailboxes in scope receive mail through Gmail in the Google Workspace account you will administer. These Gmail protections apply to inbound mail handling. They do not configure a marketing platform, transactional email service, or another mailbox provider that receives mail elsewhere. You need access to the Google Admin console, permission to manage Gmail settings, and a clear organizational-unit decision. Start with a written scope: the organizational unit, included users, any child organizational units, the business reason for a stricter or less strict action, and a test mailbox. Google documents the settings path and available protections in its [advanced phishing and malware protection documentation](https://knowledge.workspace.google.com/admin/gmail/advanced/advanced-phishing-and-malware-protection). The path in this guide was verified from that official documentation. Review the current console before making a change because Google can update labels and available choices. > Copy DNS values from the account and domain you are configuring. Do not publish selectors, targets, tokens, or hostnames from another account or from an online example. This workflow does not normally require publishing a DNS record. If you also change SPF, DKIM, or DMARC while investigating spoofed mail, treat those as separate changes with their own owner, approval, and message validation. Gmail filtering does not authenticate your organization's outbound domain. ## Which setup method should I use? Use a phased organizational-unit rollout when your account has different risk profiles or operational needs. For example, apply a proposed policy to a small pilot organizational unit, inspect the outcome with safe test messages and administrator evidence, then extend it after the team accepts the action behavior. Use a broader organizational-unit policy when the same protection and action are appropriate for all users covered by that unit. Do not assume that a parent setting is correct for every child unit. Confirm the scope shown in the Admin console before saving. Choose the action based on the consequence of a false positive. A stricter action can reduce exposure to suspicious mail, but it can also interrupt legitimate business messages. Google's documentation describes the protection groups and the actions available in the current Gmail Safety configuration. Preserve a change record with the prior setting, new setting, scope, approver, and test result. ![Decision flow for selecting Gmail Safety protection scope and validating a Google Workspace policy](/images/editorial/enable-phishing-and-malware-protection/enable-phishing-and-malware-protection-policy-flow.webp "1200x829") *Source: Palisade.* ## How do I configure phishing and malware protection in Google Workspace? ### 1. Open Gmail Safety settings Sign in to the Google Admin console and open **Apps > Google Workspace > Gmail > Safety**. Use Google's [advanced phishing and malware protection guide](https://knowledge.workspace.google.com/admin/gmail/advanced/advanced-phishing-and-malware-protection) to confirm the current path if the console layout differs from this wording. ![Google Workspace Help showing the Advanced phishing and malware protection guide and its protection categories](/images/editorial/enable-phishing-and-malware-protection/google-workspace-safety-guidance-overview.png "1200x1100") *Source: [Google Workspace Help: Advanced phishing and malware protection](https://knowledge.workspace.google.com/admin/gmail/advanced/advanced-phishing-and-malware-protection), captured from the live official documentation on August 10, 2026. This is Google's help interface and configuration guidance, not a view of your Admin console.* Record the selected organizational unit before changing any control. A policy applied to the wrong unit can leave intended recipients uncovered or affect users who were not in scope. ### 2. Select the organizational unit Choose the organizational unit for the mailboxes you are protecting. Review whether the setting inherits from a parent organizational unit or overrides it locally. If you need different treatment for executives, finance staff, shared mailboxes, or a pilot group, define the boundary before changing Gmail Safety controls. Avoid creating exceptions without an owner and review date. ### 3. Configure phishing, link, attachment, spoofing, and authentication protections Open each relevant protection group and select the action documented for that control. Google's current guidance covers protections for phishing and malware, suspicious links, attachments, spoofed messages, and unauthenticated messages. Use the specific evidence that caused the review to decide which setting needs adjustment. A suspicious attachment problem does not automatically justify changing a spoofing control. A sender-authentication failure may need a DMARC, SPF, or DKIM investigation rather than an inbox-filtering exception. Document the setting in an operational format such as this: ```yaml scope: "Finance organizational unit" change: "Gmail Safety protection action" reason: "Approved response to observed mail risk" owner: "Workspace administrator" evidence: "Redacted message details and administrator review" test: "New safe test message to the scoped mailbox" rollback: "Restore the previous documented action" ``` Do not copy a policy choice from an online example without comparing it to your account's current control label, available action, and organizational-unit scope. ### 4. Save the policy and verify the applied scope Save the Gmail Safety setting. Return to the selected organizational unit and confirm that the intended protection is active there, rather than inherited from an unexpected parent policy. Google provides a separate [Gmail settings health monitoring workflow](https://knowledge.workspace.google.com/admin/security/monitor-the-health-of-your-gmail-settings) for reviewing the health of Gmail settings. Use it to identify settings that need administrator attention after the policy change. A visible setting is evidence that the console stored the policy. It is not message-level evidence that Gmail made the expected decision for a specific delivered message. ![Gmail Safety policy validation checklist for scope, saved action, test message, and administrator evidence](/images/editorial/enable-phishing-and-malware-protection/enable-phishing-and-malware-protection-validation-checklist.webp "1200x524") *Source: Palisade.* ### 5. Send a safe, real test message Send a newly created, safe test message to a mailbox in the affected organizational unit. Use a controlled test that your security team approves. Do not distribute live malware, credential-harvesting URLs, or harmful attachments to test a Gmail protection. Record the sender, recipient organizational unit, send time, expected result, observed result, and any relevant administrator evidence. If the result differs from the configured action, confirm the recipient's organizational unit and check for inherited or conflicting Gmail settings before changing the policy again. ## How does this setup affect DMARC? Google Workspace phishing and malware protections inspect inbound mail risk. DMARC evaluates whether a message's aligned SPF or DKIM authentication passes for the visible From domain. These controls can work together, but one does not replace the other. A message can pass DMARC and still contain a malicious link. A message can also fail DMARC because the sender configured authentication incorrectly, without proving that the message is malicious. [RFC 9989 defines DMARC alignment and evaluation](https://datatracker.ietf.org/doc/html/rfc9989). Use Palisade's [DMARC checker](/tools/dmarc) to inspect the published DMARC record for a sending domain involved in a spoofing investigation. A public DNS check cannot show the Gmail policy applied to a mailbox, prove a production message path, or reveal Gmail's decision for a future message. For the broader relationship between sender controls, user reporting, and incident handling, see [Palisade's email security guidance](/learning). The related guide to [preventing email spoofing](/learning/what-is-email-spoofing-and-how-can-you-prevent-it) explains why domain authentication still needs separate ownership. ## How do I validate the setup? ### Check public DNS If the incident includes a spoofed sender domain, inspect its published DMARC record with the [DMARC checker](/tools/dmarc). Compare the record with the domain you saw in the visible From field. Do not use this step as proof that Gmail Safety is enabled. Public DNS does not expose organizational-unit policy, inbox filtering decisions, or the sender's actual production configuration. ### Validate the vendor policy in Google Workspace Return to **Apps > Google Workspace > Gmail > Safety** and confirm the selected organizational unit, the saved action, and the inheritance state. Then review the relevant checks described in Google's [Gmail settings health monitoring documentation](https://knowledge.workspace.google.com/admin/security/monitor-the-health-of-your-gmail-settings). Keep a dated record of the setting and scope. This is the vendor layer of validation. ### Inspect a delivered message Inspect a newly delivered safe test message in the mailbox that belongs to the scoped organizational unit. Capture the observed inbox outcome and, where appropriate, redacted message headers. `Authentication-Results` is a receiver-added field. [RFC 8601 defines its syntax and trust boundary](https://www.rfc-editor.org/rfc/rfc8601.html). Do not treat a copied header from an untrusted source as proof of Gmail's decision. ### Review DMARC reports After DMARC aggregate reports accumulate, review how legitimate sending sources authenticate for your domain. DMARC reporting helps identify sources and alignment failures. It does not report every inbound phishing message that Gmail filtered. ## Troubleshooting ### The setting appears to affect the wrong users Check the organizational unit selected when the policy was saved and whether a parent policy is inherited. Compare the affected mailbox's assigned organizational unit with the scope shown in Gmail Safety. Correct the scope before adjusting the protection action. Keep the previous policy available as a rollback reference. ### Gmail Safety shows the correct policy but the test result differs Confirm that the test message reached a mailbox in the selected organizational unit and was sent after the setting was saved. Check for another Gmail policy that applies to the recipient. Use a new, approved safe test message. Do not use a real phishing payload to force a detection result. ### A legitimate sender is affected by a phishing or spoofing protection Preserve redacted message evidence, including the visible From domain and trusted authentication result where available. Determine whether the sender has an authentication issue, a changed sending path, or a legitimate message pattern that requires an approved exception. Do not broadly weaken Gmail Safety to accommodate one sender until the evidence identifies the relevant control and scope. ### DMARC passes but the message is still suspicious DMARC pass is authentication evidence, not proof that the content is safe. Review the message content, links, attachment behavior, and the Gmail Safety action separately. For a broader assessment of organizational controls, use Palisade's [email security score tool](/tools/email-security-score). Its result is a point-in-time assessment and cannot prove inbox filtering or user behavior. ### Users cannot find a phishing-reporting control A user's reporting option is separate from the administrator's Gmail Safety settings. Confirm your user-reporting process and train users to report suspicious mail through the approved channel. For a protection program that includes reporting and response, see [how to build an anti-phishing program](/learning/anti-phishing-program). ## Build the operating process around the Gmail policy The Gmail Safety configuration is one control in an anti-phishing program. After you verify the intended organizational-unit scope, define how users report suspicious mail, who investigates reports, how affected users are notified, and when the policy is reviewed after a false positive or incident. Read [how to build an anti-phishing program](/learning/anti-phishing-program) to connect the Google Workspace setting to reporting, incident response, and user training. Google Workspace protections reduce risk, but they do not guarantee detection of every malicious message or replace an incident-response process. ## Sources and further reading - [Google Workspace: Advanced phishing and malware protection](https://knowledge.workspace.google.com/admin/gmail/advanced/advanced-phishing-and-malware-protection) - [Google Workspace: Monitor the health of Gmail settings](https://knowledge.workspace.google.com/admin/security/monitor-the-health-of-your-gmail-settings) - [RFC 9989: Domain-based Message Authentication, Reporting, and Conformance](https://datatracker.ietf.org/doc/html/rfc9989) - [RFC 8601: Message Header Field for Indicating Message Authentication Status](https://www.rfc-editor.org/rfc/rfc8601.html) ## Frequently asked questions ### How do I turn on malware protection? Open **Apps > Google Workspace > Gmail > Safety** in the Google Admin console, select the intended organizational unit, configure the relevant advanced phishing and malware protection action, and save the setting. Then verify the scope and use an approved safe test message. A saved policy does not guarantee Gmail will detect every future malicious message. ### Where is my phishing button? The phishing-reporting option is a user-facing Gmail function, while phishing and malware protection settings are managed by administrators under **Apps > Google Workspace > Gmail > Safety**. If a user cannot find a reporting option, check the organization's reporting process and Gmail configuration rather than changing a Safety policy without evidence. ### Is it better to delete or report phishing? Yes, report suspected phishing through your organization's approved reporting channel before deleting it when reporting is safe and practical. Reporting gives the security team evidence to investigate and may help protect other recipients. Do not click links, open attachments, or reply to obtain more evidence. ### What should you never open in spam mail? Never open an attachment or follow a link in spam mail when you cannot independently verify the sender and expected content. A familiar display name is not enough. Use a known contact method to verify an unexpected request, especially one involving credentials, payment, or account access. ### Does Gmail phishing protection replace DMARC? No. Gmail phishing protection is an inbound mailbox protection control. DMARC checks whether aligned SPF or DKIM authentication passes for the visible From domain. Both can reduce different risks, but neither proves that every message is safe or that every future message will authenticate. --- # PowerDMARC review: fit, evidence gaps, and next steps Canonical: https://www.palisade.email/learning/powerdmarc-review > PowerDMARC review for IT teams and MSPs: verified workflows, multi-tenant claims, evidence gaps, and a practical vendor decision rule today. Choose PowerDMARC if a vendor-described multi-tenant, white-label DMARC service and hosted authentication controls are central to your requirements. Choose Palisade only after you validate its workflow against the same operational evidence. The available PowerDMARC evidence confirms its stated product scope, but it does not establish pricing, plan access, interface behavior, support terms, or comparative outcomes. ## Quick takeaways - PowerDMARC describes a four-stage process that starts with DMARC setup, analyzes mail over "1-2 weeks," then moves to `p=quarantine/reject`. - PowerDMARC says it provides DMARC aggregate and forensic reporting, header analysis, reputation analysis, DNS history, and Auto DNS Publishing. - PowerDMARC says its partner offering is a "multi-tenant platform" with white-label resale and billing-system connection options. - The supplied evidence does not verify PowerDMARC pricing, plan limits, contract terms, API access, integrations, or current dashboard paths. - A published DMARC record is useful buying evidence, but it does not prove how every production sender authenticates. - A vendor evaluation should separate public DNS evidence from reporting, remediation, approval, and operational workflow evidence. ## Who this comparison is for This review is for an IT team or MSP evaluating PowerDMARC as a possible DMARC-management provider. You may be deciding whether the vendor's documented reporting workflow, hosted authentication services, partner model, or language support match the way you operate. It is also for buyers who need to avoid turning a vendor homepage into a complete procurement decision. A product page can establish that a vendor describes a capability. It cannot establish that the capability is included in your intended plan, works in your environment, meets a service requirement, or produces a particular outcome. For a broader vendor-shortlisting framework, use the [Palisade comparison hub](/compare). Keep the evaluation focused on the evidence your team needs to approve a platform, rather than on a general impression of its feature list. ## How the options were evaluated The criteria below were fixed before drawing a recommendation and checked against the supplied first-party PowerDMARC product evidence on July 30, 2026. - Workflow fit: Whether the documented process matches your DMARC rollout and reporting needs. - MSP fit: Whether the vendor describes multi-tenant, resale, branding, and billing-related capabilities. - Authentication scope: Whether the vendor describes adjacent SPF, DKIM, MTA-STS, TLS-RPT, BIMI, or email-service-provider controls. - Evidence completeness: Whether current documentation establishes pricing, plan inclusion, interface behavior, support, API access, and operational limits. - Verification path: Whether a buyer can test public DNS claims and then validate production mail, vendor status, and DMARC reports separately. A documented capability is treated as vendor-described evidence, not independent proof of effectiveness. Missing documentation remains an open question. It does not prove that a feature is absent. A DMARC rollout also needs separate evidence at each layer. Check DNS through an authoritative answer and a public resolver. Check the vendor's current status. Send real production mail and inspect its headers. Then use aggregate reports after they accumulate. A green status indicator and a DNS lookup answer do not prove the exact production sending path is aligned. ![Decision flow for assessing a PowerDMARC evaluation, starting with public DMARC evidence and ending with plan and workflow questions](/images/editorial/powerdmarc-review/powerdmarc-review-decision-flow.webp "1200x829") *Source: Palisade.* ## PowerDMARC PowerDMARC presents a staged DMARC workflow. Its homepage says customers configure an analyzer and publish a DMARC record, analyze mail over "1-2 weeks," move to `p=quarantine/reject`, then operate with an enforced policy. That is a recognizable DMARC rollout sequence, but the supplied page does not document how the workflow appears in the current product interface or which plan includes each part. PowerDMARC also says its offering includes DMARC aggregate and forensic reporting, email-header analysis, domain-reputation analysis, a live threat map, DNS timeline, security-score history, and Auto DNS Publishing. These are [PowerDMARC's stated product capabilities](https://powerdmarc.com), checked July 30, 2026. Treat them as a shortlist signal, then ask the vendor to demonstrate the specific workflows your operators need. - Best fit: Buyers who specifically need a vendor-described DMARC platform with reporting and adjacent authentication services, especially MSPs evaluating a white-label, multi-tenant operating model. - Relevant evidence: PowerDMARC says its partner offering is a "multi-tenant platform" with white-label resale, plan customization, billing-system connection, and personalized branding. It also says the control panel supports "11 languages including Japanese, French, German, Italian, Dutch, and more." These are vendor statements, checked July 30, 2026, on the [PowerDMARC homepage](https://powerdmarc.com). - Tradeoff: Pricing, domain and user limits, retention, support terms, reseller terms, regional availability, API details, integrations, and current interface paths remain unverified in the supplied evidence. PowerDMARC advertises hosted SPF, DKIM, MTA-STS, TLS-RPT, BIMI, and email-service-provider compliance capabilities. Its hosted SPF description refers to "record flattening or SPF Macros" to stay under the lookup limit. That may matter when a buyer wants a single vendor to address related DNS controls, but it is not proof that a particular plan includes the service or that a hosted record will fit your sending architecture. > Do not replace an existing SPF record or change a DMARC policy during a vendor evaluation without confirming every authorized sender. A record that looks valid in DNS can still break mail when a production service is omitted or misaligned. The PowerDMARC homepage also advertises a "15-day trial." Trial eligibility, renewal terms, card requirements, feature access, and plan restrictions were not verified. Confirm those details directly with the vendor before treating the trial as a buying criterion. ## Palisade Palisade should be evaluated under the same criteria, but the supplied evidence does not include Palisade pricing, product documentation, authenticated interface evidence, support terms, integrations, reporting details, MSP workflow evidence, or outcome data. No claim about comparative capability, automation, or fit can be established from this evidence set. - Best fit: A buyer who has validated Palisade's current workflow against the same requirements used for PowerDMARC. - Relevant evidence: The first useful comparison input is the domain's published DMARC record. The [Palisade DMARC checker](/tools/dmarc) can inspect public DMARC DNS evidence for a domain. - Tradeoff: A public DMARC check does not show all production sending sources, prove message alignment, monitor future changes, or establish what either managed platform includes in a selected plan. Do not use a free DNS result as a substitute for a platform trial or a technical review. A published record may show `p=none`, `p=quarantine`, or `p=reject`, but it does not reveal the complete reporting workflow, delegated access model, remediation process, or contract boundary that your team needs. For adjacent context on reporting-focused vendor selection, see [DMARC reporting service: EasyDMARC vs PowerDMARC](/learning/dmarc-reporting-service). If your comparison also includes another traditional DMARC platform, the [dmarcian review](/learning/dmarcian-review) covers a separate vendor evaluation path. ## How to choose Choose PowerDMARC when your decision depends on its vendor-described multi-tenant, white-label partner model or its stated hosted authentication controls, and the vendor can verify the plan, workflow, support, and contractual details your organization requires. Keep Palisade in the evaluation when you want to compare it against the same evidence record. Do not choose either option until you can answer the open questions with current first-party documentation, a scoped demonstration, or a trial using a representative domain. Use this scorecard for each vendor discussion: ```yaml option: PowerDMARC checked_on: 2026-07-30 best_fit: "MSP or IT team assessing vendor-described multi-tenant DMARC and hosted authentication services" verified_evidence: - "Vendor describes a staged DMARC workflow with analysis over 1-2 weeks" - "Vendor describes reporting, header analysis, DNS timeline, and Auto DNS Publishing" - "Vendor describes a multi-tenant, white-label partner offering" open_question: - "Which plan includes the required capabilities, limits, support, retention, integrations, and reseller terms?" option: Palisade checked_on: 2026-07-30 best_fit: "Buyer who can validate Palisade against the same operational requirements" verified_evidence: - "A public DMARC record can be inspected with the Palisade DMARC checker" open_question: - "Current workflow, pricing, reporting, support, integrations, and MSP operating model were not evidenced for this review" ``` Before comparing demos, record the public DMARC baseline for one representative domain: ```text Host: _dmarc.yourdomain.com Record shape: v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com Purpose: Illustrative only. Use the record published for your own domain. ``` Then ask each vendor to show how it handles the same scenario: - Which sending sources appear after DMARC aggregate reports accumulate? - Which authentication or alignment issue becomes an actionable task? - Which user can review evidence and approve a DNS or policy change? - Which plan includes the reporting, delegation, retention, and support level you need? - Which evidence proves a production message from your exact sending path passes DMARC? ## Check the DMARC record before comparing platform workflows Start with the public record behind the vendor evaluation. Use the [DMARC checker](/tools/dmarc) to inspect the domain's currently published DMARC policy, then compare that output with a real message header and the platform's reporting view. [Check the DMARC record](/tools/dmarc) A public record check cannot prove which production sources still fail alignment, repair a sender configuration, monitor later DNS drift, or establish what PowerDMARC or Palisade will include in a plan. Start with Palisade when you want to evaluate its product workflow after collecting that domain-level baseline: [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=tools_vendors_comparisons&utm_content=powerdmarc-review). ## Sources and further reading - [PowerDMARC homepage and product claims](https://powerdmarc.com) - [Palisade DMARC checker](/tools/dmarc) ## Frequently asked questions ### Is PowerDMARC a good fit for MSPs? Only if its vendor-described partner model matches the MSP's commercial and operational requirements. PowerDMARC says its partner offering is a "multi-tenant platform" with white-label resale, plan customization, billing-system connection, and personalized branding. Confirm current reseller terms, limits, support, and plan access before choosing it. ### Does PowerDMARC offer DMARC reporting? Yes. PowerDMARC says its offering includes DMARC aggregate and forensic reporting. The supplied evidence does not verify reporting retention, export options, alert configuration, plan inclusion, or the current reporting interface. ### Does PowerDMARC support SPF, DKIM, BIMI, and MTA-STS? Yes, PowerDMARC advertises hosted SPF, DKIM, MTA-STS, TLS-RPT, BIMI, and email-service-provider compliance capabilities. Verify which controls are available on the intended plan and whether the resulting DNS design fits your existing senders before making changes. ### Does a published DMARC record prove a platform will work? No. A public DNS result proves only what the resolver can retrieve at that time. Validate the vendor's status, inspect headers from real production mail, and review DMARC aggregate-report data after it accumulates. ### Can a free DMARC checker replace a DMARC platform trial? No. A checker can inspect a domain's public DMARC record, which is useful baseline evidence. It cannot prove platform workflow, reporting access, retention, support, integrations, future monitoring, or how the platform handles your sending sources. ### Does PowerDMARC's advertised 15-day trial settle its pricing or plan fit? No. The homepage advertises a "15-day trial," but the supplied evidence does not verify eligibility, feature access, renewal terms, card requirements, pricing, or plan limits. Confirm those details with PowerDMARC before relying on the trial for procurement. --- # Spam vs phishing Canonical: https://www.palisade.email/learning/spam-vs-phishing > Spam vs phishing: spam is unsolicited bulk email, while phishing uses deception to steal information or prompt harmful action from recipients. Spam is unsolicited bulk messaging. Phishing is deceptive fraud that tries to obtain sensitive information or cause a harmful action. A message can be both when someone sends the same deceptive request to many recipients. Treat an unexpected message as phishing when it impersonates a trusted party or pressures you to sign in, pay, disclose information, open an attachment, or follow a link. ## Quick takeaways - Spam describes unsolicited bulk delivery, while phishing describes deception and fraudulent intent. - A bulk phishing campaign can be both spam and phishing. - A suspicious email is not safe because it resembles ordinary marketing junk mail. - Spoofing can support phishing by using a false identity, but spoofing and phishing are different classifications. - Report suspected phishing through the security process available to you instead of interacting with its links or attachments. - A public DNS check can inspect a managed domain's published controls, but it cannot classify one delivered message. ## How spam and phishing differ [NIST defines spam](https://csrc.nist.gov/glossary/term/spam) as unwanted electronic junk mail and unsolicited bulk messages. The term describes the delivery pattern: recipients did not request the messages, and the sender distributes them widely. [NIST defines phishing](https://csrc.nist.gov/glossary/term/phishing) as fraudulent solicitation that masquerades as a reputable entity to trick people into disclosing sensitive information. Phishing therefore turns on the message's deceptive request and claimed identity, not on how many people received it. Use those definitions for a practical distinction: - Spam is unsolicited bulk promotion or messaging that does not necessarily make a deceptive request. - Phishing is a deceptive message that seeks credentials, payment, sensitive data, or another unsafe action. - A false sender identity is a warning sign, but the key phishing question is what the recipient is being asked to do. For the operational effects of unwanted mail and inbox placement, see the [Palisade deliverability learning hub](/email-deliverability). If a legitimate sender's mail is being classified as junk, the causes differ from an inbound phishing investigation. New-domain mail can be marked as spam for reasons that do not establish phishing. For the adjacent identity question, whether a message fakes who it is from, makes a deceptive request, or both, see [spoofing vs phishing](/learning/phishing-vs-spoofing-whats-the-difference). ## When the classification changes Classify the message by purpose before volume. - If an unsolicited email promotes a product or service without a deceptive request, it is spam. - If it pretends to be a trusted organization or person and asks for credentials, money, sensitive information, or an unsafe action, it is phishing. - If a deceptive request is sent indiscriminately to many recipients, it is both spam and phishing. This is an inference from NIST's definitions of unsolicited bulk messaging and phishing, not a separate NIST category. - If the message claims to come from an organization you know, verify the request through a website, phone number, or contact method you already trust. > Do not use the link, phone number, or reply address supplied in a suspicious message to verify it. Use an independently known contact path. The [Federal Trade Commission's phishing guidance](https://consumer.ftc.gov/articles/how-recognize-and-avoid-phishing-scams) advises people not to click unexpected links or attachments, and to contact a company through a known good website or phone number when verification is needed. Authentication does not settle this classification. A message can pass SPF or DKIM and still contain a deceptive request or link. Conversely, an authentication failure is not by itself proof that a message is phishing. A domain operator investigating legitimate mail that lands in junk should use a delivery-focused path, such as [why emails go to spam in Gmail](/email-deliverability/why-are-my-emails-going-to-spam-in-gmail). ## A worked classification rule Use the observable request in the email to decide how it should be handled. This rule does not require you to prove who sent the message. ```text Illustrative classification rule Unsolicited bulk promotion with no deceptive request = spam False or misleading identity plus a request for credentials, money, sensitive information, a link click, attachment opening, or urgent action = phishing Deceptive request sent indiscriminately to many recipients = spam and phishing ``` ![Decision flow that separates unsolicited bulk spam, deceptive phishing, and campaigns that meet both definitions](/images/editorial/spam-vs-phishing/spam-vs-phishing-classification-flow.webp "1200x676") *Source: Palisade.* The decision rule is intentionally narrow. It does not identify the sender, determine whether a linked website is malicious, or replace an organization's incident-response process. It helps a recipient avoid treating deceptive mail as routine junk. ## What to do with the evidence you have If you only have the email, avoid its links, attachments, reply address, and requested payment or sign-in process. Report the message through your organization's security route or the reporting option offered by the mailbox service. Preserve only the redacted information your security team requests. If you manage the domain shown in the message, keep the message investigation separate from a domain-control review. Inspecting a domain's published DMARC, SPF, DKIM, and related DNS records can show which controls are visible publicly. It cannot reveal the specific message's headers, linked destination, sender intent, or the receiver's final decision. For legitimate mail sent through Microsoft services, see [how to stop emails going to spam in Outlook](/email-deliverability/how-to-stop-emails-going-to-spam-in-outlook). That is a deliverability question, not evidence that an unexpected inbound message is harmless. ## Check public controls for a domain you manage If the suspicious message uses a domain your team manages, use the [Email Security Score](/tools/email-security-score) to inspect its published email-security controls. This is useful after you have separated the suspicious-message report from the domain's DNS posture. [Check the domain's email security score](/tools/email-security-score) A public DNS check cannot classify an individual message as spam or phishing, inspect its headers or links, prove sender intent, or establish why a receiver accepted, rejected, or filtered it. ## Sources and further reading - [NIST CSRC glossary: spam](https://csrc.nist.gov/glossary/term/spam) - [NIST CSRC glossary: phishing](https://csrc.nist.gov/glossary/term/phishing) - [Federal Trade Commission: how to recognize and avoid phishing scams](https://consumer.ftc.gov/articles/how-recognize-and-avoid-phishing-scams) - [Palisade Email Security Score](/tools/email-security-score) ## Frequently asked questions ### Is phishing a type of spam? Only sometimes. Phishing describes deceptive fraud, while spam describes unsolicited bulk delivery. A targeted phishing message sent to one person may not be spam. An indiscriminate phishing campaign can fit both classifications. ### Is all spam harmless? No. Spam is a delivery and consent classification, not a safety verdict. Some spam may be unwanted promotion, while some bulk messages use deception and should be treated as phishing. ### Should you mark a phishing email as spam? No. Use the phishing-reporting process available through your organization or mailbox service. The [FTC recommends reporting phishing attempts](https://consumer.ftc.gov/articles/how-recognize-and-avoid-phishing-scams), because a deceptive message may imitate a trusted identity or target other recipients. ### Can spam filters stop phishing? No. Spam filters can keep many phishing emails out, but the [FTC notes that scammers keep trying to bypass filters](https://consumer.ftc.gov/articles/how-recognize-and-avoid-phishing-scams). A delivered email is not proof that its request is legitimate. ### How can you tell the difference between spam and phishing? Classify the message by purpose. Unsolicited bulk promotion is spam. A deceptive request for credentials, money, sensitive information, or an unsafe action is phishing. A bulk deceptive campaign can be both. --- # Valimail DMARC checker: what you can verify Canonical: https://www.palisade.email/learning/valimail-dmarc-checker > Valimail DMARC checker options help review domain visibility, but confirm current results, message evidence, enforcement, and reporting separately. Valimail offers a "Check My Domain" entry point, and its free Monitor account is described as providing unlimited domain visibility. Before treating a result as proof of DMARC protection or delivery, confirm what the current check actually evaluated, inspect a real delivered message, and review DMARC aggregate-report data. A public domain check is useful evidence, but it cannot show every production sending path or a receiver's private delivery decision. ## Quick takeaways - Valimail presents a "Check My Domain" action on its website. - Valimail describes Monitor as a free account with unlimited domain visibility. - A public DMARC check and a delivered-message check answer different questions. - A reported policy status does not prove that every sending service authenticates correctly. - Treat monitoring visibility and DMARC enforcement as separate operational states. - Do not change a DMARC policy based on one public lookup alone. ## What this tool checks Valimail's public site includes a [Check My Domain action](https://valimail.com), but the available public material does not document the current checker URL, required inputs, result labels, fields, resolver behavior, or retest behavior. That means a reader should not assume that a specific screen label means a domain is protected, compliant, or safe. Valimail describes its Monitor offering as "MONITOR (FREE)" and says users can "[get unlimited domain visibility, for free](https://valimail.com)." It also says Monitor identifies enforcement status across sending domains and turns raw IP data into DMARC reports. Those statements support a limited conclusion: Monitor is positioned for visibility into domains and DMARC reporting. They do not establish that an individual public check can see every sender, validate a live message path, or explain why a particular mailbox provider accepted, filtered, or rejected a message. Use a [DMARC checker](/tools/dmarc) only for the public DNS evidence it can inspect. A public record check does not prove the production sending path, message signing, continuous state, or why one receiver rejected one message. ![Decision map for separating public DMARC evidence from message and reporting evidence](/images/editorial/valimail-dmarc-checker/valimail-dmarc-checker-evidence-map.webp "1200x829") *Source: Palisade.* ## How to run the check ### 1. Start with the exact domain used in the visible From address Identify the domain after the `@` in the visible From address of the mail you are investigating. Keep that domain separate from any return-path or signing domain until you have message-header evidence connecting them. If the problem concerns a specific campaign, application, or vendor, record the sender name and the date of a real test message. A domain-wide result cannot identify the exact system that sent that message. ### 2. Use the published Valimail entry point Open [Valimail's website](https://valimail.com) and select "Check My Domain." Record the domain entered, the date, and every result label shown by the current interface. Do not infer the meaning of a label from a search result, a past screenshot, or a similarly named product. If the result does not explain its evaluation criteria, keep it as a vendor-interface observation rather than a protocol conclusion. ### 3. Independently query the public DMARC owner A direct public DNS query creates a repeatable record of the answer returned at the time of the test. Replace the example domain with your own domain. ```bash dig +short TXT _dmarc.yourdomain.com ``` This command retrieves a public DNS response. It does not confirm which service sent mail, whether a message passed authentication, or whether a mailbox provider delivered it. ### 4. Preserve the evidence needed for a retest Save the domain name, timestamp, tool result, and DNS response. If the tool displays an error or no result, preserve that wording exactly. It may distinguish a tool-input issue from a DNS condition, but only the current interface documentation or result explanation can establish that distinction. ## How to interpret the results ### A domain-visibility or enforcement-status result Valimail says Monitor provides detailed views into enforcement status across sending domains. Treat this as a visibility-oriented result unless the current interface explains the underlying evidence and scope. A visibility result can identify a domain that needs closer review. It cannot, on its own, show that all services using the domain authenticate and align correctly. The next evidence should be a real delivered message and its receiver-added authentication results. ### A DMARC report or source-inventory result Valimail says Monitor can turn raw IP data into DMARC reports. A report can be useful for discovering sending sources that need investigation. It does not make a source authorized, correctly configured, or ready for enforcement by itself. Compare each reported source with the systems your organization intends to send mail. Then obtain a test message from the exact source. Look for receiver-added authentication evidence and keep the message path separate from a public record lookup. ### An unavailable, unclear, or undocumented checker result When the interface does not document what a result means, do not turn that result into a claim that the domain is safe or protected. Confirm the published DNS record, then move to message evidence and aggregate reports. This restraint matters when selecting tools. The [Palisade comparison hub](/compare) can help frame a vendor decision around the work you need done, such as domain visibility, sender inventory, remediation workflow, or policy readiness. It cannot replace the evidence required for your own domains. ## How to act on the result Start with the narrowest problem the evidence actually shows. - If the result points to a domain you do not recognize, identify the owner internally before changing DNS. An unfamiliar source may be a legitimate application, a retired sender, or an unauthorized service. - If the public DNS response differs from the value your DNS provider shows, check the authoritative DNS configuration and allow for normal DNS propagation before retesting. - If the public record appears present but mail still has a problem, collect a real message sent through the affected application and inspect the receiver's authentication results. - If the result identifies a source but does not show message-level authentication, validate the source with a delivered message before deciding whether to repair sender configuration, DNS, or policy. - If reports show known sources that are not ready for enforcement, resolve the individual authentication or alignment issues before proposing a policy change. > Do not move a DMARC policy to a stricter value because one lookup appears healthy. A policy change can affect mail sent by sources that were not included in that lookup. Valimail separately describes Monitor's enforcement-status visibility and Enforce's authentication automation, policy decisions, and reporting capabilities for continuous DMARC enforcement. It is reasonable to treat visibility and enforcement as different operational needs. The available material does not establish a universal threshold for moving a domain to a stricter DMARC policy. For a second vendor-oriented reading of what a checker can and cannot establish, see [Proofpoint DMARC checker: what the compliance check actually includes](/learning/proofpoint-dmarc-checker). Keep the same standard: public results need confirmation with the exact sender and message path involved. ## How to retest Repeat the same Valimail path with the same domain after the relevant DNS or sender change. Record the new date and the full result state rather than relying on a remembered summary. Run the same direct DNS lookup again: ```bash dig +short TXT _dmarc.yourdomain.com ``` Then send a new message through the same application, account, visible From domain, and recipient path that exposed the issue. Inspect the receiver-added authentication results in that delivered message. After DMARC reports accumulate, compare the reporting data with the sender inventory and the message test. The expected change depends on what was repaired. A public DNS correction should change the public DNS answer. A sender-configuration correction should appear in a new message from that sender. A report-based source issue may need additional reporting data before its trend is clear. ## Build a remediation workflow after the domain check A one-time lookup can show the public state of a domain at a moment in time. It does not identify every production sender that later begins using the domain or determine whether a sender is ready for a DMARC policy change. Palisade is agentic DMARC software for teams that need to work through DMARC aggregate-report data across domains. It can analyze aggregate-report data, identify sending sources and authentication or alignment issues, create prioritized remediation tickets, and propose when a domain appears ready for the next policy stage. A human reviews the evidence and applies any change. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=tools_vendors_comparisons&utm_content=valimail-dmarc-checker) Palisade does not autonomously change the DMARC policy, prove every future message will authenticate, or guarantee mailbox-provider delivery decisions. ## Sources and further reading - [Valimail homepage and Monitor information](https://valimail.com) - [Palisade DMARC checker](/tools/dmarc) - [Palisade comparison hub](/compare) ## Frequently asked questions ### Is Valimail safe? Not enough verified public material is available here to make a safety conclusion about Valimail. A product's safety depends on factors such as its security controls, data handling, account configuration, and the scope of the service being used. Review current vendor security documentation and contractual materials before making that assessment. ### How can I check my DMARC? Use Valimail's published "Check My Domain" entry point or a public [DMARC checker](/tools/dmarc) to inspect the domain evidence available to the tool. Then confirm the public result with a DNS query, a real delivered message from the affected sender, and DMARC aggregate-report data. A public lookup alone cannot prove the production message path. ### Is Valimail free? Yes, Valimail says its Monitor account is free and provides "unlimited domain visibility." That statement applies to Monitor and does not mean that every Valimail product or capability is free. ### What does Valimail do? Valimail describes Monitor as providing domain visibility and enforcement-status views, with DMARC reports derived from raw IP data. It describes Enforce as supporting authentication automation, policy decisions, and reporting and analytics for continuous DMARC enforcement. ### Does a DMARC checker prove that all mail will pass DMARC? No. A checker can inspect the public evidence available during that run. A delivered message from the exact sender is needed to show what authentication evidence a receiver recorded, and aggregate reports are needed to review sending activity over time. --- # What is a browser-in-the-browser attack? Canonical: https://www.palisade.email/learning/what-is-a-browser-in-the-browser-attack > A browser-in-the-browser (BitB) attack fakes a login popup with a forged address bar to steal credentials. Here's how it works and how to spot and stop it. A browser-in-the-browser (BitB) attack is a phishing technique that draws a fake browser popup window (complete with a forged address bar showing a legitimate URL) entirely inside a web page using HTML and CSS. It imitates the single sign-on prompts you see when you click "Sign in with Google" or "Sign in with Microsoft," so the victim types real credentials into a window that is just part of the attacker's page. Because the address bar is a picture, not a real one, the usual advice to "check the URL" does not help. ## Quick Takeaways - A BitB attack renders a counterfeit login popup inside the page; the address bar and padlock are fake HTML, not a real browser window. - It targets single sign-on (SSO) and OAuth flows, where users expect a small popup asking for Google, Microsoft, or Apple credentials. - The technique was popularized by a security researcher known as mr.d0x, who published a working proof of concept in 2022. - Checking the URL does not defend against it because the URL shown is drawn by the attacker. - Password managers, passkeys, and dragging the popup outside the window are reliable tells because they react to the *real* origin, not the fake one. - DMARC cannot see a BitB page. It stops the lure email from being spoofed from your domain, but the attack happens after the click. ## How does a browser-in-the-browser attack work? The attack recreates the look of an operating-system browser popup using ordinary web code. When a site offers SSO, clicking the button normally opens a genuine small window pointing at `accounts.google.com` or `login.microsoftonline.com`. A BitB page skips the real popup and instead draws a `<div>` styled to look exactly like that window: title bar, close button, and an address bar with a convincing URL and a padlock icon. Inside that fake frame sits a real login form controlled by the attacker. The victim, seeing what appears to be a trusted Google or Microsoft prompt with the correct address in the bar, enters their username and password. Those values go straight to the attacker's server. Many kits also relay the credentials in real time to capture the multi-factor prompt and the resulting session, defeating one-time-code MFA. The whole illusion depends on the victim reaching the attacker's page first: usually through a [phishing](/learning/what-is-phishing) email, a malicious ad, or a [lookalike domain](/learning/how-can-i-take-down-lookalike-domains). The page itself is legitimate HTML from the attacker's server, so there is no malware to scan and nothing for a mail filter to catch once the link is clicked. ## Why is a BitB attack so convincing? Most phishing training tells people to hover over links and read the address bar. BitB defeats that habit directly. The address bar the victim inspects is part of the phishing page, so it can display `https://accounts.google.com` with a padlock while the actual page is on the attacker's domain. Three details make it land: - **Familiar context.** SSO popups are routine, so a small window asking for Google or Microsoft credentials does not feel unusual. - **Pixel-accurate chrome.** The fake window copies the real browser's fonts, buttons, and shadow, and can even animate as if it were opening. - **A trusted-looking URL.** The forged address bar removes the one signal users are trained to check. This is the same blind spot behind why so many [phishing emails pass SPF and DKIM checks](/learning/why-do-phishing-emails-pass-spf-and-dkim): the technical envelope can look clean while the human-facing content is entirely fake. ## How do you spot a browser-in-the-browser attack? The fake window betrays itself the moment you test it against something the attacker cannot fake: - **Try to drag the popup outside the main window.** A real browser popup is its own OS window and moves independently past the edge of the parent tab. A BitB window is trapped inside the page and cannot leave it. - **Watch your password manager.** A manager keyed to the real origin will not autofill on the attacker's domain. If your saved Google login does not offer to fill the "Google" prompt, the prompt is not Google. - **Maximize or resize the browser.** The fake window often clips, misaligns, or fails to reflow because it is a page element, not a true window. - **Look for the real address bar.** The genuine browser address bar (the one at the top of the actual window) still shows the attacker's domain. Only the inner, fake bar is spoofed. ## How do you stop browser-in-the-browser attacks? Because BitB happens after the click, defense combines identity controls that cannot be phished with the email controls that keep your domain out of the lure. - **Deploy phishing-resistant MFA.** FIDO2 security keys and passkeys are bound to the real web origin. A passkey registered for `google.com` simply will not authenticate against the attacker's domain, so a stolen password gets the attacker nothing. This is the single strongest control. See the MFA types worth deploying. - **Train on the drag-and-autofill tests** rather than "check the URL." Give users two physical actions that expose the fake window instead of a rule the attack defeats. - **Enforce DMARC** so attackers cannot send the initial lure from your own domain. Move from `p=none` to `p=quarantine` or `p=reject` once your legitimate senders are aligned; check where you stand with the [DMARC checker](/tools/dmarc). - **Monitor for lookalike domains** that host these pages, and scan suspicious links before clicking with a [phishing link checker](/tools/phishing-link-checker). - **Harden the credential path** overall: see [how IT teams prevent credential theft](/learning/threats) for the broader program. For MSPs and IT teams, Palisade automates the email-authentication layer (getting client domains to DMARC enforcement and keeping them there) so your own domains cannot be used to deliver the phishing email that starts a BitB attack. A free [Email Security Score](/tools/email-security-score) shows which client domains are still spoofable today. ## Frequently asked questions **Is a browser-in-the-browser attack the same as ghost phishing?** No. Both hide malicious intent inside a rendered page, but [ghost phishing](/learning/what-is-ghost-phishing) keeps its payload encrypted until it decrypts in the browser to evade scanners, while BitB fakes a popup window to imitate a real login prompt. **Can antivirus or a secure email gateway block BitB?** Not reliably. The page is standard HTML served from the attacker's site, so there is no malicious file to detect. Gateways can catch the lure email or the malicious link, but not the rendered fake window. **Do passkeys really stop it?** Yes, when they are the login method. Passkeys and FIDO2 keys are cryptographically tied to the legitimate domain, so they refuse to sign in on the attacker's origin even if the user is fully fooled by the visual. **Does checking for HTTPS help?** No. The padlock and `https://` in the fake window are drawn by the attacker. Only the browser's own address bar, outside the fake popup, reflects the real connection. ## Related reading - [What is phishing? Attack types and prevention guide](/learning/what-is-phishing) - [What is ghost phishing and can DMARC stop it?](/learning/what-is-ghost-phishing) - [Common social engineering attacks and how to prevent them](/learning/phishing-attack-protection) --- # Email warmup service: compare the evidence before choosing Canonical: https://www.palisade.email/learning/email-warmup-service > Email warmup service comparison: assess MailToaster, verify what other vendors document, and separate warm-up claims from authentication checks. Choose MailToaster if you specifically want a vendor-documented automated warm-up workflow and accept that its claims still need to be evaluated against your own sending setup. Do not choose Instantly or Skrapp as email warmup services based on the supplied homepage evidence alone, because that evidence does not document a warm-up product. Start with the job you need, then separate vendor claims from authentication and delivered-message evidence. ## Quick takeaways - MailToaster documents an automated email warm-up service with account connection, profile configuration, message-copy choices, and inbox filtering. - MailToaster lists "New Email Account" and "Reputation Protect" as warm-up profiles. - MailToaster states a flat fee of "$29 per email account per month," with monthly or annual billing depending on the subscription plan. - The supplied Instantly homepage evidence names Inbox Placement and Deliverability, but does not document email warming. - The supplied Skrapp homepage evidence describes lead generation and email verification, not email warm-up. - A warm-up vendor claim does not prove that your production messages authenticate, reach the inbox, or meet a receiving provider's private filtering criteria. ## Who this comparison is for This comparison is for an operator evaluating an email warmup service before connecting a mailbox used for outreach or other business sending. The useful question is narrow: which vendor currently documents a warm-up workflow, and what evidence is still missing before you treat it as part of a deliverability plan? It is not a complete ranking of the warm-up market. The available first-party evidence supports detailed evaluation of MailToaster, while the supplied material for Instantly and Skrapp does not establish equivalent warm-up functionality. That distinction matters. Missing documentation is an open question, not proof that a product feature does not exist. For broader commercial decisions about email-security and deliverability products, use Palisade's [comparison hub](/compare). For the operational work beyond a warm-up service, see the [email deliverability guide](/email-deliverability). ## How the options were evaluated The criteria were set before drawing conclusions and checked against the supplied first-party vendor pages on July 30, 2026: - Product evidence: Does the vendor's own page document an email warm-up service or workflow? - Operator workflow: Does the page state what the user connects, configures, or reviews? - Compatibility claim: Does the vendor state which mailbox providers or account types it supports? - Commercial evidence: Does the page publish a current price or billing statement? - Evidence boundary: Which results remain unproven, including production authentication, provider acceptance, and inbox placement? A documented claim counts only for the wording and scope published by that vendor. A claim that is absent from the supplied evidence remains unknown. This comparison does not infer that automated engagement improves deliverability for a particular mailbox provider or sending program. ## Instantly Instantly's supplied homepage navigation includes [Inbox Placement and Deliverability](https://instantly.ai), which shows that the company presents deliverability-related product areas. It does not, however, document an email warm-up workflow, setup process, controls, pricing, or warm-up network in the evidence available for this comparison. - Best fit: An open question for email warm-up specifically. The supplied evidence supports only that Instantly presents deliverability-related product areas. - Relevant evidence: Instantly's homepage includes the product-navigation labels "Inbox Placement" and "Deliverability," checked July 30, 2026. - Tradeoff: Do not treat those navigation labels as proof of an email warmup service. Confirm the current product page, pricing, setup requirements, and supported account types before connecting a production mailbox. The practical next step is to ask for the exact evidence needed for your case: the current product page, a security description of the connection method, current pricing, and documentation for any claimed warm-up workflow. Without those details, a buyer cannot compare the service on equal terms with a vendor that documents its workflow. ## Skrapp Skrapp describes itself as a [B2B lead generation and email finder platform](https://skrapp.io) and publishes email verification as part of that offer. Neither statement documents an email warm-up service in the supplied first-party material. - Best fit: Lead generation, email finding, and email verification based on the supplied homepage description. - Relevant evidence: Skrapp's homepage uses the descriptions "B2B lead generation and email finder platform" and "Email Verification," checked July 30, 2026. - Tradeoff: The available evidence does not establish a warm-up product, workflow, price, mailbox compatibility, or provider-policy position. Email verification and email warm-up address different questions. Verification concerns whether an address can be assessed for sending use. A warm-up vendor may claim to create mailbox activity. Neither category proves that a production domain has valid SPF, DKIM, and DMARC configuration or that a receiving provider will place future mail in the inbox. ## MailToaster MailToaster is the only option in this comparison with supplied first-party evidence that explicitly describes itself as an [email warm-up service](https://mailtoaster.ai). Its page uses the phrases "Effortless email warm-up to boost inbox placement" and "Build, maintain, and repair your sender reputation automatically." Those are MailToaster marketing claims, not independent proof of an outcome with a given mailbox provider. ![MailToaster product overview showing an email warm-up service](/images/editorial/email-warmup-service/email-warmup-service-shot-3.png "1600x900") *Source: https://mailtoaster.ai* MailToaster describes a "100% automated process" in which a user can "Connect your email account," "Configure warm-up settings," choose to "Send auto-generated texts or use templates," and "Filter warm-up emails in your Inbox." The page also lists the profiles "New Email Account, Reputation Protect." - Best fit: A team that wants a vendor-documented automated warm-up workflow for a connected email account. - Relevant evidence: MailToaster describes account connection, warm-up settings, generated or template copy, inbox filtering, and the "New Email Account" and "Reputation Protect" profiles. It also says it is available for "GSuite, Outlook and other providers," checked July 30, 2026. - Tradeoff: The supplied page does not establish the exact connection method, permissions, OAuth or credential handling, supported Google Workspace or Microsoft account types, warm-up limits, cancellation terms, or whether the service improves results with a particular receiving provider. MailToaster also states that it uses "peer-to-peer sending only with no free or temporary email accounts" and describes engagement actions including "opens, replies to, marks as important, removes from spam, etc." That describes the vendor's stated approach. It does not establish a mailbox provider's policy position on synthetic activity or prove that those actions improve future inbox placement. Its published commercial statement is "$29 per email account per month billed monthly or annually, depending on your subscription plan." Treat that as a point-in-time vendor statement. Confirm the current price, annual-billing terms, taxes, limits, and feature exclusions before purchase. MailToaster says it can automatically check SPF, DKIM, DMARC, and other email-related DNS records. The supplied evidence does not describe the exact checks or any remediation behavior. Inspect those records independently before treating a warm-up account as sending-ready. ![Example email-authentication record set to inspect separately from an email warm-up service](/images/editorial/email-warmup-service/email-warmup-service-records.webp "1200x533") *Source: Palisade.* ```text Illustrative only. Do not publish values from another tenant. yourdomain.com TXT "v=spf1 include:mail.example ~all" selector1._domainkey.yourdomain.com TXT "v=DKIM1; k=rsa; p=<public-key>" _dmarc.yourdomain.com TXT "v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com" ``` A public [DMARC check](/tools/dmarc), SPF check, or DKIM check can inspect published DNS evidence. A public check cannot prove that the warm-up vendor or your production sender is using the intended authentication path, monitor later changes, or reveal a receiver's private placement decision. ## How to choose Choose MailToaster only if its documented workflow matches your immediate need and you have confirmed the unresolved operational details that matter to your mailbox environment. Keep Instantly and Skrapp in the open-question category for warm-up specifically until their current first-party documentation establishes a comparable service. Use this decision checklist before connecting an account: - Confirm that the vendor documents the exact warm-up workflow you intend to use. - Ask how the account connection works and what permissions or credentials the service requires. - Confirm the current price, billing terms, limits, and cancellation terms. - Check SPF, DKIM, and DMARC independently before drawing conclusions from warm-up activity. - Send a real message through the exact production path and inspect its `Authentication-Results` header. - Review DMARC aggregate-report data after it accumulates to identify real sending sources and alignment issues. ```yaml option: Instantly checked_on: 2026-07-30 best_fit: Deliverability-related product areas are named on the homepage verified_evidence: - Homepage navigation includes Inbox Placement - Homepage navigation includes Deliverability open_question: Whether Instantly currently offers an email warm-up service and, if so, its workflow, pricing, controls, and compatibility --- option: Skrapp checked_on: 2026-07-30 best_fit: Lead generation, email finding, and email verification verified_evidence: - Homepage describes a B2B lead generation and email finder platform - Homepage names Email Verification open_question: Whether Skrapp currently offers an email warm-up service and, if so, its workflow, pricing, controls, and compatibility --- option: MailToaster checked_on: 2026-07-30 best_fit: A vendor-documented automated email warm-up workflow verified_evidence: - Documents account connection and warm-up configuration - Lists New Email Account and Reputation Protect profiles - States a flat fee of $29 per email account per month open_question: Connection security, account-type support, exact limits, annual terms, and provider-specific outcome evidence ``` ## Check the authentication records before you connect a warm-up service A warm-up service cannot establish that your production domain is correctly authenticated. Inspect the sending domain's published DMARC, SPF, and DKIM records before you connect an account, then compare the result with a real message sent through the same production path. Start with Palisade's [DMARC checker](/tools/dmarc) to inspect the published policy. A DNS check does not prove that every sender aligns with that policy, repair authentication failures, monitor future DNS drift, or guarantee inbox placement. For the broader operational question, read [does email warmup work?](/learning/does-email-warmup-work) and compare it with the requirements of your actual mail flow. ## Sources and further reading - [MailToaster email warm-up service](https://mailtoaster.ai), checked July 30, 2026. - [Instantly homepage](https://instantly.ai), checked July 30, 2026. - [Skrapp homepage](https://skrapp.io), checked July 30, 2026. - [Palisade email deliverability guide](/email-deliverability). ## Frequently asked questions ### Is MailToaster an email warmup service? Yes. MailToaster describes itself as an email warm-up service and documents an automated workflow that includes connecting an email account, configuring settings, choosing generated or template copy, and filtering warm-up email in the inbox. Its marketing claims do not prove a specific deliverability outcome with a mailbox provider. ### Does Instantly's homepage prove that it offers email warming? No. The supplied Instantly homepage evidence includes the labels "Inbox Placement" and "Deliverability," but it does not document an email-warmup service, its workflow, price, or controls. Verify those details from current first-party product documentation before making a purchase decision. ### Does Skrapp offer an email warmup service? Not from the supplied homepage evidence. Skrapp's published homepage description covers B2B lead generation, email finding, and email verification. That is not evidence of a warm-up product, and missing documentation should remain an open question. ### Can an email warmup service prove inbox placement? No. A vendor's warm-up workflow or engagement claims do not prove a receiving provider's private filtering decision or future inbox placement. Inspect authentication records, test the real production sending path, and review ongoing DMARC data separately. ### Should SPF, DKIM, and DMARC be checked before using a warm-up service? Yes. Public DNS checks can establish what a domain publishes for SPF, DKIM, and DMARC. They do not prove that the production application signs messages correctly or that the visible records match the exact sending path, so validate with a real delivered message and its authentication results as well. --- # MXToolbox DMARC: how to interpret a public record lookup Canonical: https://www.palisade.email/learning/mx-toolbox-dmarc > MXToolbox DMARC lookup results show a public DNS policy record, not message delivery. Learn how to interpret, verify, and retest them for your domain. Choose MXToolbox when you need a point-in-time view of the DMARC record that public DNS returns for a domain. Choose a message header or DMARC aggregate reports when the question is whether a production message passed DMARC. An MXToolbox result can identify a missing, malformed, or unexpected policy record, but it cannot prove sender alignment, receiver delivery, or inbox placement. ## Quick takeaways - An MXToolbox DMARC lookup checks the public DMARC policy record available for a submitted domain at lookup time. - A valid-looking DNS record does not prove that a particular production message passed DMARC. - `p=none`, `p=quarantine`, and `p=reject` express requested handling for mail that fails DMARC. They do not identify every legitimate sender. - A missing or malformed result is a DNS evidence problem first. Confirm the record owner and returned value before editing. - Use a delivered message's authentication results for one-message diagnosis, then use aggregate reports to identify recurring sending sources. - Retest the same domain after a confirmed DNS change, but keep DNS, vendor, message, and aggregate-report evidence separate. ## Who this comparison is for This comparison is for an IT administrator or email operator who has a domain name and an MXToolbox DMARC result, but needs to decide what that result means and what evidence to collect next. The immediate job is narrow: interpret a public record lookup. It is not an inbox-placement test, an SMTP test, or proof that every application sending mail for the domain is authenticated. The [DMARC learning hub](/learning/dmarc) covers the wider operating model. This page focuses on the decision between a named MXToolbox lookup and a second public record check. Use the visible From domain for the sending stream under investigation. Do not submit a full email address, a URL, or an MX host to a DMARC lookup. DMARC policy discovery begins with DNS for the relevant domain under [RFC 9989](https://www.rfc-editor.org/rfc/rfc9989.html). ## How the options were evaluated The criteria below were checked against the cited public pages and captured public results on July 28, 2026. - Input fit: whether the option accepts the public domain evidence the operator has. - Evidence scope: whether the result establishes public DNS configuration or message-specific authentication behavior. - Output usefulness: whether the result shows a returned DMARC policy and record-level diagnostics that support the next action. - Time model: whether the result is a point-in-time lookup or recurring evidence collection. - Boundary clarity: what the result does not prove about production messages, receiver decisions, or future DNS state. A documented public capability counts as available. A capability not documented in the cited evidence remains an open question. A public record result for `example.com` is an example only. It does not establish the state of another domain. ## MXToolbox DMARC lookup MXToolbox provides a public [DMARC lookup page](https://mxtoolbox.com/DMARC.aspx) with a `Domain Name` field and a `DMARC Lookup` action. The result is useful when the question is what public DNS returns for a domain's DMARC policy record. ### 1. Enter the organizational domain Enter the domain from the visible From address of the stream you are checking. The lookup asks what DMARC policy DNS publishes for that domain. It does not inspect an individual delivered message. ![MXToolbox DMARC lookup entry page showing the Domain Name field and DMARC Lookup action](/images/editorial/mx-toolbox-dmarc/mx-toolbox-dmarc-entry-console.png "1728x1069") *Source: [MXToolbox, "DMARC Check Tool - Check DMARC Records for Errors"](https://mxtoolbox.com/DMARC.aspx), checked 2026-07-28.* ### 2. Record the returned policy and warning Record the lookup time, returned policy text, and any warning before making a DNS change. MXToolbox's public `example.com` result displayed a returned record, tag descriptions, and diagnostic checks when captured. That view is useful for separating the record itself from the tool's interpretation of record-level conditions. ![MXToolbox SuperTool public DMARC result for example.com showing a returned policy record, tag descriptions, and diagnostic checks](/images/editorial/mx-toolbox-dmarc/mx-toolbox-dmarc-result-console.png "1280x720") *Source: [MXToolbox, "SuperTool DMARC result for example.com"](https://mxtoolbox.com/SuperTool.aspx?action=dmarc%3Aexample.com&run=toolpage), checked 2026-07-28.* - Best fit: An operator who needs a public DNS view of one domain's DMARC record and record-level warnings. - Relevant evidence: MXToolbox documents the public lookup form, and its captured `example.com` result showed returned record details and diagnostic checks. - Tradeoff: The result cannot establish the SPF or DKIM outcome of a delivered message, alignment for a production sender, a receiver's private filtering decision, or future inbox placement. Use this evidence record when documenting the result: ```text Lookup input: yourdomain.com Lookup time: YYYY-MM-DDTHH:MM:SSZ Returned evidence: public DMARC record and record-level diagnostics Question answered: what policy does public DNS return now? Not established: message authentication, receiver delivery, or inbox placement ``` ## Palisade DMARC checker The [Palisade DMARC checker](/tools/dmarc) is the closer alternative when you want to compare the same public domain through a second record checker. A public `example.com` check observed on July 28, 2026 returned a policy state and displayed DMARC fields including `p`, `sp`, `adkim`, and `aspf`. ![Palisade DMARC checker public result for example.com showing returned DMARC policy fields](/images/editorial/mx-toolbox-dmarc/mx-toolbox-dmarc-tool-state.png "1728x940") *Source: [Palisade, "DMARC checker"](https://www.palisade.email/tools/dmarc), checked 2026-07-28.* - Best fit: An operator who already has a public domain and wants an independent view of the published DMARC policy fields before editing DNS. - Relevant evidence: The checker accepts a domain and returns public DMARC policy information for the submitted domain. - Tradeoff: It is also a point-in-time public DNS check. It does not prove that the exact production sending path uses aligned SPF or DKIM, and it does not control a receiving mailbox provider's delivery decision. A second public lookup is useful when an MXToolbox result is missing, malformed, or unexpected. Different formatting does not by itself mean the DNS record differs. Compare the returned record owner and policy fields before changing the zone. ![Example DMARC policy record fields that a public lookup can establish, with the message-level evidence it cannot establish](/images/editorial/mx-toolbox-dmarc/mx-toolbox-dmarc-record-meaning.webp "1200x600") *Source: Palisade.* ## How to choose Choose MXToolbox if its public result gives you the record and warning context you need. Choose the Palisade DMARC checker if you need a second public-domain lookup to compare the published policy before making a change. Neither choice replaces message evidence or reporting evidence. Use the result to select the next action: - No record found: Confirm that `yourdomain.com` is the intended From domain and that the DNS zone is authoritative before publishing a record. The [DMARC record generator](/tools/dmarc-generator) can help create a structural record after you have confirmed the policy decision. - Syntax or multiple-record warning: Inspect the exact DNS owner and value. Correct only the smallest confirmed defect. Do not weaken policy to mask an unresolved sender problem. - `p=none`: Treat the result as a monitoring policy. Collect aggregate-report evidence before moving to stronger enforcement. - `p=quarantine` or `p=reject`: Treat the result as a requested policy for mail that fails DMARC. Verify representative production messages and aggregate reports before assuming all legitimate sources are aligned. - A message-specific failure: Use the message's receiver-added authentication results and the sending service's configuration. A DNS record lookup cannot attribute the failure. RFC 9989 defines DMARC evaluation around identifier alignment with authenticated SPF or DKIM identifiers. A public policy record can be valid while a legitimate sender still fails alignment. The relevant validation sequence is DNS first, then the sending vendor's status where applicable, a delivered message from the exact production path, and aggregate reports once they accumulate. ```yaml option: MXToolbox DMARC lookup checked_on: 2026-07-28 best_fit: Public DNS record and record-level warning review verified_evidence: Domain Name input, DMARC Lookup action, returned record details and diagnostics open_question: Whether the lookup result corresponds to a specific production message option: Palisade DMARC checker checked_on: 2026-07-28 best_fit: Independent public-domain comparison of DMARC policy fields verified_evidence: Submitted domain returns a public policy state and displayed DMARC fields open_question: Whether a specific sender is aligned in production ``` > Do not move to `p=quarantine` or `p=reject` because a public lookup looks clean. A green record-level result does not test every legitimate sender that uses the domain. ## Compare the published record before editing DNS Use the same domain in the [Palisade DMARC checker](/tools/dmarc) when MXToolbox reports a missing, malformed, or unexpected policy. Compare the returned public policy with the record-level result already collected before editing DNS. [Check the public DMARC record](/tools/dmarc) A record check cannot establish why a specific delivered message passed or failed, monitor future DNS changes, or guarantee inbox placement. If the public record is valid but legitimate sources keep failing alignment, the remaining problem is recurring sender evidence. Palisade is agentic DMARC software that analyzes DMARC aggregate-report data, identifies sending sources and authentication or alignment issues, and creates prioritized remediation tickets for human review. It can propose the next policy step when the evidence supports it. Palisade does not change DNS, decide receiver delivery, or guarantee that future messages authenticate. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=dmarc_diagnostics&utm_content=mx-toolbox-dmarc) ## Sources and further reading - [RFC 9989: Domain-based Message Authentication, Reporting, and Conformance](https://www.rfc-editor.org/rfc/rfc9989.html) - [MXToolbox DMARC lookup](https://mxtoolbox.com/DMARC.aspx) - [MXToolbox SuperTool DMARC result for example.com](https://mxtoolbox.com/SuperTool.aspx?action=dmarc%3Aexample.com&run=toolpage) - [Palisade DMARC checker](https://www.palisade.email/tools/dmarc) - [Palisade guidance on fixing authentication issues](https://docs.palisade.email/guides/fixing-authentication-issues/) ## Frequently asked questions ### Does an MXToolbox DMARC lookup prove my email passes DMARC? No. An MXToolbox DMARC lookup shows public DNS evidence for the submitted domain at lookup time. A receiver evaluates a delivered message using its SPF and DKIM results and identifier alignment with the visible From domain. ### Does a `p=reject` result mean every sender using my domain is protected? No. `p=reject` requests handling for messages that fail DMARC, but it does not prove that every legitimate sender has aligned SPF or DKIM. Check representative production messages and aggregate reports before relying on enforcement. ### What should I do if MXToolbox says no DMARC record was found? Confirm the visible From domain, DNS zone, and record owner first. After publishing a deliberate record, retest the same domain with a public lookup and then validate a representative delivered message through the actual sending path. ### Can a public DMARC lookup explain why one message went to spam? No. A public lookup cannot see the recipient's private filtering decision, the delivered message headers, or the sender configuration used for that message. Inspect receiver-added authentication results and the relevant provider evidence instead. ### Should I use an MX lookup to troubleshoot a DMARC result? Only when mail routing is also part of the incident. An [MX records checker](/tools/mx) can inspect public MX records, but MX records do not establish a domain's DMARC policy or the alignment result of a delivered message. --- # Authentication failed email: fix mailbox and SMTP login errors Canonical: https://www.palisade.email/learning/authentication-failed-email > Fix authentication failed email errors by checking mailbox sign-in, SMTP AUTH credentials, TLS, and sender permissions. An "authentication failed" email error usually happens before a message is accepted for delivery. It points to a mailbox sign-in or SMTP AUTH problem, such as invalid credentials, a blocked account, a disabled submission method, an unsupported login mechanism, or a TLS mismatch. Save the complete error first, then test the same account and sending path. If a receiver reports SPF, DKIM, or DMARC results after delivery, use the [email authentication failure diagnostic](/learning/email-authentication-failure) instead. The [email authentication hub](/learning) explains the separate receiver-side protocols. ## Quick takeaways - Start with the exact error code, prompt, timestamp, account, and affected app or device. - A `535 5.7.8` reply means the SMTP server rejected the credentials in that AUTH exchange. - Test the same credentials in the provider's supported webmail or account path before editing SMTP settings. - Check the server, port, TLS mode, and advertised AUTH mechanism as one configuration. - Do not change SPF, DKIM, or DMARC to fix a pre-submission login failure. ## What does the failure mean? Mailbox sign-in and SMTP AUTH are different from receiver-side email authentication. SMTP AUTH is a client-to-server exchange that starts with the `AUTH` command after the server advertises supported mechanisms. [RFC 4954](https://www.rfc-editor.org/rfc/rfc4954.html) defines a `535 5.7.8` response as invalid or insufficient authentication credentials, while `454 4.7.0` indicates a temporary server failure. The reply text can add provider-specific context, but preserve it rather than guessing from the word "authentication." ```text 535 5.7.8 Authentication credentials invalid 454 4.7.0 Temporary authentication failure ``` These are protocol examples, not proof of the cause in a particular account. A password prompt can also mean the provider changed its authentication method, reset the password, or suspended the account. [Apple's current Mail troubleshooting](https://support.apple.com/en-ie/102413) lists those account-side causes and recommends checking the same credentials through webmail. ![Decision flow separating mailbox sign-in, SMTP AUTH, and receiver-side authentication evidence.](/images/editorial/authentication-failed-email/authentication-failed-email-evidence-flow.svg "1200x861") *Source: Original Palisade troubleshooting graphic based on [RFC 4954 SMTP Authentication](https://www.rfc-editor.org/rfc/rfc4954.html).* ## What usually causes it? ### The account password or account state changed The quickest distinction is whether the account can sign in through its normal webmail or provider account flow. Apple documents that a Mail password prompt can follow use of an old password, a provider-required reset, an account suspension, or a changed authentication method. A failed webmail test points to the account or provider path, not to the mail client's outgoing-server settings. ### The SMTP credentials do not match the configured mailbox An SMTP client can reach a server and still fail AUTH because the submitted username or password is wrong, expired, or no longer accepted. RFC 4954 assigns `535 5.7.8` to invalid or insufficient credentials. Do not assume that a client-side password field contains the current account credential. ### The server requires a different TLS or AUTH method The server advertises AUTH mechanisms in the `EHLO` response, and that list may change after `STARTTLS`. RFC 4954 also says a server should reject an unsupported mechanism or one that requires encryption with `504`. This means the server, port, TLS mode, and mechanism must be checked together. ### The authenticated account is not allowed to submit as the visible sender Successful login does not always authorize every From address. For Microsoft 365 SMTP client submission, [Microsoft's current troubleshooting guidance](https://learn.microsoft.com/en-us/troubleshoot/exchange/email-delivery/fix-issues-with-printers-scanners-and-lob-applications-that-send-email-using-off) says the app normally sends from the mailbox used to log on, or that mailbox needs Send As permission for another sender. Microsoft also documents `5.7.60` for a sender-permission mismatch. ## How do I diagnose the failure? ### 1. Capture the exact failed path Record the full error or SMTP reply, UTC timestamp, server hostname, port, TLS setting, username form, From address, and the app or device version. Redact the password, OAuth token, and message content. A test from another mail client only helps if it uses the same account, server, network, and submission method. ### 2. Test the account outside the affected client Sign in through the provider's supported webmail or account page using the same account. If that test fails, reset or recover the account through the provider and stop changing SMTP settings. Apple uses this same comparison to distinguish a rejected account password from a Mail configuration problem in its [webmail test guidance](https://support.apple.com/en-ie/102413). ### 3. Compare the SMTP settings with the server's requirements Confirm the server name, port, TLS mode, and authentication method from the provider's current documentation. For an SMTP session you control, save the greeting, `EHLO` capabilities, the `STARTTLS` result, and the AUTH reply without recording secrets. The AUTH capability list is the evidence for which mechanisms the server offered in that session. ### 4. Check account authorization and the submission route If the client authenticates but sending still fails, compare the authenticated mailbox with the visible From address and the intended submission route. Microsoft documents that SMTP AUTH must be enabled for the mailbox in its client-submission scenario, and that a client without a credential field may need a different submission method. Treat provider administration changes as provider-specific repairs, not universal SMTP instructions. ## How do I fix it? ### Repair the account or credential that the evidence identifies Replace a stale saved password only after confirming the current credential through the provider's approved account path. Complete a required reset or account recovery there. If webmail still rejects the account, contact the provider or administrator rather than repeatedly retrying SMTP AUTH. ### Match TLS and the supported AUTH mechanism Use the provider's documented server, port, TLS setting, and supported login method. Do not force an older plaintext mechanism to work around a TLS or authentication-method rejection. RFC 4954 says servers should not permit plaintext password mechanisms without protection against password snooping, such as negotiated `STARTTLS`. ### Enable or choose the correct submission path When provider documentation shows that SMTP AUTH is disabled for the mailbox, have the account administrator enable the supported method or choose the documented alternative. Microsoft notes that direct send and SMTP relay have different login requirements from SMTP AUTH client submission. Do not weaken multifactor or conditional-access policy as a default repair. That is a security-policy decision, not a technical equivalent of correcting credentials. ### Correct the sender authorization separately If AUTH succeeds but the server rejects the visible sender, give the authenticated mailbox the appropriate provider-defined permission or use the correct relay route. This repair changes sender authorization. It does not change mailbox credentials, SPF, DKIM, DMARC, or receiver enforcement. ## How do I validate the repair? Repeat the same route that failed: the same app or device, network, server, port, TLS mode, authenticated account, and From address. A successful sign-in in another client is useful, but it does not prove the affected configuration now works. - Confirm that the account can sign in through the provider's supported account path when that was the failed layer. - Confirm that the affected client completes SMTP AUTH and accepts the expected submission settings. - Send a controlled message through the same sender route and retain the success or failure reply. - If the message is accepted but later fails at a recipient, inspect the recipient result and switch to the [receiver-side authentication diagnostic](/learning/email-authentication-failure). At that point, headers and domain authentication evidence are relevant. DNS and DMARC reports are not primary validation for mailbox or SMTP login. They become useful only after a message is accepted and a receiver reports a domain-authentication result. For the protocol background behind that later stage, see [what email authentication means](/learning/what-is-email-authentication-and-why-does-it-matter). If you have a delivered message with receiver-added results, the [email header analyzer](/tools/email-header-analyzer) can help separate that later evidence from the submission error. ## Sources and further reading - [RFC 4954: SMTP Service Extension for Authentication](https://www.rfc-editor.org/rfc/rfc4954.html) - [Apple Support: If Mail on your Mac keeps asking for your password](https://support.apple.com/en-ie/102413) - [Microsoft Learn: Fix issues with SMTP AUTH client submission](https://learn.microsoft.com/en-us/troubleshoot/exchange/email-delivery/fix-issues-with-printers-scanners-and-lob-applications-that-send-email-using-off) ## Frequently asked questions ### Does a 535 authentication error mean my email was rejected by the recipient? No. A `535 5.7.8` SMTP AUTH reply concerns the client authentication exchange with the submission server. It normally happens before that server accepts the message for delivery. Save the complete reply and test the same account and SMTP configuration. ### Can I fix an SMTP AUTH failure by changing SPF or DMARC? No. SPF, DKIM, and DMARC are receiver-side domain-authentication controls. They do not supply mailbox credentials or enable an SMTP AUTH method. Change them only when a delivered message has separate receiver-side authentication evidence. ### Why does webmail work but my mail app still says authentication failed? Webmail success usually narrows the problem to the client configuration, saved credential, selected authentication method, or the outgoing SMTP path. Compare the app's server, port, TLS mode, username, and From address with the provider's current requirements. ### Should I turn off multifactor authentication to make SMTP work? Not as a routine fix. A legacy client may not support the provider's required authentication method, but disabling a security control changes account policy. Use the provider's supported submission method or have an administrator assess the approved alternative. ### What evidence should I give an email provider or administrator? Provide the full error text, UTC timestamp, affected account, server hostname, port, TLS mode, application or device version, and whether the same account works through webmail. Do not send passwords, OAuth tokens, or full message content in a support ticket. --- # Valimail pricing Canonical: https://www.palisade.email/learning/valimail-pricing > Valimail pricing explained: Monitor is free, Enforce Starter starts at $5,000 per year, and higher tiers require a custom quote. Valimail publishes a free Monitor plan and lists Enforce Starter as starting at $5,000 per year. Its pricing page names Premium and Enterprise as higher Enforce tiers, but those tiers require a conversation with sales rather than a public rate. Valimail says a premium quote depends on email volume, domains and subdomains, sending services, and organization size. Treat $5,000 as a starting point, not a complete price for every environment. [Valimail's pricing page](https://www.valimail.com/pricing/) was checked on 28 July 2026. ## Quick takeaways - Monitor is Valimail's free plan, while Enforce is its paid DMARC-protection product line. - Enforce Starter is publicly listed as starting at $5,000 per year. - Premium and Enterprise do not have public rates on the pricing page. - Valimail says premium quotes depend on email volume, domains and subdomains, sending services, and organization size. - Ask for the exact scope, term, and included products before using a quote to compare platforms. ## What Valimail publishes publicly [Valimail's pricing page](https://www.valimail.com/pricing/) separates Monitor, Enforce, and Amplify. Monitor is presented as a free plan for visibility. The page presents Enforce Starter, Premium, and Enterprise as pricing tiers. Only Starter has a displayed amount: "Starting at $5,000/year." Premium and Enterprise direct readers to contact Valimail for custom pricing. This page deliberately does not turn that starting price into a per-domain rate, a monthly equivalent, or a promise about what your team will pay. Valimail does not publish those terms on the page. If you are deciding whether Valimail is the right product rather than checking its public price boundary, see the broader [Palisade versus Valimail comparison](/valimail-alternative). ![Valimail Enforce account overview with a mail-sending geography map and country-volume table.](/images/editorial/valimail-pricing/valimail-enforce-account-overview.png "1417x725") *Source: [Valimail Support, “Valimail Enforce Account Overview”](https://support.valimail.com/en/articles/13656887-valimail-enforce-account-overview), checked July 17, 2026. First-party public interface excerpt, unmodified.* ## What a custom quote may depend on [Valimail's request-pricing page](https://www.valimail.com/request-pricing/) says pricing for its premium solutions is tailored to an organization's email infrastructure. It names four factors that can affect a quote: email volume, the number of domains and subdomains, sending services, and organization size. Those factors are inputs to a sales quote, not a published formula. They do not establish which factor carries the most weight or how much any one factor changes the price. That is why two organizations starting from the same public Starter figure can still receive different proposals. ## A practical pricing check before you request a quote Bring a small, consistent fact set to the conversation. It will help you compare Valimail's quote with any other platform proposal on the same scope. ```text Pricing discussion checklist Domains and subdomains in scope: <count> Monthly email volume: <estimate> Sending services: <named systems> Required products: Monitor, Enforce, Amplify, or another scope Contract term and renewal terms: <confirm with vendor> Included support, implementation, and add-ons: <confirm with vendor> ``` Ask whether the quoted scope includes every domain and sending service you expect to manage. Also ask what happens if that scope changes. This is procurement hygiene, not a claim about Valimail's contract terms. ![Decision card distinguishing Valimail's published free Monitor plan and Enforce Starter starting price from custom quote requirements.](/images/editorial/valimail-pricing/valimail-pricing-public-price-boundary.svg "1200x522") *Source: Original deterministic visual based on [Valimail's pricing page](https://www.valimail.com/pricing/) and [Valimail's request-pricing page](https://www.valimail.com/request-pricing/).* ## Compare quotes on the same scope Use the same domain count, email-volume estimate, sending-service inventory, required products, contract term, implementation scope, and support assumptions for every proposal. Otherwise, a lower headline number may simply cover less. When the remaining question is product fit rather than public price, use the [Palisade versus Valimail comparison](/valimail-alternative). For a broader category decision, read the guide to choosing an [email deliverability service](/learning/best-email-deliverability-service) or the operating-model guide to [DMARC monitoring tools](/compare/best-free-dmarc-monitoring-tools). None of those pages replaces a current vendor quote. ## Sources and further reading - [Valimail pricing](https://www.valimail.com/pricing/) - [Valimail request pricing](https://www.valimail.com/request-pricing/) ## Frequently asked questions ### Is Valimail free? Yes. Valimail presents Monitor as a free plan. It is separate from the paid Enforce product line, so confirm the product scope you need before treating Monitor as an evaluation of paid enforcement capabilities. ### How much does Valimail Enforce cost? Valimail publicly lists Enforce Starter as starting at $5,000 per year, checked on 28 July 2026. Premium and Enterprise are listed as custom pricing, so the published figure is a starting point rather than a universal rate. ### What affects a Valimail custom quote? Valimail says its premium-solution quotes can be affected by email volume, the number of domains and subdomains, sending services, and organization size. The company does not publish a formula that assigns a specific price to each factor. ### Does Valimail publish Premium and Enterprise prices? No. Valimail's pricing page names Enforce Premium and Enforce Enterprise, but directs readers to contact the company for custom pricing instead of listing public rates for those tiers. ### Should I compare a quote only by the starting price? No. Compare the required product scope, domain and sender scope, contract term, implementation work, support, and any add-ons. A starting price cannot show whether two proposals cover the same operational need. --- # End to End Encryption Email Services: How to Choose Canonical: https://www.palisade.email/learning/end-to-end-encryption-email-services > Compare end to end encryption email services by recipient workflow, metadata exposure, interoperability, and operational fit. End to end encryption email services are best chosen by the path a recipient can actually use to decrypt and reply. Proton Mail is a fit for Proton contacts, PGP users, or password-protected external messages. Gmail client-side encryption can fit a Google Workspace deployment that meets Google's documented edition and external-recipient requirements, including beta access for its Assured Controls path. S/MIME is a standards-based option for a managed, compatible group. None of these choices replaces sender authentication. ## Quick takeaways - Confirm whether the recipient can use the same encrypted service, PGP, a password-protected portal, or S/MIME before choosing a provider. - Proton Mail and Gmail client-side encryption document distinct external-recipient paths, but Gmail's external end to end encryption depends on the documented Workspace configuration and, for the Assured Controls path, beta access. - A password-protected secure-message workflow requires a safe method to share the password and support the recipient. - S/MIME is an interoperable encrypted-message format. Confirm certificate handling and mail-client support in the deployment you plan to use. - Encryption protects message confidentiality. SPF, DKIM, and DMARC address whether mail claiming to be from a domain is authenticated. ## Who this comparison is for This comparison is for privacy-conscious teams, regulated professional groups, and individuals selecting a primary encrypted email service or a controlled encrypted-email workflow. It is not a buying guide for bulk senders, marketing platforms, or transactional email. Those senders need a deliverability and authentication program, including [SPF](/learning/what-is-spf), [DKIM](/learning/what-is-dkim), and [DMARC](/learning/what-is-dmarc), alongside any confidentiality control. ## How the options were evaluated The criteria come before the recommendation because encrypted email fails in practice when the recipient path is unclear. Checked on 2026-07-28, the comparison evaluates each option on four questions: - **Recipient workflow:** Can the recipient decrypt in their ordinary mailbox, or must they use an account, PGP key, password, portal, or certificate? - **What is protected:** What does the provider document as end to end encrypted, and what metadata remains outside that protection? - **Interoperability:** Does the service document a way to exchange encrypted email with someone outside its own service? - **Operating model:** Who provisions keys, shares passwords, recovers access, and supports recipients when a message cannot be opened? This is an evidence-led comparison, not a claim that a missing feature is absent. Verify current plans, retention, legal requirements, mobile-client support, and recovery controls with the provider before procurement. ## Proton Mail - **Best fit:** Teams or correspondents who can use Proton Mail together, or who can use PGP or a password-protected external-message workflow. - **Relevant evidence:** [Proton's encryption documentation](https://proton.me/support/proton-mail-encryption-explained) says messages between Proton Mail addresses are end to end encrypted. For non-Proton recipients, it documents password-protected email and PGP options; otherwise, the message uses TLS in transit rather than default end to end encryption. - **Tradeoff:** [Proton's metadata explanation](https://proton.me/support/proton-mail-encryption-explained) says subject lines and sender and recipient addresses are not end to end encrypted. An external recipient path still requires coordination. Choose Proton Mail when the people who exchange sensitive messages can standardize on Proton or already have a workable PGP process. Treat a password-protected message as a recipient-access workflow, including a safe way to share the password and help the recipient open the message. ![Proton Mail compose window with the External encryption control highlighted.](/images/editorial/end-to-end-encryption-email-services/proton-mail-external-encryption-button.png "677x551") *Source: [Proton Support, “Password-protected Emails”](https://proton.me/support/password-protected-emails), checked July 29, 2026. First-party public interface excerpt, unmodified.* ## Gmail client-side encryption - **Best fit:** Google Workspace organizations that have the documented client-side encryption entitlement and want a managed deployment. - **Relevant evidence:** [Google's Gmail client-side encryption documentation](https://support.google.com/mail/answer/13317990?hl=en) says encryption is handled in the browser before data is transmitted to or stored in Google's cloud. It lists the Workspace editions that can use client-side encryption. Its documented path for sending end to end encrypted messages to anyone without S/MIME requires Gmail with Assured Controls and access to the beta. - **Tradeoff:** External end to end encryption is not the default path for every Gmail account or Workspace edition. Without Assured Controls, Google's documented external CSE path uses S/MIME and a prior exchange of digital signatures. Choose Gmail client-side encryption when the organization can verify its Workspace edition and whether it has both Assured Controls and beta access, or needs the documented S/MIME path instead. Test the recipient opening and reply path with representative external recipients before using it for sensitive communications. ## S/MIME as a managed alternative - **Best fit:** A group that has selected an S/MIME-capable mail deployment and can confirm that its recipients can use that deployment. - **Relevant evidence:** [RFC 8551](https://www.rfc-editor.org/rfc/rfc8551/) defines the S/MIME 4.0 message format for encrypted and signed MIME messages, while [RFC 8550](https://www.rfc-editor.org/rfc/rfc8550/) defines S/MIME certificate handling. - **Tradeoff:** S/MIME is a standard rather than a hosted encrypted-email service. [Microsoft's email-encryption comparison](https://learn.microsoft.com/en-us/purview/email-encryption) says S/MIME uses unique digital certificates and recipient public keys, while recipients maintain their own private keys. Certificate issuance, discovery, revocation, device deployment, and recovery depend on the mail deployment and policy you choose. This is an implementation inference, not a feature claim about every S/MIME service. Choose S/MIME when certificate governance and recipient compatibility are established requirements. If outside recipients cannot consistently receive and decrypt S/MIME, compare Proton Mail's password workflow with Gmail client-side encryption's documented external-recipient path instead. ![Outlook compose window showing encryption options under the Options tab.](/images/editorial/end-to-end-encryption-email-services/outlook-compose-encrypt-options.png "700x409") *Source: [Microsoft Learn, “Security and compliance in new Outlook for Windows”](https://learn.microsoft.com/en-us/microsoft-365-apps/outlook/security/security-compliance), checked July 29, 2026. First-party public interface excerpt, unmodified.* ## How to choose Use these decisions in order. The recommendation is conditional because the recipient workflow is more important than a provider's marketing label. ### 1. Map the recipient population List the parties who must exchange sensitive messages and sort them by their available path: same provider, OpenPGP, S/MIME certificate, password-protected secure message, or no supported path. Do not assume that ordinary SMTP delivery is end to end encrypted. [Proton's encryption documentation](https://proton.me/support/proton-mail-encryption-explained) says external delivery without its encrypted options is protected by TLS in transit, which is a different boundary than end to end encryption. ### 2. Choose the lowest-friction secure path you can support If most correspondents can use the same provider, provider-to-provider encryption can be the simplest path. If they cannot, compare Proton Mail's password workflow with Gmail client-side encryption's documented external-recipient path, then decide whether your organization can manage an S/MIME deployment. Test with a real recipient group before moving sensitive workflows. ### 3. Keep confidentiality separate from domain authentication Encrypted email does not prove that a message claiming to be from your domain was authorized to send. Review your domain with a [DMARC check](/tools/dmarc) and use [email authentication guidance](/learning/what-is-email-authentication-and-why-does-it-matter) for SPF, DKIM, and DMARC. This is a separate control plane from encryption and does not inspect or decrypt the message body. ```yaml encrypted_email_service_decision: checked_on: "2026-07-28" recipient_path: "same provider | PGP | password workflow | S/MIME" protected_content: "documented and reviewed" metadata_boundary: "documented and accepted" key_or_password_owner: "named person or team" support_test: "completed with representative recipient" open_question: "Can every required recipient decrypt and reply safely?" ``` Use the record to capture evidence rather than assuming that an encryption label covers every message, recipient, and metadata field. For a provider-specific implementation of these authentication checks, see [How do I send a secure email in Gmail?](/learning/how-do-i-send-a-secure-email-in-gmail). ## Sources and further reading - [Proton Mail encryption explained](https://proton.me/support/proton-mail-encryption-explained) - [Gmail client-side encryption documentation](https://support.google.com/mail/answer/13317990?hl=en) - [RFC 8551: S/MIME 4.0 Message Specification](https://www.rfc-editor.org/rfc/rfc8551/) - [RFC 8550: S/MIME 4.0 Certificate Handling](https://www.rfc-editor.org/rfc/rfc8550/) - [Microsoft email-encryption comparison](https://learn.microsoft.com/en-us/purview/email-encryption) ## Frequently asked questions ### Is TLS the same as end to end encryption? No. TLS protects a connection in transit. End to end encryption is a message-access model in which the intended endpoints can decrypt the protected content. A provider may document TLS for ordinary external delivery and a separate workflow for end to end encrypted messages. ### Can I send encrypted email to a Gmail or Outlook address? Yes, if the service and recipient path support it. Proton documents password-protected messages and PGP for external recipients. Gmail client-side encryption can support external end to end encryption with Assured Controls and beta access, or an S/MIME path after signature exchange. Test the recipient experience before relying on it. ### Does end to end encryption hide email metadata? Not always. Providers document different boundaries for subjects, addresses, and routing data. Proton documents that message subjects and sender and recipient addresses are not end to end encrypted. Review the provider's current documentation for the fields that matter to your use case. ### Is S/MIME better than an encrypted email service? Only when its certificate and client requirements fit the recipient group. S/MIME can suit a managed, compatible community. Proton Mail or qualifying Gmail client-side encryption can be easier when recipients need a documented password-protected or Workspace-managed workflow instead of an organization-managed S/MIME deployment. ### Does encrypted email stop phishing or domain spoofing? No. Encryption protects the confidentiality of a message you send through its supported path. It does not stop someone else from sending mail that impersonates your domain. SPF, DKIM, and DMARC provide the authentication evidence used to address that separate problem. --- # SPF and Constant Contact: what to configure Canonical: https://www.palisade.email/learning/spf-constant-contact > Constant Contact does not require its servers in SPF. Self-authenticate with DKIM and DMARC, then verify a campaign from your custom domain. For Constant Contact Email and Digital Marketing, do not add Constant Contact server addresses to your domain's SPF record. Constant Contact says receivers check its envelope domain, `@in.constantcontact.com`, so SPF cannot align with your visible From domain. Instead, self-authenticate your custom domain with the account-generated DKIM CNAME or TXT records and DMARC record, then send a test campaign. Keep any existing SPF policy for the services that actually use its envelope domain. ## Quick takeaways - Do not add a Constant Contact `include:` mechanism or IP address to SPF for its Email and Digital Marketing product. - SPF alignment cannot pass for that sending path because Constant Contact uses `@in.constantcontact.com` for the Header or Bounce address. - DMARC can still pass when self-authentication produces DKIM alignment with the visible From domain. - Choose DKIM CNAME records for the normal single-account path, or DKIM TXT when several Constant Contact accounts use the same domain. - Copy the generated DNS names and values only from the account and domain you are configuring. ## What should I check before configuring Constant Contact? Confirm that you are using Constant Contact's Email and Digital Marketing product, have access to DNS for the visible From domain, and can use a verified address at that domain. The [current authentication overview from Constant Contact](https://knowledgebase.constantcontact.com/email-digital-marketing/tutorials/KnowledgeBase/5865-Understanding-email-authentication?lang=en_US) distinguishes this product from Lead Gen & CRM, which has a different authentication workflow. Check the domain's existing SPF policy before making any DNS change. Do not add a second `v=spf1` TXT value and do not remove mechanisms for other active senders. Constant Contact's documented path does not need a new SPF authorization for its marketing sends. > Copy the DKIM and DMARC names and values from the Constant Contact account that owns this domain. Do not publish a selector, target, TXT value, or DMARC value copied from another account or an online example. ## Which setup method should I use? Use **Self-authenticate using DKIM CNAME records** for the normal path. Constant Contact calls it the simplest and most secure option. Use **Self-authenticate using DKIM TXT record** when multiple Constant Contact accounts use the same domain. The [self-authentication instructions](https://knowledgebase.constantcontact.com/email-digital-marketing/tutorials/KnowledgeBase/5932-Self-authenticate-your-emails-using-your-own-domain?lang=en_US) state that the account generates the DKIM record information and the DMARC policy information for both paths. This is not an SPF-record setup. If another platform sends mail with an envelope domain under your control, assess that sender separately with the [SPF record checker](/tools/spf). Do not treat a successful DNS lookup as proof that a Constant Contact campaign used DKIM or that DMARC passed. ## How do I configure authentication for Constant Contact? ### 1. Open the self-authentication settings In Constant Contact, select your profile name in the upper-right, choose **Settings**, open **Advanced settings**, and select **Add self-authentication**. This current path and the button labels are documented in Constant Contact's [self-authentication guide](https://knowledgebase.constantcontact.com/email-digital-marketing/tutorials/KnowledgeBase/5932-Self-authenticate-your-emails-using-your-own-domain?lang=en_US). Do not rely on this prose as a substitute for a current screen review. ![Constant Contact profile menu showing the Settings option](/images/editorial/spf-constant-contact/constant-contact-settings-menu.webp "992x570") *Source: [Constant Contact's self-authentication guide](https://knowledgebase.constantcontact.com/email-digital-marketing/tutorials/KnowledgeBase/5932-Self-authenticate-your-emails-using-your-own-domain?lang=en_US), captured from its published documentation on August 10, 2026. This is the vendor's example account, not your account.* ![Constant Contact Advanced settings with Add self-authentication highlighted](/images/editorial/spf-constant-contact/constant-contact-add-self-authentication.webp "1000x600") *Source: [Constant Contact's self-authentication guide](https://knowledgebase.constantcontact.com/email-digital-marketing/tutorials/KnowledgeBase/5932-Self-authenticate-your-emails-using-your-own-domain?lang=en_US), captured from its published documentation on August 10, 2026. It shows the entry point; generated records remain specific to your own account.* ### 2. Select the domain and DKIM method Choose the verified custom domain used by the campaign's From address. Select the CNAME method unless the same domain is used by multiple Constant Contact accounts, in which case select the DKIM TXT method. Constant Contact documents that an account can authenticate one domain and that the TXT option is intended for the multi-account case. ### 3. Publish the account-generated DNS records Use the copy controls in Constant Contact to obtain each DKIM record and the DMARC record, then publish them at the DNS provider that hosts the domain. The names, selectors, targets, and public-key values are account-generated. They are not safe to reuse across tenants. **Record type:** `CNAME` or `TXT`, as generated by Constant Contact **Host and value:** account-generated ```text Copy the DKIM and DMARC record names and values from Constant Contact for this exact domain. ``` The code block describes the procedure only. Do not publish the text above as a DNS record. Keep the domain's existing SPF policy unless you are separately changing a sender that SPF evaluates. ![Constant Contact authentication setup flow](/images/editorial/spf-constant-contact/spf-constant-contact-authentication-flow.webp "1200x676") *Source: Palisade.* ### 4. Check status and activate After the DNS records have propagated, return to the same self-authentication area and select **Check status** or **Activate**. Constant Contact says propagation can take from a couple of hours to a couple of days and directs readers to activate only when the records are ready. If status does not become ready, compare every published name and value with the current account-generated values before changing mail flow. ### 5. Send a real test campaign Copy a recent campaign, send it to a private test list, and use a From address with the authenticated domain. Constant Contact's [test instructions](https://knowledgebase.constantcontact.com/email-digital-marketing/tutorials/KnowledgeBase/5932-Self-authenticate-your-emails-using-your-own-domain?lang=en_US) recommend this before a production send. Keep the delivered message for header inspection. ## How does this setup affect DMARC? For this Constant Contact path, SPF does not align with the visible From domain because the Header or Bounce address is `@in.constantcontact.com`. Constant Contact explicitly says there is no requirement for SPF alignment when DMARC can pass through aligned DKIM. When self-authentication is active and the campaign uses a custom-domain From address, Constant Contact says the message is DKIM aligned for DMARC purposes. Review the [DMARC alignment guide](/learning/check-dmarc-alignment) before changing a policy from monitoring to enforcement. ## How do I validate the setup? ### Check public DNS Query the exact CNAME or DKIM TXT owner name that Constant Contact generated, plus the DMARC record at `_dmarc.your-domain.example`. The [DKIM checker](/tools/dkim) can confirm a selector's public DNS answer, while the [DMARC checker](/tools/dmarc) can confirm the published DMARC policy. Do not test SPF by adding Constant Contact to the root policy because that is not the documented sending identity for this product. ### Check the vendor status Return to **Settings**, **Advanced settings**, and the self-authentication state. The expected outcome is a ready state followed by activation. This validates that Constant Contact can resolve the account-generated records. It does not prove a recipient accepted a particular campaign. ### Inspect a delivered message Open the full headers of the test campaign in the receiving mailbox. In the receiver-added `Authentication-Results` field, look for a DKIM pass whose `header.d` matches the visible From domain or its organizational domain, then compare the DMARC result with that visible From domain. [RFC 8601](https://www.rfc-editor.org/rfc/rfc8601.html) defines the Authentication-Results header; the receiver, not the sender, adds the result you should trust. ### Review DMARC reports Review DMARC aggregate reports after campaigns have run through the normal sending schedule. Look for the Constant Contact source, the visible From domain, DKIM result, and alignment result. Reports reveal observed receiver traffic, but they cannot replace the vendor status check or a delivered-message header from your own test. ## Troubleshooting ### I added Constant Contact to SPF and nothing improved Remove only the Constant Contact mechanism you added after confirming that no other service uses it. Constant Contact's official documentation says its servers do not need to be added to your SPF record for this product. Preserve authorizations for other active senders, and keep one SPF policy at each exact DNS name. ### Check status does not find the DNS records Compare the DNS owner name and value character-for-character with the current account-generated record. Check whether the DNS provider automatically appends the domain suffix, then allow the documented propagation window before retrying. Do not substitute a record from another Constant Contact account. ### My campaign uses an unauthenticated From address Use a verified From address under the authenticated domain. Constant Contact notes that, after self-authentication, a From address outside that domain is likely to bounce. Test with a private list before sending to campaign contacts. ## Check the public records before you send After you publish the generated records, run the [Email Security Score](/tools/email-security-score) for the visible From domain. It can inspect the public SPF, DKIM, and DMARC posture that recipients can query. The score cannot confirm that Constant Contact activated self-authentication, read a private campaign, prove DKIM alignment for an unseen message, or guarantee inbox placement. Use it with the vendor status and delivered-message checks above. ## Sources and further reading - [Constant Contact: Understanding email authentication](https://knowledgebase.constantcontact.com/email-digital-marketing/tutorials/KnowledgeBase/5865-Understanding-email-authentication?lang=en_US) - [Constant Contact: Self-authenticate your emails using your own domain](https://knowledgebase.constantcontact.com/email-digital-marketing/tutorials/KnowledgeBase/5932-Self-authenticate-your-emails-using-your-own-domain?lang=en_US) - [RFC 8601: Authentication-Results](https://www.rfc-editor.org/rfc/rfc8601.html) ## Frequently asked questions ### Do I add Constant Contact to my SPF record? No. For Constant Contact Email and Digital Marketing, receivers check Constant Contact's envelope domain rather than your visible From domain. Add no Constant Contact SPF mechanism unless Constant Contact documents a different sending product and identity for your account. ### Can SPF alignment pass for a Constant Contact campaign? No. Constant Contact says its Header or Bounce address uses `@in.constantcontact.com`, which does not match a custom visible From domain. DMARC can still pass through aligned DKIM after self-authentication. ### Should I use DKIM CNAME or TXT records? Only use CNAME records for the normal single-account setup. Use the DKIM TXT option when multiple Constant Contact accounts use the same domain. Copy the exact record type, name, and value generated in the account. ### Does self-authentication replace my existing SPF record? No. Self-authentication configures DKIM and DMARC for the Constant Contact path. Keep the SPF policy that authorizes the services whose envelope or HELO identities actually use the DNS name being evaluated. ### How long should I wait before activating self-authentication? Constant Contact says newly published authentication records can take from a couple of hours to a couple of days to propagate. Check status only after public DNS returns the generated records, then activate when the account marks them ready. --- # 2 factor authentication Yahoo email: what to enable Canonical: https://www.palisade.email/learning/2-factor-authentication-yahoo-email > Yahoo calls it two-step verification. Pick a second factor you can actually recover, and create app passwords for older mail clients that still need them. Yahoo Mail uses Yahoo Account two-step verification to require a second proof when a new device or browser signs in. Yahoo documents push notifications, phone verification, authenticator-app codes, and security keys as available methods. Choose a method you can recover, keep recovery details current, and use Yahoo's current [two-step verification instructions](https://help.yahoo.com/kb/add-two-step-verification-extra-security-sln5013.html) to make the account change. This is account-login protection, not SPF, DKIM, or DMARC for a domain you send from. ## Quick takeaways - Yahoo calls the feature 2-step verification, although people often search for 2 factor authentication. - An authenticator app requires at least two recovery methods on the Yahoo account, according to Yahoo. - Yahoo says Account Key must be disabled before 2-step verification can be enabled. - Save any emergency recovery code where you can access it without the Yahoo account. - Third-party mail apps may need an app password after you turn on 2-step verification. ## What Yahoo two-step verification protects Yahoo states that two-step verification adds a code or other second step when a new device or browser signs in. That can reduce the usefulness of a stolen password, but it does not make a phishing page safe or reverse a compromise that has already happened. If you entered a Yahoo password or approval code into a suspicious site, start with the recovery steps in [what to do after a phishing link](/resources-post/what-to-do-if-you-clicked-on-a-phishing-link) before treating two-step verification as the only response. Yahoo's documented options are a prompt in a Yahoo app, a code delivered to a phone, an authenticator-app code, or a security key. The precise choices available can depend on the account and recovery setup, so use the current [Yahoo two-step verification help](https://help.yahoo.com/kb/add-two-step-verification-extra-security-sln5013.html) rather than relying on an old screen capture or a copied menu path. ## Choose the second factor before you turn it on Start with the method you can still use if your primary phone is lost. Yahoo's help says an authenticator-app setup needs at least two recovery methods, and its security-key guidance says an emergency recovery code is provided during setup. Yahoo also documents that its Account Key and two-step verification are not used together, so an account using Account Key needs that feature disabled before the two-step option can be enabled. Use this decision record before following Yahoo's current instructions: ```text Yahoo account sign-in decision Account Key enabled? Disable it before selecting 2-step verification. Authenticator app chosen? Confirm two recovery methods are available first. Security key chosen? Store the emergency recovery code separately. Third-party mail app? Plan to create an app-specific password if the app needs one. ``` ![Yahoo two-step verification setup decision checklist](/images/editorial/2-factor-authentication-yahoo-email/2-factor-authentication-yahoo-email-checklist.webp "1200x524") *Source: Palisade.* The [Yahoo Account Key documentation](https://help.yahoo.com/kb/account/disable-enable--step-verification-sln25781.html) explains how to move back to password sign-in, and Yahoo's [security-key guidance](https://help.yahoo.com/kb/mail/enable-security-key-sln35380.html) describes the supported key requirements. Those pages are the source of truth for account-specific prompts and recovery options. ## Keep Yahoo Mail working in other apps Two-step verification can change how an older or non-Yahoo mail client signs in. Yahoo says a third-party mail app that does not use Yahoo's branded sign-in page may need an app password. An app password is separate from the main Yahoo password, and Yahoo says it remains active until you remove it. Before changing a mail client, record which app and device use the Yahoo account. Then use Yahoo's [app-password instructions](https://help.yahoo.com/kb/mail/generate-password-sln15241.html) to create a separate password only for that app when needed. Remove an app password you no longer need instead of sharing or reusing it. ## Verify the account is still recoverable After the account change, test a sign-in only from a device and browser you control. Confirm that the chosen second factor works, that the recovery details are current, and that a lost-device plan does not depend on the same mailbox. Yahoo says it sends alerts when two-step verification is turned on or off, or when the verification method changes. Review any security alert you did not expect in the [Yahoo security changes help](https://help.yahoo.com/kb/account/understanding-security-yahoo-account-sln37259.html). For broader account protection, [prevent account hijacking](/learning/threats) explains why strong factors and session recovery matter after credentials are exposed. If a suspicious email prompted this work, [learn how to recognize phishing](/learning/what-is-phishing) before opening another sign-in link. ## Check the message before you sign in If an unexpected message sent you toward a Yahoo sign-in page, use [Yahoo and Gmail email error-code guidance](/learning/how-can-you-resolve-yahoo-and-gmail-email-error-codes) only for sender-side SMTP failures. It cannot verify a Yahoo account or enable two-step verification. For a suspicious account message, open Yahoo directly rather than following the message link. ## Sources and further reading - [Yahoo Help: Add two-step verification for extra security](https://help.yahoo.com/kb/add-two-step-verification-extra-security-sln5013.html) - [Yahoo Help: Use and manage Yahoo Account Key](https://help.yahoo.com/kb/account/disable-enable--step-verification-sln25781.html) - [Yahoo Help: 2-Step Verification with a Security Key](https://help.yahoo.com/kb/mail/enable-security-key-sln35380.html) - [Yahoo Help: Generate and manage third-party app passwords](https://help.yahoo.com/kb/mail/generate-password-sln15241.html) - [Yahoo Help: Understanding security changes on your Yahoo account](https://help.yahoo.com/kb/account/understanding-security-yahoo-account-sln37259.html) ## Frequently asked questions ### Is 2 factor authentication available for Yahoo Mail? Yes. Yahoo calls it 2-step verification and documents several methods, including a Yahoo-app prompt, phone verification, authenticator-app codes, and a security key. The methods shown can depend on the account's recovery setup. ### Do I need to turn off Yahoo Account Key first? Yes. Yahoo says Account Key must be disabled before you enable two-step verification. Follow Yahoo's current Account Key instructions because the available sign-in choices can vary by account. ### Can I use an authenticator app with Yahoo? Yes. Yahoo documents authenticator-app verification. It also says that the account must have at least two recovery methods before that option is available. ### Will Yahoo two-step verification affect Outlook or another mail app? Yes, it may. Yahoo says third-party mail apps that do not use Yahoo's branded sign-in page may require an app password. Generate a separate app password only when Yahoo's current instructions call for it. ### Does Yahoo two-step verification stop phishing? No. It adds protection at sign-in, but it does not make a fraudulent site trustworthy or undo information already submitted to one. Treat a suspicious login page or unexpected approval request as a separate security incident. --- # Abnormal email security Canonical: https://www.palisade.email/learning/abnormal-email-security > Abnormal email security is an API-connected cloud email-security offering. Compare its buyer evidence with gateway and DMARC boundaries in practice. Choose Abnormal email security if an API-connected cloud email-security approach fits your Microsoft 365 or Google environment and you can evaluate its permissions and operational results in your tenant. Choose an MX-routed secure email gateway when mail routing is the architecture you need to assess. Keep sender-domain authentication separate: DMARC validates use of the visible From domain, but it does not establish that an inbound security product will detect or handle a particular message. ## Quick takeaways - Abnormal publicly positions Email Security as cloud email security with API deployment. - Abnormal's product material describes behavioral models related to people and vendors connected to an organization. - API-connected email security and an MX-routed secure email gateway require different deployment evidence. - DMARC covers visible From-domain validation, policy preferences, and reporting requests. - A buyer evaluation needs tenant-specific evidence for permissions, remediation, false-positive handling, and rollback. - A public DMARC lookup can document published sender-domain policy, but cannot test an inbound filter. ## Who this comparison is for This comparison is for a security or email administrator deciding how to evaluate Abnormal's publicly described Email Security offering alongside two distinct controls: an MX-routed secure email gateway and DMARC. The decision is architectural before it is commercial. An API-connected security product raises questions about connection scope, access permissions, message handling, native-control coexistence, and the evidence available after an event. A gateway evaluation centers on mail routing and gateway operation. DMARC is a sender-domain authentication protocol, so its evidence is public DNS, delivered-message authentication results, and aggregate reports. If the wider task is selecting among anti-phishing products, use [Palisade's anti-phishing software comparison](/learning/anti-phishing-software). For a broader view of vendor categories, see the [email-security comparison hub](/compare). This page is narrower: it explains what Abnormal's public material says and what evidence a buyer should collect before drawing conclusions about a tenant. ## How the options were evaluated The criteria below use current public primary sources checked on August 13, 2026. They do not treat vendor positioning as proof of a tenant outcome. - Deployment model: Whether the option is described as API-connected cloud email security, an MX-routed gateway model, or sender-domain authentication. - Evidence boundary: What a public description, DNS record, message, or tenant trial can establish. - Operational review: What the buyer must verify about authorization, investigation, remediation, release, and rollback. - Authentication scope: Whether the control validates sender-domain use, evaluates inbound messages, or both. - Unknowns: Any tenant behavior, performance result, or configuration effect that public documentation does not establish. A documented capability is evidence of the vendor's published description. A successful tenant trial is evidence only for the approved scenario and configuration tested. Missing public detail is an open question, not proof that a capability is absent. ## Abnormal email security [Abnormal's Email Security product page](https://abnormal.ai/products/cloud-email-security) describes a cloud email-security offering that uses behavioral models for people and vendors connected to an organization. The same public material describes API deployment and Microsoft 365 and Google coverage. Those are vendor statements about product positioning and deployment, not independently verified detection or remediation outcomes in every tenant. - Best fit: Teams evaluating an API-connected cloud email-security product for Microsoft 365 or Google and prepared to review its proposed authorization and operating model. - Relevant evidence: Abnormal's [Inbound Email Security data sheet](https://files.abnormalsecurity.com/production/files/IES-Data-Sheet-March-2026.pdf?dm=1773676381) describes the vendor's Inbound Email Security offering and its behavioral approach. Check deployment statements against the buyer's own identity, permissions, and mail-handling requirements. - Tradeoff: Public product material does not prove how a specific tenant's permissions, native controls, approved remediation actions, or false-positive workflow will behave. A useful evaluation begins with scenarios that reflect the risks the organization actually needs to test. Supplier impersonation, display-name impersonation, compromised-account activity, and known-good business mail are different cases. Define which cases are authorized, who owns the evidence, and what action may be reversed before the evaluation starts. ## MX-routed secure email gateway An MX-routed secure email gateway is a separate architecture, not a synonym for API-connected cloud email security. A gateway evaluation asks how messages route through the service, how the service operates at the mail boundary, and how that path interacts with existing mail infrastructure. See [what an email security gateway is](/learning/email-security-gateway) for the three deployment models. - Best fit: Teams whose planned security design depends on evaluating mail routing and gateway operation. - Relevant evidence: A gateway assessment needs the documented mail path, authoritative DNS answers, configured MX records, and delivered messages from the actual production route. - Tradeoff: Gateway evidence cannot be assumed to describe the permissions model or operational behavior of an API-connected product. Do not label Abnormal as an MX-routed gateway based on a general email-security category. Abnormal's public product material describes API deployment. The buyer should confirm the architecture proposed for the specific tenant and document any coexistence with native controls. > A green vendor status or a published DNS record is not proof that production messages follow the intended path. Validate the exact sending and receiving path with real delivered-message evidence before relying on a mail-flow change. ## DMARC sender-domain authentication [DMARC, specified in RFC 9989](https://www.rfc-editor.org/rfc/rfc9989.html), lets a domain owner enable validation of the domain used in a message's visible From field and publish handling preferences and reporting requests. This is a different control boundary from inbound behavioral email security. - Best fit: Domain owners who need to publish sender-domain authentication policy and review authentication evidence for domains they control. - Relevant evidence: The DMARC DNS record, a real message's authentication results from the production path, and aggregate reports after data accumulates. - Tradeoff: DMARC does not establish whether an inbound product detected a particular impersonation attempt, handled a malicious attachment, or released a legitimate message. The following is an illustrative record shape only. Publish the record and reporting addresses appropriate for your own domain and reporting destination. ```text _dmarc.yourdomain.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com" ``` ![Decision map for separating API-connected email security, MX-routed gateway, and DMARC evaluation evidence](/images/editorial/abnormal-email-security/abnormal-email-security-evaluation-boundaries.webp "1200x738") *Source: Palisade.* ## How to choose Choose Abnormal when the proposed API-connected deployment fits the tenant and the buyer can run an authorized evaluation with evidence for the operational questions that public product pages cannot answer. Choose a gateway approach when the required control point is mail routing. Use DMARC alongside either approach for sender-domain authentication, not as a replacement for inbound threat evaluation. Use the same evidence scorecard for each option: ```yaml option: Abnormal email security checked_on: 2026-08-13 best_fit: API-connected cloud email-security evaluation for Microsoft 365 or Google verified_evidence: - Abnormal publicly describes API deployment - Abnormal publicly describes behavioral models for people and vendors open_question: Tenant-specific permissions, message actions, false-positive handling, and rollback behavior option: MX-routed secure email gateway checked_on: 2026-08-13 best_fit: Mail-routing and gateway-operation evaluation verified_evidence: - The buyer can document the intended MX and message path open_question: Interaction with the tenant's existing routing and native controls option: DMARC checked_on: 2026-08-13 best_fit: Sender-domain authentication and policy publication verified_evidence: - RFC 9989 defines visible From-domain validation, policy preferences, and reports open_question: Which production senders authenticate and align after reports accumulate ``` Collect these items before deciding: - The proposed connection and permissions scope, with approval from the relevant identity and security owners. - A documented baseline for native email controls and the current mail path. - Authorized representative cases, including known-good business messages and approved impersonation or compromised-account scenarios. - Timestamps and evidence for investigation, remediation, release, and rollback for each scenario. - A named evidence owner who can retain the results and approve any production change. Validate across four layers where they apply. Check DNS through the authoritative server and a public resolver. Confirm the vendor's current status in the tenant. Inspect a real delivered message from the exact production path. Review DMARC aggregate reports once data accumates. Each layer answers a different question. ## Check the published DMARC record beside the evaluation Use Palisade's [DMARC checker](/tools/dmarc) to inspect the published DMARC record for a domain in scope after documenting the current mail path and native-control baseline. Keep the result with the evaluation record so the team can distinguish sender-domain policy from inbound-filter evidence. A public DNS check cannot evaluate Abnormal, inspect a tenant, reproduce a detection, measure message timing, test permissions, repair a false positive, monitor future tenant state, or prove inbound-filter effectiveness. ## Sources and further reading - [Abnormal Email Security product page](https://abnormal.ai/products/cloud-email-security) - [Abnormal Inbound Email Security data sheet](https://files.abnormalsecurity.com/production/files/IES-Data-Sheet-March-2026.pdf?dm=1773676381) - [RFC 9989: Domain-based Message Authentication, Reporting, and Conformance](https://www.rfc-editor.org/rfc/rfc9989.html) ## Frequently asked questions ### Is Abnormal email security a secure email gateway? Not necessarily. Abnormal's public materials describe an API-connected cloud email-security approach. An MX-routed secure email gateway is evaluated through mail-routing and gateway-operation evidence. Confirm the proposed architecture, authorization scope, and message path for the tenant. ### Does Abnormal email security replace DMARC? No. DMARC validates authorized use of the visible From domain and publishes handling preferences and reporting requests. An inbound email-security product may evaluate other message and behavioral signals, but it does not replace sender-domain authentication or DMARC reporting. ### Can a DMARC lookup test Abnormal email security? No. A DMARC lookup can inspect a domain's published authentication policy. It cannot access an Abnormal tenant, test permissions, reproduce a detection, measure remediation timing, or establish whether a particular message was handled correctly. ### What should a buyer test during an Abnormal evaluation? Start with the proposed connection scope and the native-control baseline. Then test authorized representative threat scenarios and known-good business messages. Retain evidence for detection, investigation, remediation, release, rollback, false positives, and the administrator effort required for the same cases. ### Does API deployment prove that mail flow will not change? No. A public deployment description does not prove the effects of a particular tenant's permissions, native controls, remediation settings, or operating procedures. Document the proposed mail path and validate it with real delivered-message evidence before relying on a production result. --- # Avanan email security Canonical: https://www.palisade.email/learning/avanan-email-security > Avanan is Check Point's API-based email protection. What it inspects, where it sits in your mail flow, and what it doesn't do for domain authentication. Choose Avanan email security if your organization needs Check Point's documented API-based inline protection for supported SaaS email applications and can validate its fit in the tenant. Choose a sender-authentication workflow alongside it when the question is whether mail using your domain passes SPF, DKIM, and DMARC. These products address different evidence: Avanan evaluates email threats and configured handling, while sender authentication establishes domain identity signals. ## Quick takeaways - Check Point documents Avanan as API-based inline protection for supported SaaS applications. - Check Point's Email Protection documentation lists Microsoft Exchange Online and Gmail as supported email applications. - Check Point says Avanan sends intercepted email to ThreatCloud for analysis before recipient delivery. - A malicious verdict follows the tenant's configured workflow, so public documentation cannot prove a particular message outcome. - Avanan email security and sender-domain authentication solve separate email-security problems. - Public documentation does not show a tenant's license, policies, security events, or quarantined messages. ## Who this comparison is for This comparison is for an email-security administrator evaluating Avanan, now documented by Check Point, as part of an inbound-email protection decision. It is also useful when a buyer needs to separate a product's documented architecture from the evidence needed to confirm that an individual organization's deployment works as intended. The decision is narrower than choosing a general email-security category. An organization may need protection for messages delivered to Microsoft Exchange Online or Gmail, a way to handle phishing and malware, and separate controls for mail sent using its own domain. Those needs overlap operationally, but they do not produce the same evidence. For a broader view of buyer choices, use Palisade's [email-security comparison hub](/compare). For a general deployment comparison, read [what an email security gateway is](/learning/email-security-gateway). ## How the options were evaluated The criteria below were checked against current first-party documentation on August 13, 2026. A documented capability counts only within the scope Check Point describes. A fact about an individual tenant remains unknown until the organization checks its authorized configuration and message evidence. - Deployment context: Whether the product is documented for the email application the organization uses. - Protection flow: What the vendor says happens to email before delivery and after a malicious verdict. - Operating evidence: What an administrator must inspect to confirm a tenant's actual policy and a message-specific outcome. - Sender-domain boundary: Whether the question concerns inbound threat handling or SPF, DKIM, and DMARC authentication. - Unknowns: Missing public documentation is recorded as an open question, not as proof that a capability is absent. The comparison does not treat a product description as proof that an organization's mail is protected. Confirm DNS separately, confirm the vendor's tenant status, inspect a real message from the relevant production path, and review DMARC aggregate reports after they accumulate. ## Avanan email security for API-based email protection Check Point's [Introduction to Avanan](https://sc1.checkpoint.com/documents/Avanan_Admin_Guide/Email_Security/Admin_Guide/Topics/introduction/introduction-to-Email-Security.html) describes Avanan as API-based inline protection for SaaS applications. For Email Protection, the same documentation names Microsoft Exchange Online and Gmail as supported applications. Check Point describes an email flow in which Avanan intercepts a sent email, sends it to ThreatCloud for analysis before recipient delivery, and applies the configured workflow when the verdict is malicious. The documentation also says Avanan inspects internal and outgoing traffic for data leakage, phishing, and malware. Check Point states that emails can be removed and modified after delivery when needed. - Best fit: Organizations evaluating documented API-based inline protection for supported Microsoft Exchange Online or Gmail environments. - Relevant evidence: Check Point documents pre-delivery ThreatCloud analysis, configured handling for malicious verdicts, and supported Email Protection applications. - Tradeoff: The public documentation does not establish the policy, licensing, event history, retained messages, or verdict for a specific tenant or message. ![Scope diagram showing documented Avanan email flow from sent message through ThreatCloud analysis and configured handling to recipient delivery](/images/editorial/avanan-email-security/avanan-email-security-scope.svg "1200x652") *Source: [Check Point, "Introduction to Avanan"](https://sc1.checkpoint.com/documents/Avanan_Admin_Guide/Email_Security/Admin_Guide/Topics/introduction/introduction-to-Email-Security.html), checked 2026-07-28.* A conventional secure email gateway can use a different routing model. Read [what an email security gateway is](/learning/email-security-gateway) when the buyer needs to compare that general model with Check Point's documented API-based approach. Do not assume that a category label proves identical deployment behavior. ## Palisade for sender-domain authentication work Palisade is a separate fit when the unresolved problem is sender-domain authentication rather than inbound threat analysis. Palisade is agentic DMARC software that analyzes DMARC aggregate-report data, identifies sending sources and authentication or alignment issues, and creates prioritized remediation tickets. It can propose the next DMARC policy step when evidence indicates a domain may be ready, while a human reviews the evidence and applies the DNS change. - Best fit: IT teams and MSPs that need to identify sending sources and work toward DMARC enforcement across one domain or many domains. - Relevant evidence: A sender-domain review begins with published SPF, DKIM, and DMARC records, then uses delivered-message and DMARC-report evidence to validate the production sending path. - Tradeoff: Palisade does not control an Avanan tenant's policies, message verdicts, quarantine handling, or a receiver's decision about a particular message. The distinction matters because [SPF](/learning/what-is-spf), [DKIM](/learning/what-is-dkim), and DMARC do not perform the same job as message threat analysis. [RFC 9989](https://www.rfc-editor.org/rfc/rfc9989.html) defines DMARC as a mechanism that uses domain-authentication results and a published policy to guide receiver handling. A passing published record does not prove that every future message will authenticate or reach the inbox. ![Decision boundary showing when to evaluate Avanan tenant protection, sender-domain authentication, or both](/images/editorial/avanan-email-security/avanan-email-security-decision-boundaries.webp "1200x676") *Source: Palisade.* ## How to choose Choose Avanan when the immediate decision is whether its documented Email Protection scope and API-based deployment fit the organization's supported SaaS email environment. Confirm that conclusion in the tenant, because the configured workflow determines how a malicious verdict is handled. Choose Palisade alongside Avanan when the immediate decision is whether all authorized senders using a domain authenticate and align for DMARC. The two evaluations can both be necessary. One cannot substitute for the other. Use this evidence scorecard before treating either product description as an operating result: ```yaml - option: "Avanan email security" checked_on: "2026-08-13" best_fit: "API-based inline Email Protection for documented supported SaaS email applications" verified_evidence: - "Check Point documents Microsoft Exchange Online and Gmail support." - "Check Point documents ThreatCloud analysis before recipient delivery." - "Malicious-email handling follows the configured tenant workflow." open_question: "Which policies, licenses, events, and message outcomes apply in this tenant?" - option: "Palisade" checked_on: "2026-08-13" best_fit: "DMARC operations and sender-domain authentication remediation" verified_evidence: - "DMARC work requires published DNS, message, and aggregate-report evidence." - "Palisade analyzes DMARC aggregate-report data and proposes remediation priorities." open_question: "Which production sending sources still fail authentication or alignment?" ``` > Do not change a DMARC policy based only on a public DNS result. Validate the authoritative DNS record, the vendor's status, a real delivered message from the production path, and DMARC aggregate-report data. ## Check the deployment fit before purchase Review [Check Point's Avanan product introduction](https://sc1.checkpoint.com/documents/Avanan_Admin_Guide/Email_Security/Admin_Guide/Topics/introduction/introduction-to-Email-Security.html) against the organization's documented email applications and required policy outcomes. Then use the authorized tenant's configuration and message evidence to confirm how the deployment behaves. This review cannot prove tenant policy, a quarantine action, a specific email verdict, or whether a sender domain will pass SPF, DKIM, or DMARC. ## Sources and further reading - [Check Point Avanan Administration Guide: Introduction to Avanan](https://sc1.checkpoint.com/documents/Avanan_Admin_Guide/Email_Security/Admin_Guide/Topics/introduction/introduction-to-Email-Security.html) - [Check Point Avanan Administration Guide: Getting started](https://sc1.checkpoint.com/documents/Avanan_Admin_Guide/Email_Security/Admin_Guide/Topics/getting-started/getting-started.html) - [RFC 9989: Domain-based Message Authentication, Reporting, and Conformance](https://www.rfc-editor.org/rfc/rfc9989.html) ## Frequently asked questions ### Is Avanan email security a secure email gateway? No. Check Point documents Avanan as API-based inline protection for supported SaaS applications. A secure email gateway can use a different routing model, so evaluate the documented deployment architecture and the organization's actual configuration. ### Does Avanan support Microsoft Exchange Online and Gmail? Yes. Check Point's Avanan introduction lists Microsoft Exchange Online and Gmail as supported Email Protection applications. That documentation does not show which policies or licenses apply in a particular tenant. ### Does Avanan replace SPF, DKIM, and DMARC? No. Avanan's documented Email Protection scope concerns threat analysis and configured message handling. SPF, DKIM, and DMARC address sender-domain authentication and receiver policy, so they require separate validation. ### Can Avanan remove a message after delivery? Yes. Check Point states that Avanan can remove and modify emails after delivery if needed. Public documentation cannot establish whether this occurred for a particular message in a particular organization. ### Can a public check reveal an Avanan tenant's policies? No. Public documentation can describe the product's scope, but it cannot reveal a tenant's policies, licensing, message events, quarantined items, or the verdict for an individual email. Those require authorized tenant evidence. --- # Barracuda email security Canonical: https://www.palisade.email/learning/barracuda-email-security > Barracuda email security: compare Barracuda Email Protection with Palisade by deployment scope, DMARC workflow, buyer fit, and DMARC evidence. Choose Barracuda Email Protection if your evaluation centers on protecting Microsoft 365 or Google Workspace mailboxes with Barracuda's published threat, account, data, and domain-fraud capabilities. Choose Palisade if the operating problem is DMARC adoption and enforcement across one or many domains, with an AI agent that analyzes aggregate-report data and prepares remediation work for human review. These products can address related email-security work, but they do not have the same primary job. ## Quick takeaways - Barracuda positions Email Protection as a suite that supplements Microsoft 365 and Google Workspace. - Barracuda lists Domain Fraud Protection as a feature for DMARC reporting and analysis, separate from inbound threat protection. - DMARC evaluates aligned SPF or DKIM results and communicates a domain owner's requested disposition to receivers. - A public DNS check can establish what a domain publishes today. It cannot inspect a Barracuda tenant, a licensed plan, a message verdict, or a receiver's private filtering decision. - Palisade is for teams that want an AI agent to do DMARC analysis and propose prioritized remediation work, while humans review evidence and apply changes. ## Who this comparison is for This comparison is for an IT administrator, security owner, or MSP deciding whether the immediate need is email-security protection around a mailbox environment or an operating workflow for sender-domain authentication. The distinction matters when both products appear in the same evaluation. A secure email platform can help protect users from malicious or unwanted inbound mail. [DMARC](/learning/what-is-dmarc) is concerned with mail that claims to use a sender domain and whether aligned SPF or DKIM authentication supports the domain's published policy. Read [AI powered email security: what the label actually covers](/learning/ai-powered-email-security) if the evaluation is using a broad "AI email security" label without a defined operating task. Use a product comparison only after writing down the evidence the team needs. For example, a Microsoft 365 tenant may need to test deployment and response workflows. A domain owner may instead need to inventory all sources sending as `yourdomain.com`, resolve authentication or alignment failures, and decide when report evidence supports a stricter DMARC policy. ## How the options were evaluated The criteria below were checked against vendor-published material on August 13, 2026. They are intended to keep product scope separate from a promised tenant outcome. - Buyer fit: the operating problem the documented product scope addresses. - Deployment scope: the mail environment or domain workflow described by the vendor. - Workflow: the evidence and follow-up work the product is described as supporting. - DMARC boundary: what the product can contribute to a sender-domain program, and what still requires protocol evidence and human approval. - Open questions: tenant-specific details that documentation cannot establish, including plan entitlement, configuration, message handling, and response results. A documented feature counts as vendor-published scope. It does not establish detection quality or a result in a particular tenant. Missing documentation is an open question, not proof that a capability is absent. ## Barracuda Email Protection Barracuda's [Email Protection overview](https://www.barracuda.com/products/email-protection) describes a product suite intended to supplement Microsoft 365 and Google Workspace. The same overview describes API-first deployment without MX-record changes for those environments. Barracuda's [features page](https://www.barracuda.com/products/email-protection/features) lists threat protection, account-takeover protection, encryption and data-loss prevention, incident response, training, backup, archiving, and Domain Fraud Protection. - Best fit: Teams evaluating a Barracuda product suite around a Microsoft 365 or Google Workspace mailbox environment. - Relevant evidence: Barracuda documents published feature categories, post-delivery capabilities, and API-first positioning for Microsoft 365 and Google Workspace in its Email Protection materials, checked August 13, 2026. - Tradeoff: A product page cannot establish which controls are licensed, enabled, or effective in one tenant. The buyer still needs plan-specific deployment documentation and test evidence from the intended mail path. Barracuda identifies Domain Fraud Protection as part of the Email Protection feature set. Its [feature description of Domain Fraud Protection](https://www.barracuda.com/products/email-protection/features) states that it provides DMARC reporting and analysis, visibility into sending systems, and passing or failing DMARC information. That scope is relevant when a team needs to understand legitimate and unauthorized use of a domain before considering a policy change. DMARC itself has a narrower protocol role. [RFC 9989 defines DMARC](https://www.rfc-editor.org/rfc/rfc9989) as an evaluation of aligned SPF or DKIM authentication, with a requested disposition that a receiver can apply. Inbound threat filtering and sender-domain authentication may support the same security program, but one does not replace the other. ![Scope map separating mailbox protection, sender-domain authentication, and tenant-specific evidence](/images/editorial/barracuda-email-security/barracuda-email-security-scope.webp "1200x442") *Source: Palisade.* The deployment model also needs confirmation. Barracuda's [Email Protection plans page](https://www.barracuda.com/products/email-protection/plans) describes API, inline, and traditional MX-record deployment options for eligible plans. Confirm the route offered by the plan under review. Do not assume that an API-connected deployment, an inline configuration, and an MX-routed configuration produce the same evidence or operational responsibilities. For background on the broader category, [what an email security gateway is](/learning/email-security-gateway) explains the gateway model. That model is useful for inbound protection, but it does not prove that every source using a domain in the visible From field is authorized and aligned. ## Palisade for DMARC operations Palisade is agentic DMARC software for IT teams and MSPs. It fits teams whose main problem is moving a domain, or a portfolio of domains, toward DMARC enforcement with evidence from aggregate reports. Palisade autonomously analyzes DMARC aggregate-report data, identifies sending sources and authentication or alignment issues, and creates prioritized remediation tickets. It can propose the next policy step when a domain appears ready, while a human reviews the evidence and applies the DNS change. See [Palisade's comparison hub](/compare) for the broader operating-platform context. - Best fit: IT teams and MSPs that need a repeatable process for finding legitimate senders, resolving DMARC issues, and deciding when evidence supports a policy-stage change. - Relevant evidence: Palisade focuses on DMARC aggregate-report analysis, source identification, remediation prioritization, and human-reviewed policy progression. - Tradeoff: Palisade is not an email gateway and does not replace a mailbox-security product's tenant-level threat controls, quarantine workflow, or response actions. The product boundary is important. Palisade does not autonomously change the DMARC policy, change a receiver's private reputation decision, guarantee delivery, or prove that every future message will authenticate. It helps organize DMARC evidence and the remediation work that follows from it. A team comparing these options may use both categories. Barracuda can be evaluated for mailbox and tenant protection needs. Palisade can be evaluated for the recurring sender-domain work that remains after public records, message authentication results, and aggregate reports show which sources need attention. For another vendor-oriented scope explanation, see [Abnormal email security](/learning/abnormal-email-security). ## How to choose Choose Barracuda Email Protection when the purchase decision begins with protection and response around Microsoft 365 or Google Workspace mailboxes, then validate the licensed deployment and tested tenant workflow. Choose Palisade when the operational gap is DMARC evidence across domains: discovering sources in aggregate reports, identifying authentication or alignment failures, assigning remediation work, and judging whether a human-reviewed policy step is ready. Use the same validation layers for either evaluation where they apply: - DNS: Query the authoritative DNS service and at least one public resolver for the relevant DMARC, SPF, and DKIM records. - Vendor: Confirm the actual plan, deployment route, and status within the vendor environment. - Message: Send a real message through the exact production path and inspect its `Authentication-Results` or raw headers. - DMARC: Review aggregate reports after data accumulates. A passing DNS record or a green vendor status is not evidence that the production path is authenticating and aligning as intended. ```yaml option: Barracuda Email Protection checked_on: 2026-08-13 best_fit: Microsoft 365 or Google Workspace teams evaluating Barracuda's published email-security suite verified_evidence: Barracuda documents Email Protection, API-first deployment positioning, Domain Fraud Protection, and plan-qualified deployment options open_question: Which features, deployment path, policies, response actions, and results apply to this tenant and plan --- option: Palisade checked_on: 2026-08-13 best_fit: IT teams and MSPs operating DMARC remediation and policy progression across domains verified_evidence: Palisade analyzes DMARC aggregate reports, identifies sources and authentication issues, and proposes prioritized human-reviewed remediation work open_question: Which sender sources and policy blockers appear after the organization's own report data accumulates ``` ## Check the public sender-domain baseline If the immediate question is whether a sending domain publishes the main public email-authentication controls, use the [Email Security Score](/tools/email-security-score) to inspect the domain before comparing it with message and DMARC-report evidence. A public baseline is useful when a buyer needs to separate a visible DNS issue from a tenant-configuration question. It cannot inspect a Barracuda tenant, its licenses or policies, a message verdict, continuous state, or a mailbox provider's private decision. It also cannot prove inbox placement or replace a delivered message from the production sending path. ## Sources and further reading - [Barracuda Email Protection overview](https://www.barracuda.com/products/email-protection) - [Barracuda Email Protection features](https://www.barracuda.com/products/email-protection/features) - [Barracuda Email Protection plans](https://www.barracuda.com/products/email-protection/plans) - [RFC 9989: DMARC](https://www.rfc-editor.org/rfc/rfc9989) - [Palisade comparison hub](/compare) ## Frequently asked questions ### Is Barracuda Email Protection the same as DMARC? No. Barracuda Email Protection is a broader email-security offering. Barracuda lists Domain Fraud Protection for DMARC reporting and analysis, while DMARC is a sender-domain authentication and requested-disposition protocol defined by RFC 9989. ### Does Barracuda Email Protection replace Microsoft 365 or Google Workspace? No. Barracuda's Email Protection overview says the offering supplements Microsoft 365 and Google Workspace. The practical fit depends on the plan, deployment method, policies, and evidence from the tenant's own test workflow. ### Can Barracuda help with DMARC reporting? Yes. Barracuda's Email Protection features page describes Domain Fraud Protection as providing DMARC reporting and analysis, visibility into sending systems, and passing or failing DMARC information. Confirm the licensed scope and configuration in the tenant before relying on it operationally. ### Is Palisade an email gateway? No. Palisade is DMARC software for analyzing aggregate reports, identifying sending sources and authentication issues, and preparing prioritized remediation work. It does not replace an email gateway's mailbox-protection or tenant-response functions. ### Does a public email-security scan evaluate Barracuda settings? No. A public scan can inspect publicly resolvable sender-domain signals. It cannot access Barracuda policies, licensing, deployment settings, message verdicts, or response actions in a tenant. --- # Mimecast DKIM setup Canonical: https://www.palisade.email/learning/mimecast-dkim-setup > Set up Mimecast outbound DKIM signing: create the DNS Authentication definition, publish its generated TXT key, apply a policy, and validate mail. To set up DKIM for Mimecast outbound mail, create an outbound DNS Authentication definition for each internal sending domain, generate its key pair, publish the displayed DNS Address and Public Key as a TXT record, validate it in Mimecast, then attach the definition to an outbound policy. Copy the DNS values from your own account. The selector and public key are account-specific, so another tenant's record cannot authenticate your mail. ## Quick takeaways - This guide covers mail that exits through Mimecast Email Security Cloud Gateway, not a separate marketing or transactional platform. - Mimecast generates a DNS Address in the form `selector._domainkey.domain` and a public key for the outbound definition. - Publish the generated values as a TXT record, then use the definition's DNS check before saving it. - A saved definition does not sign mail until an outbound DNS Authentication policy selects it. - Validate four things separately: public DNS, the Mimecast definition, a delivered message, and DMARC aggregate-report data. ## What should I check before configuring Mimecast DKIM? Confirm that the stream you are configuring actually leaves through Mimecast. Mimecast says that when all outbound mail goes through its service, Mimecast should be the signer; mail signed before reaching Mimecast can fail after delivery because the earlier signer did not deliver the message. Read [Mimecast's DNS Authentication overview](https://mimecastsupport.zendesk.com/hc/en-us/articles/34000468841107-Policies-DNS-Authentication-Overview) alongside your outbound routing before changing DNS. You need access to the Mimecast Administration Console, an internal domain available to select in the definition, and permission to add a TXT record at that domain's authoritative DNS host. A separate sending platform needs its own signing path and selector. For the protocol background, see [what DKIM is](/learning/what-is-dkim). > Copy the DNS Address and Public Key only from the Mimecast definition for the domain you are configuring. Do not publish a selector, hostname, or key copied from another account, domain, or online example. ## Which setup method should I use? Use this workflow when Mimecast is the final outbound gateway for the messages in scope. In Mimecast's documented definition, selecting **Sign Outbound Messages with DKIM** exposes the internal-domain selection, key length, DNS Address, and Public Key. Mimecast documents 1024-bit and 2048-bit key choices for an internal domain. Choose the value your DNS host and organization support, then publish exactly what the console generates rather than adapting a sample record. [Mimecast's DNS Authentication Definition guide](https://mimecastsupport.zendesk.com/hc/en-us/articles/34000340541587-Policies-Configuring-DNS-Authentication-Definition) is the authority for the current fields and labels. ## How do I set up Mimecast DKIM? ### 1. Open the outbound DNS Authentication definition In the Mimecast Administration Console, open the DNS Authentication definition workflow for outbound mail and select **Sign Outbound Messages with DKIM**. Select the internal domain that sends through Mimecast. Mimecast says that each internal domain needs its own definition and policy association, which prevents the wrong domain from being used for a signing check. Confirm the current controls against [Mimecast's definition instructions](https://mimecastsupport.zendesk.com/hc/en-us/articles/34000340541587-Policies-Configuring-DNS-Authentication-Definition). ### 2. Generate the key pair for the selected domain Choose the available DKIM key length, then use **Generate** to create the key pair. Mimecast keeps the private key and displays the public key, so the only value that belongs in DNS is the displayed public key. Record the displayed **DNS Address** and **Public Key** before leaving the definition. ![Mimecast's official DNS Authentication definition instructions for DKIM key length, domain, DNS address, and public key](/images/editorial/mimecast-dkim-setup/mimecast-dkim-definition-guide-official.png "1200x1500") *Source: [Mimecast's DNS Authentication Definition guide](https://mimecastsupport.zendesk.com/hc/en-us/articles/34000340541587-Policies-Configuring-DNS-Authentication-Definition), captured from the live official documentation on August 10, 2026. This is Mimecast's support documentation, not a view of your Administration Console, and the key values shown there are instructions, not values to publish.* ### 3. Publish the account-specific TXT record At the DNS provider for the selected domain, add one TXT record using the DNS Address as the host and the Public Key as the value. Mimecast documents the address format as `selector._domainkey.domain`; if your DNS provider appends the domain automatically, enter only the hostname portion it expects. This structural example is illustrative only: **Record type:** `TXT` **Host, illustrative only:** `mimecast20260728._domainkey.example.com` **Value, illustrative only:** ```text v=DKIM1; k=rsa; p=<the public key generated in your Mimecast definition> ``` Do not publish this example or any key from another account. Copy the exact DNS Address and Public Key generated in your own Mimecast definition. Mimecast also notes that some DNS providers need spaces preserved in the public key and that a 2048-bit key can exceed a provider's single-string TXT limit. Review the [DNS Address and Public Key instructions](https://mimecastsupport.zendesk.com/hc/en-us/articles/34000340541587-Policies-Configuring-DNS-Authentication-Definition) before saving. ![Mimecast DKIM DNS record flow](/images/editorial/mimecast-dkim-setup/mimecast-dkim-setup-dns-records.webp "1200x400") *Source: Palisade.* ### 4. Check DNS and save the definition Return to the definition and use **Check DNS**. Mimecast says this performs a TXT lookup for the generated `selector._domainkey.domain` name and compares it with the Public Key field. If the check cannot find a TXT record, Mimecast advises allowing up to 72 hours for propagation, then comparing the published value with the definition. Save the definition after the DNS check succeeds, because Mimecast says an unsaved validated key is not used for outbound signing. ### 5. Apply an outbound DNS Authentication policy Create or update the outbound policy under **Policies | Gateway Policies**, then select the DNS Authentication definition you created. Mimecast's current policy instructions say to choose **DNS Authentication - Outbound**, select an existing policy or **New Policy**, and select the required definition in **Select Option**. Scope the policy to the intended sender and validity period before enabling it. [Mimecast's policy guide](https://mimecastsupport.zendesk.com/hc/en-us/articles/34000734400019-Policies-Configuring-DNS-Authentication-Policy) documents the path and policy fields. ![Mimecast DKIM validation checklist](/images/editorial/mimecast-dkim-setup/mimecast-dkim-setup-validation.webp "1200x524") *Source: Palisade.* ## How does this setup affect DMARC? A valid Mimecast signature helps DMARC only when its `d=` signing domain aligns with the visible From domain. Mimecast explains that a DKIM signature can pass while still being unaligned when the signing domain does not match the From domain. Inspect a delivered message's `DKIM-Signature` and `Authentication-Results` values after the policy takes effect, then compare `d=` and `header.from`. [Mimecast's alignment guidance](https://mimecastsupport.zendesk.com/hc/en-us/articles/44628847105171-DMARC-Analyzer-2-0-Alignment) describes that distinction. Before changing enforcement, use the [DMARC checker](/tools/dmarc) to inspect the published policy. A public record check cannot establish which signer handled a particular delivered message. ## How do I validate the setup? ### Check public DNS Query the generated `<selector>._domainkey.<domain>` TXT name through an authoritative or public resolver. Confirm that the answer matches the Public Key displayed in the definition. You can also use the [DKIM checker](/tools/dkim) with the selector and domain to inspect the public record. This proves DNS publication, not signing. ### Check the Mimecast vendor status Use **Check DNS** in the saved definition and confirm it succeeds. Mimecast says the definition activates only after a successful DNS check. This confirms Mimecast can resolve the generated key, but it does not prove that the outbound policy matched a real message. ### Inspect a delivered message Send a message through the exact production route to an external mailbox and inspect the receiver-added authentication results. [RFC 8601](https://www.rfc-editor.org/rfc/rfc8601.html) defines the `Authentication-Results` header fields used to report results. Look for `dkim=pass`, the expected selector, and a `DKIM-Signature` with the expected `d=` domain. ```text Authentication-Results: receiver.example; dkim=pass header.d=example.com header.s=mimecast20260728; dmarc=pass header.from=example.com DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=mimecast20260728; ``` The example is illustrative only. The selector and signing domain must come from your delivered message and Mimecast definition. ### Review DMARC reports Use aggregate-report data or a DMARC monitoring service after normal traffic has flowed. One delivered message establishes one path. Report data helps identify whether other sources using the From domain remain unaligned or unsigned. [RFC 9989](https://www.rfc-editor.org/rfc/rfc9989.html) defines DMARC's alignment model, and [RFC 9990](https://www.rfc-editor.org/rfc/rfc9990.html) defines aggregate reporting. ## Check the public key before changing more DNS If the DNS check fails, first inspect the exact public key that is published at the selector from your Mimecast definition. The [Palisade DKIM checker](/tools/dkim) can inspect that public record. It does not prove Mimecast is applying the outbound policy, validate a particular message, or repair the record. [Check the published Mimecast DKIM record](/tools/dkim) ## Watch the signing paths beyond this change The public-key check confirms that one selector resolves. It cannot show whether another sender uses the same From domain, whether a later routing change bypasses Mimecast, or whether every production stream remains aligned. Palisade's DMARC Agent analyzes aggregate-report data, identifies sending sources and authentication or alignment issues, and creates prioritized remediation tickets. Your team reviews the evidence and applies any DNS or DMARC policy change. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=vendor_setup&utm_content=mimecast-dkim-setup) Palisade does not change Mimecast settings, publish DNS records, guarantee delivery, or prove how an individual receiver treated a message. ## Troubleshooting ### Check DNS cannot find the TXT record Compare the host saved at your DNS provider with the DNS Address in Mimecast. A provider that appends the domain can create a doubled hostname when given a fully qualified value. If the host and public key match, allow the propagation period Mimecast documents before regenerating anything. ### The definition is validated but mail is unsigned Check that you saved the definition after validation and that the outbound DNS Authentication policy selects it. Then verify the policy scope against the actual sender and route. A DNS record alone does not cause Mimecast to sign mail. ### DKIM passes but DMARC fails Compare the signature's `d=` value with the visible From domain. A valid signature from an unrelated signing domain can pass DKIM and fail DMARC alignment. Correct the signing-domain relationship or the From-domain design instead of generating another key. ### A message was signed before reaching Mimecast If the message is modified after an earlier signer applies DKIM, the receiver can report a failed signature. Confirm which gateway is the final outbound sender. Mimecast's overview specifically cautions against a separate server signing before it hands mail to Mimecast when Mimecast is the final sender. ## Sources and further reading - [Mimecast: Configuring DNS Authentication Definition](https://mimecastsupport.zendesk.com/hc/en-us/articles/34000340541587-Policies-Configuring-DNS-Authentication-Definition) - [Mimecast: Configuring DNS Authentication Policy](https://mimecastsupport.zendesk.com/hc/en-us/articles/34000734400019-Policies-Configuring-DNS-Authentication-Policy) - [Mimecast: DNS Authentication Overview](https://mimecastsupport.zendesk.com/hc/en-us/articles/34000468841107-Policies-DNS-Authentication-Overview) - [Mimecast: DMARC Analyzer 2.0 Alignment](https://mimecastsupport.zendesk.com/hc/en-us/articles/44628847105171-DMARC-Analyzer-2-0-Alignment) - [RFC 8601: Message Header Field for Indicating Message Authentication Status](https://www.rfc-editor.org/rfc/rfc8601.html) - [RFC 9989: Domain-based Message Authentication, Reporting, and Conformance (DMARC)](https://www.rfc-editor.org/rfc/rfc9989.html) ## Frequently asked questions ### Does Mimecast create the DKIM key? Yes. In Mimecast's documented outbound definition workflow, the Generate action creates the key pair. Mimecast stores the private key and displays the public key for you to publish in DNS. The DNS Address and Public Key must come from the definition for the domain you are configuring. ### Can I copy a Mimecast DKIM record from another domain? No. A DKIM public key has to match the private key held by the signer. Copying another account's selector or public key does not give Mimecast the matching private key for your domain and can leave your production mail unsigned or failing verification. ### Does a successful DNS check prove outbound mail is signed? No. It shows that Mimecast can resolve the public key for the definition. Confirm actual signing with a message sent through the production route and receiver-added authentication results that show `dkim=pass`. ### Why does DKIM pass but DMARC fail? DKIM can pass for a signing domain that does not align with the visible From domain. DMARC requires aligned SPF or DKIM identity, so compare `header.d` or the signature's `d=` value with the From domain in the delivered message. ### How long should I wait for Mimecast DNS validation? Mimecast documents allowing up to 72 hours after publishing a TXT record when its DNS check cannot find the record. Before waiting or regenerating a key, compare the DNS Address and Public Key in the definition with the record saved at the authoritative DNS host. --- # MxToolbox email deliverability tool: read the report Canonical: https://www.palisade.email/learning/mxtoolbox-email-deliverability-tool > Send a test message to MxToolbox, open the email deliverability report, interpret its message-path evidence, choose the next check, and retest. The MxToolbox Email Deliverability tool is useful when you need evidence from one sent message. Send a representative message to MxToolbox, retrieve its report, then use the reported delivery, relay, SPF, DKIM, and header evidence to choose one narrow next check. It does not prove inbox placement across mailbox providers or diagnose every cause of poor [email deliverability](/email-deliverability). ## Quick takeaways - MxToolbox's current workflow starts by sending a message to `ping@tools.mxtoolbox.com`. - Use a test message from the same sending application and visible From domain as the path under investigation. - A report establishes evidence for the submitted message and the time of the lookup, not every future message. - Read Delivery Information before changing DNS or sender settings. - Relay evidence points to a message-path investigation, while authentication evidence may justify a separate public DNS check. - Retest with a new message sent through the same path after a supported repair. ## Who this comparison is for This guide is for an email administrator, deliverability specialist, or MSP technician who has a message path to inspect and needs to decide what the MxToolbox report can establish. If the decision is whether another product should replace this or another MXToolbox job, use the [MXToolbox alternatives comparison](/resources-post/mxtoolbox-alternatives) to match each evidence type to a tool. The choice is between evidence types, not between brands. A submitted-message report can show information returned for that message. A public DNS lookup can show a published record. An MX lookup can show currently resolvable mail-routing records. A blocklist lookup can show a named provider's result for an IP address or domain. SMTP diagnostics require an observed connection to the mail service. None of those checks proves that a production sending path will behave the same way later, or that a receiving mailbox provider will place a message in the inbox. For the broader concept and its factors, see [what email deliverability means](/email-deliverability). ## How the options were evaluated The diagnostic options below were assessed against public first-party documentation checked on 2026-07-28. The criteria are: - Input fit: whether the check needs a submitted message, a public domain, an MX hostname, an IP address, or an SMTP endpoint. - Evidence scope: the specific fact the result can establish. - Time model: whether the result is a point-in-time observation or evidence from a submitted message. - Next action: the narrowest investigation the result supports. - Boundary: what the result does not prove or control. A documented capability counts as available. A missing documented capability remains an open question. A successful result for one input is not evidence about another sending path, receiver, or later delivery attempt. ## MxToolbox Email Deliverability tool MxToolbox documents an Email Deliverability workflow that accepts a test message. Its [Email Deliverability page](https://mxtoolbox.com/deliverability) instructs the sender to email `ping@tools.mxtoolbox.com`, then retrieve the report through the reply link or by entering the sender email address in the page's search control. ### 1. Send a representative test message Send a new message through the same application, provider configuration, visible From domain, and authentication setup that you need to investigate. Do not substitute a message from a different system when the question concerns the production path. Keep the sent copy. It gives you the message subject, sender identity, and sending context needed to confirm that the returned report belongs to the intended test. ### 2. Retrieve the report Open the reply from MxToolbox and use the report link. If you need to retrieve an earlier result, use the email search method documented on the [MxToolbox Email Deliverability page](https://mxtoolbox.com/deliverability). Confirm that the report corresponds to the message you sent before acting on it. An older report can describe an earlier configuration, DNS state, or sending path. ![MxToolbox Email Deliverability interface showing the test address and sender-email report retrieval field](/images/editorial/mxtoolbox-email-deliverability-tool/mxtoolbox-deliverability-public-interface.png "1280x900") *Source: [MxToolbox Email Deliverability](https://mxtoolbox.com/deliverability), checked 2026-07-28.* ### 3. Preserve the evidence that drives the next action Record the test context before making changes. This prevents a later record update or sender change from being credited to the wrong test. ```text Test date and time: Sending application: Visible From domain: Report sender address and subject: Reported failed, delayed, or warning fields: Next evidence source: Same-path retest date: ``` - Best fit: Investigating one message sent through a known path. - Relevant evidence: MxToolbox's [Email Delivery Tools documentation](https://knowledgebase.mxtoolbox.com/home/email-delivery-tools) describes Header Analyzed, Delivery Information, Relay Information, SPF/DKIM Information, Headers Found, and Received Header. - Tradeoff: The report does not establish a receiver-wide inbox-placement result, future delivery behavior, or the state of an unobserved sending source. ## Public DNS and MX diagnostics A public DNS or MX diagnostic is the better fit when the remaining question is "what record can a public resolver see now?" It is not a replacement for the MxToolbox submitted-message report. Use a public DNS result after the report points to a record question, such as a DMARC publication issue. The focused [Palisade DMARC checker](/tools/dmarc) can inspect the public DMARC record for a domain. A public MX check can inspect the currently published mail-routing records. > Do not replace an SPF record, publish a DKIM record, or change a DMARC policy based only on a red status. First identify the sending application, the intended identity, and the authoritative DNS record that controls the path. - Best fit: Confirming public DNS or MX publication after a report narrows the question. - Relevant evidence: A public lookup can establish the answer returned for the queried domain or hostname at that time. - Tradeoff: A public record does not prove the sending application used it, that a message was signed, or that a receiver accepted the message. ![Decision flow for selecting message, DNS, MX, blocklist, or SMTP evidence after a deliverability report](/images/editorial/mxtoolbox-email-deliverability-tool/mxtoolbox-email-deliverability-tool-decision-flow.webp "1200x980") *Source: Palisade.* ## Blocklist and SMTP diagnostics A blocklist lookup and an SMTP diagnostic answer different questions from the MxToolbox report. A blocklist lookup is appropriate when the investigation has identified a sending IP address or domain and the next question concerns a named reputation data source. Palisade can [run the domain and its mail server IPs through public blocklists](/tools/domain-reputation) in one pass. Record the exact input, provider, and lookup time. A clean result does not establish that every receiver considers the sender reputable, because mailbox providers can apply private reputation and filtering signals. SMTP diagnostics are appropriate when the symptom is a connection, TLS, greeting, relay, or response-code problem. Those failures require observed server behavior, relevant mail-server logs, or a test against the affected endpoint. A public DNS record does not reproduce an SMTP transaction. - Best fit: Investigating a named source reputation result or a mail-server interaction. - Relevant evidence: A blocklist result applies to the named provider and exact queried input. SMTP evidence applies to the observed connection and response. - Tradeoff: Neither result proves inbox placement, message authentication on every future message, or a receiver's private filtering decision. ## Palisade for a separate public DMARC question Palisade fits this workflow only when the MxToolbox report leaves a specific public DMARC publication question open. The [Palisade DMARC checker](/tools/dmarc) gives a separate public record check that can complement the message-specific report. - Best fit: Inspecting the currently published DMARC record after report evidence points to DMARC publication. - Relevant evidence: The public DMARC record returned for the queried domain. - Tradeoff: The checker cannot reproduce MxToolbox's submitted-message report, alter DNS, control a receiver, or guarantee inbox placement. If the ongoing problem is broader than one record, Palisade is DMARC software for teams that need to analyze DMARC aggregate-report data, identify sources and alignment issues, and create prioritized remediation work. It proposes the next policy step when the evidence supports it, while a human reviews the evidence and applies any change. It does not autonomously change the DMARC policy or guarantee that future mail will authenticate. ## How to choose Choose MxToolbox first when you need a report about an actual submitted test message. Choose a public DNS or MX lookup when the remaining question is about a currently published record. Choose a blocklist lookup when the question names a particular reputation source and IP address or domain. Choose SMTP evidence when the failure concerns a server connection or response. ```yaml option: MxToolbox Email Deliverability tool checked_on: 2026-07-28 best_fit: "A representative message sent through the path under investigation" verified_evidence: "Header, delivery, relay, SPF, DKIM, and received-message report sections documented by MxToolbox" open_question: "How a specific receiving mailbox provider will place future messages" option: Public DMARC or MX lookup checked_on: 2026-08-13 best_fit: "A question about a currently resolvable public record" verified_evidence: "The record returned for the exact queried domain or hostname" open_question: "Whether the production sender uses the record and whether a receiver accepts the message" option: Blocklist or SMTP diagnostic checked_on: 2026-08-13 best_fit: "A named reputation source or observed mail-server behavior" verified_evidence: "The exact provider result or tested SMTP interaction" open_question: "Inbox placement and receiver-private filtering decisions" ``` Use the report in this evidence order: - Delivery Information: investigate an authentication result through the application configuration and the relevant public record. - Relay Information: inspect the sending provider's logs or receiving system evidence before changing authentication policy. - SPF and DKIM Information: identify the sender identity and the exact DNS record before proposing any DNS change. - Headers Found and Received Header: confirm that the report represents the path you intended to test. If you inspect an `Authentication-Results` field in a delivered message, treat it as an assertion from the system that added it. [RFC 8601](https://www.rfc-editor.org/rfc/rfc8601.html) explains that use of those authentication assertions depends on the trust relationship with the validating system. ## Retest the same message path After a supported repair, send a fresh message through the same application and visible From domain to `ping@tools.mxtoolbox.com`. Retrieve the new report, confirm that it describes the new message, and compare the field that prompted the repair. When DNS was changed, confirm the intended value with authoritative DNS and at least one public resolver before interpreting the retest. Then check the sending application's own verification state and inspect a real delivered message from that same production path. Once DMARC aggregate reports have accumulated, use them to confirm which sources are actually sending and whether authentication or alignment issues remain. ## Check a remaining public DMARC question If the report leaves a DMARC publication question unresolved, [check the public DMARC record with Palisade](/tools/dmarc). This is useful after the report has narrowed the issue to public DNS evidence. It does not reproduce the submitted-message report, repair the sender configuration, monitor later changes, or guarantee inbox placement. ## Sources and further reading - [MxToolbox Email Deliverability](https://mxtoolbox.com/deliverability) - [MxToolbox Email Delivery Tools documentation](https://knowledgebase.mxtoolbox.com/home/email-delivery-tools) - [RFC 8601: Authentication-Results header field](https://www.rfc-editor.org/rfc/rfc8601.html) - [Palisade DMARC checker](/tools/dmarc) - [Email deliverability testing tools](/tools/email-deliverability-test) ## Frequently asked questions ### Does the MxToolbox Email Deliverability tool prove inbox placement? No. The report provides evidence about the submitted message and MxToolbox's checks at that time. Inbox placement can vary by receiving provider, recipient, reputation, content, and later message-path conditions. ### Can I retrieve a MxToolbox report without sending another message? Yes. MxToolbox documents a sender-email search path for retrieving reports. Use a fresh message when verifying a recent sender or DNS change because an older report represents earlier evidence. ### Should I change a DMARC policy after a failed report result? No. First determine whether the problem concerns public DMARC publication, message alignment, or the sending application's identity. A failed result identifies a question to investigate. It does not authorize a policy change by itself. ### Does a public DMARC lookup prove that the application signs mail correctly? No. A public lookup shows the record that resolves for the queried domain. It does not prove that the sending application used the intended domain, generated a DKIM signature, or passed DMARC at a receiver. ### Can a blocklist result explain every deliverability problem? No. A result applies to the named provider's data for the queried input at that time. It does not expose every blocklist, mailbox-provider private reputation, recipient engagement signal, or inbox-placement outcome. --- # Sublime email security Canonical: https://www.palisade.email/learning/sublime-email-security > Understand Sublime email security's documented scope, what it does not prove in a tenant, and how to evaluate it alongside sender-domain authentication. Sublime email security is a cloud email-security platform that Sublime documents for Microsoft 365 and Google Workspace environments. Its published scope includes blocking email attacks, triaging suspicious messages reported by users, and threat hunting. That describes available product functions, not proof that a particular tenant is connected correctly, catches every attack, or can replace sender-domain controls. Evaluate the platform with tenant and message evidence, and evaluate DMARC separately. ## Quick takeaways - Sublime documents Microsoft 365 and Google Workspace support for its cloud email-security platform. - Its overview lists blocking phishing, business email compromise, and malware, as well as triage and threat hunting. - Vendor documentation describes capability, not the outcome in your tenant or for a specific message. - Sublime says it can work alongside Microsoft Defender for Office 365, so do not assume a replacement architecture. - DMARC answers a different sender-domain question from an inbound security product. ## What Sublime email security covers The [Sublime documentation overview](https://docs.sublime.security/docs/overview) describes a cloud platform for Microsoft 365 and Google Workspace. It lists blocking attacks such as phishing, business email compromise, and malware, automatic triage for user-reported suspicious email, and threat hunting across the environment. The same overview describes programmable detections and actions such as quarantine, webhook notification, and warning banners. Those statements define the vendor's published product scope. They do not establish that your tenant has authorized the required access, that a detection is appropriate for your mail, or that a message was handled correctly. The deployment architecture also matters. For a broader explanation of security layers, read [how secure email gateways protect an organization](/learning/how-secure-email-gateways-protect-organization) and [business email-security practices](/learning/what-are-the-top-email-security-tips-for-small-businesses). ## What it does not establish Sublime's [Microsoft 365 email-security page](https://sublime.security/microsoft-365-email-security/) says the platform works alongside Microsoft Defender for Office 365 and adds an organization-specific detection and response layer. That is a product-positioning statement, not proof that a tenant's existing controls, permissions, remediation settings, or mail flow are safe to change. Do not turn a vendor capability page into evidence of efficacy. A useful evaluation still needs representative business mail, approved threat simulations, records of detections and releases, and a review of false positives, administrator effort, and rollback options. The exact mix depends on the tenant and its approved testing process. ## Use the right evidence for the question Keep product evidence, delivered-message evidence, and public DNS evidence separate. They answer different questions. ```text Question: What features does Sublime document? Evidence: current vendor documentation and the approved tenant evaluation Question: What happened to one received message? Evidence: the preserved message, its received headers, and the tenant's event evidence Question: Is a visible From domain covered by a published DMARC policy? Evidence: the public DMARC record and receiver-added authentication results ``` This record is deliberately narrow. A result from one lane does not establish the other two. That boundary is especially useful when a team is deciding whether a phishing result, a quarantine event, or a DNS check justifies a configuration change. ## Does Sublime replace DMARC? No. [RFC 9989](https://www.rfc-editor.org/rfc/rfc9989.html) defines DMARC as a mechanism for the domain in the visible From field, including identifier alignment, published policy, and reporting requests. A service that examines inbound messages can address different signals, but it does not replace the sender-domain authorization and reporting function of DMARC. See [what DMARC is](/learning/what-is-dmarc) for the protocol boundary. The reverse is also true. A correct DMARC record does not prove that an inbound security platform will detect every malicious message, correctly classify user-reported email, or have the right tenant settings. Treat these as complementary evidence domains. ## Evaluate a deployment without overclaiming Start with the native controls and the proposed authorization scope. Then define approved cases that include ordinary business mail and authorized threat simulations. For each case, retain enough evidence to review the detection, investigation, remediation, release, rollback, false-positive impact, and administrator effort. ![Deployment evaluation evidence checklist](/images/editorial/sublime-email-security/sublime-email-security-evaluation-checklist.webp "1200x582") *Source: Palisade.* Do not use a single vendor alert as a pass or fail test. It can be one useful observation, but an evaluation should also expose what happened to legitimate mail and how an administrator can reverse a mistaken action. If your question is only about published sender-domain configuration, use a public record check instead of trying to infer the answer from an inbound security product. ## Check sender-domain authentication separately Use the [Palisade DMARC checker](/tools/dmarc) to inspect the public policy for a domain you control. A public lookup can show the published sender-domain record. By inference from DMARC's DNS publication model, it cannot inspect a private Sublime tenant, reproduce a detection, or prove a particular inbound message was safe. For a related named-product example, read [Advanced Email Security from GoDaddy](/learning/advanced-email-security-godaddy). Keep the same boundary in both cases: vendor scope, tenant evidence, message evidence, and public DNS do not substitute for one another. ## Sources and further reading - [Sublime documentation overview](https://docs.sublime.security/docs/overview) - [Sublime email security for Microsoft 365](https://sublime.security/microsoft-365-email-security/) - [RFC 9989: DMARC](https://www.rfc-editor.org/rfc/rfc9989.html) ## Frequently asked questions ### Does Sublime replace DMARC? No. Sublime's inbound email-security functions and DMARC's sender-domain authorization and reporting function address different evidence and control boundaries. Review both when the organization sends mail under domains it owns. ### Can a DMARC lookup test Sublime? No. A DMARC lookup reads a public DNS record. It cannot inspect a Sublime tenant, confirm permissions, recreate a detection, measure false positives, or establish how a specific message was handled. ### Does Sublime replace Microsoft Defender for Office 365? No. Sublime says it can operate alongside Microsoft Defender for Office 365. Confirm the proposed architecture, permission scope, remediation settings, and operating responsibilities for the tenant before relying on either control path. ### What should a Sublime trial measure? Measure approved representative cases, including legitimate business mail and authorized threat simulations. Retain evidence for detection, investigation, remediation, release, rollback, false positives, and administrator effort. ### Does an API integration prove messages are protected? No. An integration can establish a connection path, but it does not prove coverage, tuning, permissions, remediation behavior, or the outcome for every message. Test those conditions with approved tenant and message evidence. --- # Warmy email deliverability test Canonical: https://www.palisade.email/learning/warmy-email-deliverability-test > What a Warmy deliverability test measures, how to read its placement result, and the evidence to confirm before changing a sender's configuration. A Warmy email deliverability test is a placement snapshot for the message and providers included in that test. Warmy's documentation says its tests report where copies land for selected providers, including inbox, spam, unreceived, and promotions states. Use that outcome to choose the next evidence check, not as proof that every recipient will see the next campaign in the inbox. Authentication, sender history, and real-recipient signals can still differ. ## Quick takeaways - A Warmy result describes the tested message, provider set, and time of the test. - Inbox and spam outcomes are useful provider-specific evidence, not a guarantee for every recipient. - Compare a placement concern with message authentication and the sender's own delivery data before changing configuration. - Keep the sender, content, and delivery path representative when you retest. - Make one evidence-backed change at a time so the next result remains interpretable. ## What a Warmy test records Warmy's [Email deliverability test documentation](https://support.warmy.io/knowledge/the-inbox-deliverability-checker) says its tests send a personalized message to mailboxes outside its warm-up network and show results by provider. The same documentation describes four outcomes: inbox, spam, unreceived, and promotions. Those labels tell you what happened to the copies the service observed. They do not disclose a mailbox provider's private filtering formula or establish a result for all recipients. ![Warmy dashboard showing sent and received counts, mailbox temperature, and a deliverability breakdown across inbox and spam](/images/editorial/warmy-email-deliverability-test/warmy-email-deliverability-test-cited-2.png "1239x743") *Source: [Warmy product imagery](https://www.warmy.io/), checked 2026-07-30. This is Warmy's own published interface image, not a test result for your domain.* The free [Warmy deliverability-test page](https://www.warmy.io/free-tools/email-deliverability-test/) describes its output in terms of sender reputation, spam score, and inbox placement. Treat any score as a summary of that service's evidence at that point in time. A score alone does not identify whether a DNS record, a sending service, a complaint pattern, or message content caused a placement outcome. This is the same general limitation described in the [inbox placement test guide](/learning/inbox-placement-test): a placement test is useful for a representative copy, but it is not a campaign-wide delivery guarantee. The broader concept of [email deliverability](/email-deliverability) includes the receiver's acceptance and folder decision, not just one test result. ```text WARMY RESULT REVIEW RECORD Tested message: representative sender, content, and delivery path Observed outcome: inbox / spam / unreceived / promotions by tested provider Evidence not supplied: every recipient's future folder decision or a root cause Next check: message authentication, public DNS, or sender-owned campaign evidence Retest rule: change one documented variable, then compare the same path ``` ![Warmy result review checklist](/images/editorial/warmy-email-deliverability-test/warmy-email-deliverability-test-review.webp "1200x582") *Source: Palisade.* ## How to interpret a Warmy result ### 1. Preserve the test context Save the test time, sender identity, message version, and provider outcomes before changing anything. A placement result has more value when you can compare it with the same message type and sending route later. If the tested message was not representative of the campaign, use the result as a lead for investigation rather than a verdict. ### 2. Separate placement from message-level evidence If a provider outcome raises an authentication, alignment, blocklist, or content question, send the same representative message to Palisade's [email deliverability test](/tools/email-deliverability-test). It examines a received message for those signals. It does not reproduce Warmy's provider-placement result or show the folder used by every mailbox provider. ### 3. Check the public authentication posture When the remaining question is whether the visible domain publishes the expected SPF, DKIM, and DMARC records, run the domain through the [Email Security Score](/tools/email-security-score). It is the narrowest useful follow-up for public record evidence. A DNS check cannot prove the exact sending path, fix a sender configuration, or explain a particular recipient's folder decision. ## What a low placement result does and does not show A low inbox outcome is a reason to inspect the tested provider, sender, and message path more closely. It is not proof of a single cause. The result may be consistent with an authentication problem, a sender-history issue, a content concern, or evidence that is not visible to the test. That conclusion is an inference because mailbox providers do not publish a complete one-to-one explanation for each folder decision. Start with evidence that can distinguish the possibilities. Keep a delivered copy of the representative message, its authentication results, the public DNS records, and the sender's own complaint and bounce trends. For a separate message-level spam-risk workflow, see [test spam email](/tools/email-deliverability-test). Do not treat a better retest as proof that a tool repaired the sender. It only confirms a changed result for the path you tested. ## Check the public records behind the result If the test result leaves you with a public authentication question, inspect the domain's published posture before changing policy. The Email Security Score can show the current records, while the delivered-message test can show whether a representative message authenticated on arrival. Together, those checks narrow the gap between a placement snapshot and an evidence-backed sender investigation. [Check the Email Security Score](/tools/email-security-score) The score does not reproduce Warmy's test, see private recipient signals, change DNS, or guarantee inbox placement. ## Keep recurring sender evidence together One provider-placement result and one public DNS check cannot show every legitimate sender using a domain or prioritize a recurring alignment issue. Palisade's [DMARC Agent remediation guide](https://docs.palisade.email/guides/fixing-authentication-issues/) explains that DMARC reporting can identify sending sources and authentication or alignment problems, then create remediation work for human review. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=email_deliverability&utm_content=warmy-email-deliverability-test) Palisade does not change DNS, control receiver filtering, reproduce a Warmy result, or guarantee delivery. ## Sources and further reading - [Warmy Email deliverability test documentation](https://support.warmy.io/knowledge/the-inbox-deliverability-checker) - [Warmy free email deliverability test](https://www.warmy.io/free-tools/email-deliverability-test/) - [Amazon Pinpoint inbox placement test documentation](https://docs.aws.amazon.com/pinpoint/latest/userguide/channels-email-deliverability-dashboard-pipt.html) - [Palisade DMARC Agent remediation guide](https://docs.palisade.email/guides/fixing-authentication-issues/) ## Frequently asked questions ### Does a Warmy email deliverability test guarantee inbox placement? No. It reports the outcome for the message and providers included in the test. Real recipients, later sending conditions, engagement, and receiver-specific filtering can differ from those observed copies. ### What does an unreceived result mean in Warmy? It means Warmy documents a problem with sending the email or detecting the result for that provider. Keep the provider outcome with the message evidence, then investigate the sending path before assigning a single cause. ### Should I change my DNS after one low placement result? Only when the result and separate evidence support a public authentication problem. First compare the test with a representative delivered message and the published SPF, DKIM, and DMARC records so a DNS change addresses an observed issue. ### Can a good Warmy result prove that every campaign recipient will get the inbox? No. A good result describes the tested copies at that time. It cannot establish inbox placement for every mailbox, later campaign, recipient audience, or receiver-specific filtering decision. ### What should I retest after fixing an authentication issue? Use the same sender identity, representative content, delivery path, and relevant provider set. Record the change you made, then compare the new result with the earlier result instead of treating different tests as directly comparable. --- # Zix email security: what the name means today Canonical: https://www.palisade.email/learning/zix-email-security > Zix email security now sits within OpenText Cybersecurity. Learn what its encryption service does and where SPF, DKIM, and DMARC differ today. Zix email security is a legacy name now represented within OpenText Cybersecurity. OpenText says Zix is formally part of the OpenText family, while established support and account portals remain available. The current related offering is OpenText Core Email Encryption, which applies policy-based actions to outbound email. Choose it when the question is how content is protected. Use SPF, DKIM, and DMARC when the question is whether a domain is authorized to send mail. ## Quick takeaways - Zix is formally part of OpenText, though established Zix portals remain available. - OpenText Core Email Encryption describes policy actions that can encrypt, quarantine, or block outbound email. - Encryption protects message content according to policy. It does not authenticate the visible From domain. - SPF, DKIM, and DMARC address sender-domain authorization and authentication. - A public DNS check cannot prove why an OpenText or Zix tenant handled one message in a particular way. - A delivered message and the tenant's policy evidence are needed to validate an individual encryption outcome. ## Who this comparison is for This comparison is for administrators, procurement teams, and recipients who encounter the Zix name in an old portal, a notification, vendor documentation, or an internal security discussion. The immediate task is to identify what the name refers to today and decide whether the remaining question belongs to email encryption or sender-domain authentication. The distinction matters when an organization sees an encrypted message and assumes it came from an authenticated sender. Those are separate observations. An encryption service can protect content after its policy evaluates a message. DMARC evaluates use of the author domain and publishes the domain owner's requested handling for failures. This is not a general email-security platform comparison. For broader managed DMARC product evaluation, see Palisade's [DMARC software comparison hub](/compare). The decision here is narrower: does the evidence point to an OpenText encryption-policy question or a public domain-authentication question? ## How the options were evaluated The options were evaluated against current first-party documentation and protocol specifications, checked August 13, 2026. - Product context: Whether the source identifies the current relationship between Zix and OpenText. - Security job: Whether the documented capability protects message content or validates sender-domain use. - Evidence available: Whether a public domain name, a tenant policy record, or a delivered message is required. - Validation boundary: What the result cannot establish about a particular message, recipient, or future delivery. - Operator fit: Which team can act on the finding. A documented capability counts as available for the purpose described by its publisher. Tenant-specific policy, licensing, deployment details, and the exact handling of an individual message remain unknown unless the organization operating the service confirms them. ## OpenText Core Email Encryption OpenText's [Zix legacy information page](https://cybersecurity.opentext.com/legacy/zix/) states that Zix is formally part of the OpenText family and that established support and account portals remain available. That explains why the Zix name can still appear in operational material while current product information is published under OpenText Cybersecurity. OpenText's [Core Email Encryption product page](https://cybersecurity.opentext.com/products/email-security/email-encryption/) describes DLP filters and policy actions that can encrypt, quarantine, or block outbound email. The same page describes delivery options and reporting for encryption triggers and message handling. These are policy-controlled capabilities. The public product description does not establish which policy a particular tenant has configured. ![OpenText Core Email Encryption product page showing the public product context for policy-based outbound email protection](/images/editorial/zix-email-security/opentext-core-email-encryption-product-page.png "1280x800") *Source: [OpenText Core Email Encryption](https://cybersecurity.opentext.com/products/email-security/email-encryption/), checked 2026-07-28.* - Best fit: An organization that needs policy-based protection for outbound message content and uses OpenText or legacy Zix services. - Relevant evidence: OpenText documents DLP filters, policy actions to encrypt, quarantine, or block email, delivery choices, and reporting on triggers and handling. - Tradeoff: A public product page cannot show why a specific tenant encrypted, quarantined, blocked, or delivered one message. That answer requires the operating organization's policy evidence and the message path. For a recipient, a Zix-branded notification is a reason to verify the sender and follow the sending organization's support instructions. It is not proof that the sender is legitimate. For an administrator, the legacy name is a product-context clue. It does not identify the exact service edition or the policy that applied to a message. > Do not change DNS records because an encrypted-message notification was received. First establish whether the problem is message-content handling or sender-domain authentication. ## Domain authentication with SPF, DKIM, and DMARC Encryption and domain authentication can both be present on the same message. Neither result proves the other. [RFC 9989's DMARC specification](https://www.rfc-editor.org/info/rfc9989/) defines DMARC as a protocol for validating an author domain's use, communicating a handling preference for failed validation, and requesting reports. In operational terms, DMARC helps a domain owner publish an authentication policy. It does not report an encryption tenant's policy or determine whether content was protected. - Best fit: A domain owner investigating spoofing resistance, sender authorization, alignment, or DMARC policy. - Relevant evidence: [SPF](/learning/what-is-spf) records identify hosts authorized to use a domain in SMTP HELO and MAIL FROM identities under [RFC 7208](https://www.rfc-editor.org/info/rfc7208/). [DKIM](/learning/what-is-dkim) verification retrieves a public key from the claimed signing domain under [RFC 6376](https://www.rfc-editor.org/info/rfc6376/). DMARC evaluates aligned authentication results for the author domain. - Tradeoff: DNS records alone do not prove that a particular production message used the intended sending path, signed successfully, or received a specific mailbox provider outcome. Use this evidence map to keep the two jobs separate: ```text Question: What does "Zix email security" mean in this environment? Evidence: OpenText legacy information and the operating organization's records. Next action: Confirm the current service and support path. Question: Why was one message encrypted, quarantined, or blocked? Evidence: Tenant policy, audit records, and the exact message path. Next action: Ask the organization that operates the OpenText or Zix service. Question: Is a domain publicly publishing authentication controls? Evidence: Public DNS for SPF, DKIM, and DMARC. Next action: Inspect the domain records, then validate a real delivered message. ``` ![Authentication evidence map separating public DNS checks from tenant policy and delivered-message evidence](/images/editorial/zix-email-security/zix-email-security-authentication-evidence.webp "1200x442") *Source: Palisade.* A domain owner can use Palisade's [Email Security Score](/tools/email-security-score) to inspect the public DNS posture for a domain. That is useful when the available evidence is only a domain name. It does not inspect OpenText policy, prove that an individual message was encrypted, reveal a recipient's experience, or predict future delivery. ## How to choose Choose OpenText Core Email Encryption when the unresolved question concerns protected content, policy-triggered handling, delivery choices, or an existing Zix-branded service relationship. Choose domain authentication work when the unresolved question concerns who may use a domain, whether messages authenticate with aligned identifiers, or the domain owner's requested handling of failed authentication. Use the following checks before assigning the issue: - Confirm whether the observed evidence is a vendor notification, a tenant-policy event, a raw delivered message, or a public domain name. - Route tenant-policy questions to the organization operating the OpenText or Zix service. - Route a public domain question to SPF, DKIM, and DMARC inspection. - Validate a claimed production result with a real delivered message from the exact sending path. - Review DMARC aggregate-report data after it accumulates. Public DNS and a vendor status indicator are not message-level validation. ```yaml option: OpenText Core Email Encryption checked_on: 2026-08-13 best_fit: Policy-based protection of outbound email content verified_evidence: OpenText documents DLP filters, encrypt, quarantine, and block actions, delivery choices, and reporting open_question: Which policy, entitlement, and message outcome apply in a specific tenant ``` ```yaml option: SPF, DKIM, and DMARC checked_on: 2026-08-13 best_fit: Public sender-domain authorization, signing, alignment, and DMARC policy verified_evidence: RFC 7208, RFC 6376, and RFC 9989 define the separate protocol roles open_question: Whether a specific production message followed the expected path and how a receiver handled it ``` The four validation layers are distinct: - DNS: Query the authoritative DNS source and at least one public resolver for the published SPF, DKIM, and DMARC records. - Vendor: Review the current OpenText or Zix tenant status and policy evidence with the organization that operates the service. - Message: Inspect a real delivered message from the exact production path, including its authentication results and raw headers. - DMARC: Review aggregate-report data once enough mail has been processed to identify sending sources and alignment outcomes. ## Sources and further reading - [OpenText Cybersecurity: Zix legacy information](https://cybersecurity.opentext.com/legacy/zix/) - [OpenText Core Email Encryption](https://cybersecurity.opentext.com/products/email-security/email-encryption/) - [RFC 9989: Domain-based message authentication, reporting, and conformance](https://www.rfc-editor.org/info/rfc9989/) - [RFC 7208: Sender Policy Framework](https://www.rfc-editor.org/info/rfc7208/) - [RFC 6376: DomainKeys Identified Mail](https://www.rfc-editor.org/info/rfc6376/) ## Frequently asked questions ### Is Zix still a separate company? No. OpenText's [Zix legacy information page](https://cybersecurity.opentext.com/legacy/zix/) says Zix is formally part of the OpenText family. Established support and account portals remain available, so older operational material can still use the Zix name. ### Is Zix email security the same as OpenText Core Email Encryption? Not necessarily. Zix is a legacy brand context, while OpenText's [Core Email Encryption page](https://cybersecurity.opentext.com/products/email-security/email-encryption/) documents its current policy-based encryption offering. Confirm the actual product and policy with the organization operating the service. ### Does an encrypted message prove the sender is legitimate? No. Encryption can protect message content under a policy, but it does not prove that the visible From domain passed SPF, DKIM, or DMARC authentication. Sender-domain identity requires separate authentication evidence. ### Can a DMARC check show whether Zix encrypted a message? No. DMARC evaluates author-domain authentication and publishes a requested handling policy for failed validation. It cannot inspect an OpenText or Zix tenant's encryption policy or prove how a particular message was handled. ### Should a recipient trust a Zix notification link? Only after confirming that the sender and message are expected. Use the sending organization's documented support route when help is needed to access an encrypted message. A notification alone does not establish that a message is trustworthy. --- # Open-source DMARC report analyzers: how to choose Canonical: https://www.palisade.email/learning/dmarc-report-analyzer-open-source > Compare open-source DMARC analyzers by ingestion, storage, dashboards, security, maintenance, and the operating work each option leaves to you. An open-source DMARC report analyzer can keep aggregate data inside infrastructure you control, but the software is only one part of the system. You still own report ingestion, parser updates, storage, access control, backups, alerting, and incident response. Choose a project by the operating model you can support, not by stars alone. This comparison was checked on July 27, 2026 and should be rechecked before deployment. ## Quick takeaways - Choose between a modern self-hosted web application and a smaller PHP application with relational storage. - Test malformed, duplicate, compressed, and high-volume reports before selecting a project. - Treat repository activity as a maintenance signal, not a security or conformance audit. - Budget for the database, dashboard, authentication, backups, upgrades, and on-call ownership. - Keep raw reports long enough to reproduce parser or aggregation errors. ## Who this comparison is for Self-hosting makes sense when the organization has a strong reason to control the data path and already operates the required infrastructure. Common reasons include data-residency rules, integration with an existing security data platform, an internal engineering requirement, or a need to inspect and transform raw XML before storage. It is a poor fit when nobody owns the mailbox, parser, database, dashboards, and upgrades as one service. DMARC reports arrive continuously, parsers face untrusted compressed XML, and the data becomes less useful when ingestion silently stops. A free license does not remove the operating cost. This article compares two current open-source approaches: - [Resend DMARC Analyzer](https://resend.com/docs/dmarc-analyzer), a browser-based or self-hosted Next.js application with automated report support. - [DmarcSrg](https://dmarc.pl/), a PHP parser, viewer, mailbox collector, and summary generator backed by MariaDB or MySQL. The list is not a certification or an exhaustive directory. DMARC.org maintains a broader [code and libraries resource](https://dmarc.org/resources/code-and-libraries/), but inclusion there also carries no warranty. The durable decision is whether a project's current scope and your operating controls fit. ## How the options were evaluated The evaluation uses ten criteria. Each one maps to a failure an operator may need to detect and repair: - **Input coverage:** IMAP, local files, APIs, object storage, and supported compression types. - **Parser behavior:** current schema support, duplicate handling, malformed input, size limits, and reproducible errors. - **Output model:** raw preservation, normalized JSON or CSV, relational storage, search indexes, and event streaming. - **Analysis surface:** built-in reports, dashboards, filters, alerting, and export. - **Access control:** authentication, authorization, network boundaries, secrets, and auditability. - **Reliability:** retry behavior, failed-message quarantine, health checks, backups, and disaster recovery. - **Scale:** report volume, database growth, retention, indexing, and query cost. - **Maintenance:** supported runtime, dependency updates, release activity, migration work, and rollback. - **Privacy:** report content, source IP data, mailbox credentials, data location, and deletion policy. - **Exit path:** raw export, normalized export, schema documentation, and the effort to change tools later. ![Decision matrix for choosing an open-source DMARC analyzer by operating model.](/images/editorial/dmarc-report-analyzer-open-source/open-source-dmarc-analyzer-selection-matrix.svg "1200x689") *Source: Criteria are derived from the current documentation for [Resend DMARC Analyzer](https://resend.com/docs/dmarc-analyzer) and [DmarcSrg](https://dmarc.pl/), checked July 28, 2026.* ### Resend DMARC Analyzer is the modern application choice Resend DMARC Analyzer is strongest when the organization wants a modern web application that can be used directly in a browser or deployed into an existing Next.js environment. Its documentation describes XML report parsing, readable dashboards, and a self-hosted mode for receiving automated report digests. That convenience still creates service work. You must operate the deployment, report intake, storage, authentication, retention, and monitoring used in your environment. A readable dashboard is not proof that every receiver reported or that every sending source has been assigned to a business owner. ### DmarcSrg is the smaller integrated application choice DmarcSrg combines mailbox or file ingestion, a relational database, a web interface, filtering, DKIM and SPF detail, retention functions, and scheduled summary email. Its smaller stack can be easier to understand than a parser plus a separate search cluster. The tradeoff is a more specific PHP and MariaDB or MySQL operating model. The team owns the web server, database hardening, authentication configuration, mailbox access, backup, and upgrade testing. This can fit a small installation when the built-in views answer the required questions. ## How to choose ### 1. Write the operating requirement before installing anything List the domains, expected daily report count, required retention, data location, analyst roles, alert conditions, and maximum acceptable ingestion gap. Decide whether raw XML must be retained and who may access source IP and authentication data. If the requirement is only to inspect occasional reports, a full search cluster is probably unnecessary. If an MSP must isolate many tenants and prove access boundaries, a single basic dashboard may be insufficient. ### 2. Build an adversarial test corpus Use synthetic or redacted reports that include gzip and zip attachments, duplicate report IDs, overlapping date ranges, unknown extensions, malformed XML, large record counts, IPv6 sources, multiple DKIM results, and policy overrides. [RFC 9990](https://www.rfc-editor.org/rfc/rfc9990.html) defines the current aggregate-report format and explicitly treats report content as a potential attack surface. A parser should reject or quarantine invalid input without losing the evidence required for diagnosis. ```text Expected test result: accepted report -> normalized records + raw source retained duplicate report -> idempotent skip with an observable event malformed report -> quarantined input + actionable error oversized archive -> bounded rejection without resource exhaustion ``` ### 3. Operate a representative pilot Run the candidate on a noncritical reporting address for at least two normal report cycles. Measure ingestion delay, failure rate, database growth, dashboard query time, backup time, and the effort required to identify one legitimate sender and one failing source. Do not expose a default web interface directly to the internet. Put it behind the organization's approved identity, TLS, network, and logging controls. Use a dedicated mailbox credential with the narrowest access the collector supports. ![Reference architecture for a self-hosted DMARC report analyzer from reporting mailbox to analyst workflow.](/images/editorial/dmarc-report-analyzer-open-source/self-hosted-dmarc-analyzer-architecture.svg "1200x958") *Source: The trust boundaries reflect the aggregate-report delivery and security considerations in [RFC 9990](https://www.rfc-editor.org/rfc/rfc9990.html).* ### 4. Test maintenance and exit before production Perform an upgrade, restore a backup into a clean environment, rotate the mailbox credential, and export both raw and normalized data. Record the exact recovery time and any manual schema work. Review repository activity, supported runtimes, open security issues, dependency alerts, and license obligations on the selection date. A project that is active today can slow later. Your plan needs a replacement trigger, not only an installation guide. ## Operating controls that software does not supply The self-hosted service needs an owner, a runbook, and observable health. At minimum, monitor the last successfully processed report, the number of failed attachments, mailbox backlog, storage growth, database errors, certificate expiry, and backup completion. Separate the ingestion identity from analyst identities. Keep secrets outside the image and repository. Restrict outbound network access where practical. Scan images and dependencies, pin versions, and review changes before upgrades. Define retention for raw email, attachments, normalized records, and backups separately. Aggregate reports contain source IP addresses and authentication identifiers. The [DMARC aggregate report guide](/learning/dmarc-aggregate-report-format) explains the data model; privacy and access decisions still belong to the organization. Before selecting an analyzer, use Palisade's [DMARC checker](/tools/dmarc) to confirm that the domain publishes a current policy and aggregate-report destination. That public check does not prove report coverage, parser safety, source ownership, or the operating quality of any analyzer. If the pilot shows that the team cannot own ingestion, storage, upgrades, access control, and incident response, compare a managed option against the real self-hosting cost rather than a zero-dollar license. Palisade's [DMARC Agent](https://docs.palisade.email/guides/fixing-authentication-issues/) turns DMARC report findings into source-specific authentication tickets and recommended actions, but it cannot guarantee that every receiver reports or classify a sender without business context. [Get started](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=article_assisted&utm_content=dmarc-report-analyzer-open-source) when the written requirements call for ongoing managed operations. The broader [DIY versus managed DMARC guide](/learning/should-you-diy-dmarc-or-use-an-automated-service) helps assign that operating decision. The [DMARC learning hub](/learning/dmarc) remains the protocol reference. ## Sources and further reading - [RFC 9990: DMARC aggregate reporting](https://www.rfc-editor.org/rfc/rfc9990.html) - [Resend DMARC Analyzer documentation](https://resend.com/docs/dmarc-analyzer) - [DmarcSrg documentation](https://dmarc.pl/) - [DMARC.org code and libraries](https://dmarc.org/resources/code-and-libraries/) ## Frequently asked questions ### Is an open-source DMARC analyzer free to operate? No. The license may have no purchase price, but the organization still pays for infrastructure, engineering time, monitoring, backups, upgrades, incident response, and security review. ### Is Resend DMARC Analyzer a complete managed DMARC service? No. It can render reports in a browser or run as a self-hosted application, but the operator remains responsible for the deployed intake, storage, access, monitoring, and response process. ### Should I choose the repository with the most stars? No. Stars can signal interest, but they do not prove parser correctness, security, maintenance capacity, or fit. Test the current code against your report corpus and operating requirements. ### Can a self-hosted analyzer tell me every service that sends mail? Only partially. It can show sources observed by participating receivers in the reports you receive. It cannot prove that every message or receiver is represented, and business ownership still requires investigation. ### When should I use a managed DMARC platform instead? Use a managed platform when the organization needs ongoing monitoring, guided sender identification, support, or multi-domain operations but cannot reliably own the ingestion, storage, security, upgrade, and response work of a self-hosted service. --- # dmarcian review: what it does and who it fits Canonical: https://www.palisade.email/learning/dmarcian-review > An evidence-based dmarcian review: the platform modules, what each tier includes, which features are gated to Enterprise, and the sender profiles it fits. dmarcian is a DMARC monitoring platform that turns aggregate reports into a per-source view of who sends as your domains, then recommends the SPF and DKIM changes needed to reach enforcement. Its own publishing guide directs customers to create the DMARC record in their DNS hosting provider. Plans run from a free non-business tier to published tiers metered by both active domains and monthly message volume, with domain discovery, API access, and single sign-on reserved for Enterprise. Figures below were checked on 28 July 2026. ## Quick takeaways - dmarcian's core value is report interpretation: Domain Overview, Detail Viewer, Source Viewer, and Alert Central turn raw aggregate XML into per-source authentication status and remediation guidance. - dmarcian's publishing guide directs customers to add the DMARC TXT record at their DNS provider. That deployment model is worth checking against the DNS workflow you want. - Pricing is metered on two axes at once, active domains and DMARC-capable messages per month, so a small domain count with heavy volume can cost the same as a large portfolio. - Automatic Domain Discovery, the API, and single sign-on are documented as Enterprise features, so multi-domain automation arrives at the top tier rather than the middle. - Report history is tiered too, from one month on the free plan to unlimited on Enterprise, which matters because DMARC problems often surface over weeks. - A free 30-day trial of the paid plans requires no payment method up front, so the platform can be evaluated against your own report volume before committing. ## Who this comparison is for This review is for someone evaluating dmarcian on its own merits: an IT lead, a deliverability owner, or an MSP technician who has decided that reading raw DMARC XML by hand does not scale and now wants to know what this specific platform does, what it gates behind which tier, and where it stops. It assumes you already know why you want DMARC reporting. If you are still deciding whether to interpret reports yourself or hand that to a service, start with [whether to run DMARC yourself or use an automated service](/learning/should-you-diy-dmarc-or-use-an-automated-service) and come back once that is settled. If you have already chosen to leave dmarcian and want to know how a switch works in practice, that is a different question with its own page: see [how a migration to Palisade actually works](/dmarcian-dmarc-alternative). ## What dmarcian does [dmarcian's DMARC Management Platform documentation](https://dmarcian.com/dmarc-management-platform/) describes four named modules and what each one delivers. **Domain Overview** is described as a centralized command center across a domain portfolio. It summarizes authentication status, shows where abuse attempts originate, and displays domain health and compliance status. **Detail Viewer** is the granular layer: a source-by-source breakdown, analysis of authentication issues, detailed compliance reporting, and step-by-step remediation guidance. **Source Viewer** consolidates DMARC-capable sending sources across domains and domain groups, automatically categorizes legitimate versus suspicious sources, and produces automated recommendations for SPF and DKIM configuration adjustments. **Alert Central** delivers real-time customizable alerts for domain events, and can send them over email, Slack, Teams, or webhooks. Alongside the platform, [dmarcian publishes a set of free diagnostic tools](https://dmarcian.com/), including a DMARC Domain Checker, DMARC Inspector, DMARC Record Wizard, SPF Surveyor, DKIM Inspector and Validator, BIMI tools, and an XML to Human Converter. The same page lists deployment, onboarding, support, and consultation services, and names individuals and small businesses, organizations and enterprises, and MSPs and IT agencies as its audiences. One boundary is worth stating carefully because it shapes every comparison you will make. dmarcian's [DMARC publishing guide](https://dmarcian.com/how-to-publish-a-dmarc-record/) tells the operator to access the domain's DNS hosting provider and publish the DMARC TXT record there. Its platform documentation also describes remediation guidance, automated recommendations, policy recommendations, and risk scoring. It does document more than pure reporting at the subdomain layer: Intelligent Subdomain Management detects new subdomains and offers "subdomain risk scoring, automated policy inheritance options and bulk configuration tools." The public page does not explain whether those options write DNS, so confirm that directly if hands-off subdomain policy matters to you. ![dmarcian Domain Overview dashboard with DMARC-capable volume, source compliance, threat map, and domain status.](/images/editorial/dmarcian-review/dmarcian-domain-overview-dashboard.png "2002x1418") *Source: [dmarcian product page](https://dmarcian.com/), checked July 17, 2026. First-party public interface excerpt, unmodified.* ## What each tier includes [dmarcian's pricing page](https://dmarcian.com/pricing/) publishes the current structure below, checked on 28 July 2026. Prices change, so confirm current figures before you budget. ```text Plan Monthly Yearly Domains Messages/month History Users Domain groups Personal $0 $0 2 1,250 1 month 1 1 Basic $24 $19.99 2 100,000 3 months 1 1 Plus $240 $199 8 1,000,000 1 year 3 3 Enterprise $600 $499 15 5,000,000 unlimited unlimited unlimited Custom not publicly priced ``` Prices are USD, with stated parity for CAD and EUR. The yearly column is the effective monthly rate when billed annually, and dmarcian labels the domain-group allowances "standard" on every tier below Enterprise. Personal is restricted to non-business domains such as those hosting family photos or hobbies, so it is an evaluation and personal-use tier rather than a free business plan. All paid plans include a 30-day trial, which dmarcian states does not require a payment method unless you decide to continue. The detail that catches people out is the double meter. Every tier caps both active domains and DMARC-capable messages per month, and you are held to whichever ceiling you hit first. A company with two domains sending a million messages a month is not a Basic customer despite the domain count. Overage pricing for message volume is referenced but not published, so model your own volume before committing. ## How the options were evaluated To keep this assessment checkable rather than impressionistic, dmarcian was read against five criteria, each answered only from its own current documentation. **Report interpretation.** Does the product turn aggregate XML into a per-source view an operator can act on? Documented and strong: this is the core of Domain Overview, Detail Viewer, and Source Viewer. **Path to enforcement.** Does it tell you what to change to reach a stricter policy safely? The policy values themselves are defined by [RFC 9989](https://www.rfc-editor.org/rfc/rfc9989.html), which sets out `p=none`, `p=quarantine`, and `p=reject` and the identifier alignment a message must satisfy. dmarcian documents remediation guidance, SPF and DKIM recommendations, [subdomain policy](/learning/glossary/dmarc-sp) recommendations, and a guide for publishing the DMARC record through the domain's DNS provider. **Portfolio scale.** How well does it handle many domains? Documented, with a caveat: domain groups are published per tier, from one on the lower plans to unlimited on Enterprise, and Automatic Domain Discovery is one of the three features marked Enterprise-only, so the discovery step that helps large portfolios arrives at the top tier. Bulk configuration tools are described without a tier marker. **Integration and access control.** API access and single sign-on are documented as Enterprise features. The pricing grid separately lists two-factor authentication on all four subscription tiers and User Access Controls on Plus and Enterprise, so access controls should be assessed by the specific control you need rather than treated as one Enterprise-only bundle. **Cost predictability.** Documented and mixed: published tier prices are a real advantage, while the twin domain and volume meters plus unpublished overage rates make the top of a tier harder to forecast. Two adjacent standards are worth separating from the platform page, because the pricing grid documents more than the platform page does. [TLS Reporting](https://dmarcian.com/tls-reporting/) is a published plan feature on all four subscription tiers, including the free Personal plan, and its own page states that every dmarcian account gets a unique SMTP TLS reporting address. BIMI Inspector and Builder is likewise published across all four tiers. Neither is a gap, even though the platform page does not describe them. MTA-STS is genuinely absent from both pages. Three things are deliberately recorded as not publicly documented rather than as missing features: MTA-STS, the multi-tenant or per-client specifics for MSPs (although MSPs are named as an audience), and both Custom-tier pricing and volume overage rates. Absence from a web page is not evidence a product cannot do something, and this review does not treat it that way. ## Where dmarcian fits well It fits a team whose main problem is comprehension. If you have DMARC records published, reports arriving, and no clear picture of which of your senders are failing alignment, dmarcian's per-source view is squarely aimed at that and its published pricing lets you budget without a sales call. It also fits an organisation that wants outside help rather than only software, given the separately sold deployment, onboarding, and consultation services. ## Where it may not fit Three profiles should look carefully before committing. **High volume on few domains.** The message meter, not the domain count, will set your tier. Check your monthly DMARC-capable volume against the ceilings above before assuming a lower plan applies. **Teams that need API or SSO early.** Both are documented as Enterprise features. If programmatic access or SAML is a requirement rather than a nice-to-have, that requirement sets your tier regardless of how many domains you run. **Long diagnostic windows on lower tiers.** Three months of history on Basic is workable, but intermittent authentication failures from a quarterly campaign or a seasonal sender can fall outside that window. ## How to choose Decide on the two axes that actually move the cost and the outcome, in this order. First, measure your real monthly DMARC-capable message volume and count your active sending domains. Whichever ceiling you reach first determines your tier on any volume-metered platform, dmarcian included, so this number decides your budget more than a feature list does. Second, decide which DNS operating model you want. dmarcian's public guide directs the operator to publish a DMARC TXT record at the DNS provider. Palisade offers two documented paths: with [Hosted DMARC](https://docs.palisade.email/page-breakdowns/hosted-dmarc/), it publishes and maintains the DMARC record through CNAME delegation after the operator reviews and applies the update; with external DNS, the operator copies the generated record to the DNS provider. dmarcian's subdomain page lists automated policy inheritance options without explaining whether they write DNS, so verify that directly if hands-off subdomain policy is what you are shopping for. Palisade can be assessed against the same operational criteria only where public evidence is available. Its [DMARC Agent guide](https://docs.palisade.email/guides/fixing-authentication-issues/) documents report-based authentication tickets with affected-source details and recommended actions, while Hosted DMARC documents a delegated-record path. This review does not make a portfolio-scale, access-control, or plan-price comparison for Palisade because those terms are outside the evidence collected here. The useful comparison is which product gives your team a clear next action and a DNS workflow you can operate safely. If your answer is that you want published pricing, strong report visualisation, and optional professional services, dmarcian is a well-documented fit. If your answer is that you want the report-to-action step to be shorter and you do not want domain discovery or API access gated to a top tier, it is worth checking alternatives against the same five criteria above rather than against a feature grid. ## Check your own domain before you shortlist any platform Whichever platform you evaluate, the useful first step is knowing what your domain publishes right now, because that determines whether reports will even arrive and whether a trial will show you anything. Run your sending domain through Palisade's [DMARC record checker](/tools/dmarc) to read your published policy, alignment tags, and report addresses exactly as a receiver resolves them. That check reads public DNS; it does not send mail, prove how any message was handled, or change your configuration. Once reports are arriving, the remaining question is how a platform turns the evidence into work. Palisade's [DMARC Agent guide](https://docs.palisade.email/guides/fixing-authentication-issues/) describes report-based authentication tickets with affected-source details and recommended actions. If you use Hosted DMARC, the reviewed update can be published through its CNAME delegation; with external DNS, your team applies the generated record at its DNS provider. Stronger authentication supports better deliverability; it does not guarantee placement. [Get started](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=compare&utm_content=dmarcian-review) You can also see the full set of [DMARC platform comparisons](/compare) if you are shortlisting more than one. ## Sources and further reading - [dmarcian pricing page](https://dmarcian.com/pricing/) - [dmarcian DMARC Management Platform](https://dmarcian.com/dmarc-management-platform/) - [dmarcian guide to publishing a DMARC record](https://dmarcian.com/how-to-publish-a-dmarc-record/) - [Palisade Hosted DMARC documentation](https://docs.palisade.email/page-breakdowns/hosted-dmarc/) - [Palisade guide to fixing authentication issues](https://docs.palisade.email/guides/fixing-authentication-issues/) - [RFC 9989: Domain-based Message Authentication, Reporting, and Conformance (DMARC)](https://www.rfc-editor.org/rfc/rfc9989.html) ## Frequently asked questions ### What does dmarcian actually do? It collects the DMARC aggregate reports receivers send about your domains and turns them into a readable per-source view. Its modules summarize authentication status across your domain portfolio, break down results source by source, categorize legitimate versus suspicious senders, and alert you to domain events. It then recommends the SPF and DKIM changes needed to reach a stricter policy. ### How much does dmarcian cost? Published rates as of 28 July 2026 are $0 for the non-business Personal tier, $24 per month for Basic, $240 per month for Plus, and $600 per month for Enterprise, with lower effective rates when billed yearly and a Custom tier that is not publicly priced. Each tier caps both active domains and monthly DMARC-capable messages, and you are held to whichever limit you reach first. ### Does dmarcian tell me to publish DNS records? Yes. Its publishing guide tells customers to access the domain's DNS hosting provider and add the DMARC TXT record there. The platform page separately describes remediation guidance and subdomain policy tools, but it does not explain whether its automated policy inheritance options write DNS. Confirm that behaviour directly if it is a requirement. ### Is dmarcian suitable for MSPs? Yes, at least as a stated audience: it names MSPs and IT agencies among the groups it serves and sells deployment and onboarding services aimed at that market. The specifics of multi-tenant or per-client management are not detailed publicly, so treat those as unconfirmed rather than absent and ask directly if per-client separation is a requirement for you. ### What is the difference between dmarcian's free tools and its paid platform? The free tools are one-off diagnostics you run against a domain, such as the DMARC Inspector, SPF Surveyor, and DKIM Validator. They check what is published at a moment in time. The paid platform is continuous: it ingests the aggregate reports receivers send over time, so it can show which sources keep failing and whether a change actually worked. Some tooling appears in both places, since the pricing grid lists BIMI Inspector and Builder as a plan feature on every subscription tier as well as among the free tools. --- # One-click unsubscribe and the RFC 8058 header pair Canonical: https://www.palisade.email/learning/one-click-unsubscribe > One-click unsubscribe uses RFC 8058 headers, DKIM coverage, and an HTTPS POST endpoint that accepts mailbox-provider requests without redirects. [RFC 8058](https://datatracker.ietf.org/doc/html/rfc8058) defines one-click unsubscribe for list senders. A qualifying message needs a `List-Unsubscribe` header containing an HTTPS URI, a `List-Unsubscribe-Post: List-Unsubscribe=One-Click` header, and valid DKIM coverage for both fields. The sender's HTTPS endpoint must accept the mailbox provider's POST without cookies, HTTP authorization, or an HTTPS redirect. ## Quick takeaways - RFC 8058 is an IETF Proposed Standard published in January 2017. - One-click unsubscribe requires both `List-Unsubscribe` and `List-Unsubscribe-Post`. - The `List-Unsubscribe` field MUST contain one HTTPS URI for RFC 8058 functionality. - A valid DKIM signature MUST cover both one-click headers and include them in its `h=` tag. - A mailbox provider SHOULD send `multipart/form-data` and MAY send `application/x-www-form-urlencoded`; the endpoint must accept either encoding. - RFC 8058 defines a protocol mechanism. It does not itself create legal compliance or require every mailbox provider to show an unsubscribe control. ## Who is affected? RFC 8058 affects operators sending mailing-list, marketing, or subscribed email who want a supporting mail receiver to offer a one-click unsubscribe action. The sender publishes the headers and operates, or configures, the endpoint. The receiver obtains user consent through its own interface and sends the POST request. The older [`List-Unsubscribe` header defined by RFC 2369](https://datatracker.ietf.org/doc/html/rfc2369) predates RFC 8058. RFC 2369 defines list-command URLs in message headers. RFC 8058 adds the signal that permits a receiver to perform the constrained one-click POST transaction. This is separate from the authentication controls explained in [Palisade's email authentication guide](/learning/what-is-email-authentication-and-why-does-it-matter). SPF, DKIM, and DMARC establish authentication and policy signals. RFC 8058 defines a list-removal request path. Google's [Email sender guidelines](https://support.google.com/a/answer/81126) apply one-click unsubscribe requirements to bulk senders, which its [sender guidelines FAQ](https://support.google.com/mail/answer/14229414) defines as sending close to 5,000 messages or more to personal Gmail accounts in a 24-hour period. For marketing and subscribed messages, Google requires one-click unsubscribe and a clearly visible unsubscribe link in the message body. Yahoo's [Sender Hub best practices](https://senders.yahooinc.com/best-practices/) also set bulk-sender expectations for a functioning `List-Unsubscribe` mechanism on marketing and subscribed traffic. RFC 8058 does not replace a visible unsubscribe link, suppression-list governance, or applicable law. The [FTC CAN-SPAM compliance guide](https://www.ftc.gov/business-guidance/resources/can-spam-act-compliance-guide-business) describes separate obligations for commercial email in the United States. ## What are the requirements? ### The message includes the RFC 8058 header pair RFC 8058 says `List-Unsubscribe` MUST contain one HTTPS URI. The field may contain another URI, such as a `mailto:` URI. `List-Unsubscribe-Post` MUST contain the single key and value `List-Unsubscribe=One-Click`. ```text List-Unsubscribe: <https://unsubscribe.yourdomain.com/list/opaque-token>, <mailto:unsubscribe@yourdomain.com> List-Unsubscribe-Post: List-Unsubscribe=One-Click ``` > These values are illustrative only. Generate recipient-specific endpoint values in your own sending system. Do not publish live recipient tokens in documentation, tickets, or test messages. The HTTPS URI needs enough information to identify the recipient and applicable list without another form submission. RFC 8058 does not prescribe a token format. Use an opaque, hard-to-forge value and avoid placing recipient data directly in the URI. ![RFC 8058 header pair showing the HTTPS List-Unsubscribe URI, List-Unsubscribe-Post value, and required DKIM coverage](/images/editorial/one-click-unsubscribe/one-click-unsubscribe-header-pair.svg "1200x579") *Source: [RFC 8058: Signaling One-Click Functionality for List-Unsubscribe Email Header Fields](https://datatracker.ietf.org/doc/html/rfc8058), checked 2026-07-28.* ### DKIM must cover both headers RFC 8058 requires `List-Unsubscribe` and `List-Unsubscribe-Post` to be covered by a valid DKIM signature and included in the signature's `h=` tag. A vendor dashboard showing that DKIM is enabled does not prove that the delivered campaign message signed these particular headers. ```text DKIM-Signature: v=1; a=rsa-sha256; d=yourdomain.com; h=from:subject:date:list-unsubscribe:list-unsubscribe-post; ... ``` This is an illustrative header fragment, not a complete DKIM signature. Your sending system generates the selector, signature data, and signed-header list. Inspect the delivered message from the real production path. Message transformations, alternate relays, and separate campaign tools can change headers after a general configuration check. RFC 8058 also recommends an opaque or hard-to-forge component in the HTTPS URI to reduce forged-message and direct-POST risks. ### The receiver sends a constrained HTTPS POST RFC 8058 says a mail receiver can perform a one-click unsubscribe by sending an HTTPS POST to the URI in `List-Unsubscribe`. The mailbox provider SHOULD send `multipart/form-data` and MAY send `application/x-www-form-urlencoded`. The endpoint must accept either encoding. ```text List-Unsubscribe=One-Click ``` The POST request MUST NOT include cookies or HTTP authorization. The mail sender MUST NOT return an HTTPS redirect. The endpoint cannot depend on a browser session, login page, confirmation screen, JavaScript, or a redirected POST. ![RFC 8058 flow from the signed header pair through a mailbox-provider action to the sender HTTPS POST endpoint and suppression result](/images/editorial/one-click-unsubscribe/one-click-unsubscribe-flow.svg "1200x720") *Source: [RFC 8058: Signaling One-Click Functionality for List-Unsubscribe Email Header Fields](https://datatracker.ietf.org/doc/html/rfc8058), checked 2026-07-28.* Make successful unsubscribe handling idempotent as implementation guidance. A repeated valid request for an already-suppressed recipient should leave that recipient suppressed and should not create duplicate work. RFC 8058 does not separately require idempotency, but it is appropriate for an endpoint that may receive retries. ## When does the requirement take effect? RFC 8058 was published in January 2017 as an IETF Proposed Standard. It remains the controlling protocol document for the header pair, DKIM coverage, and POST constraints. It does not establish a universal sender deadline or require receivers to render a particular interface. Google states that its bulk-sender requirements began on February 1, 2024, for senders that send close to 5,000 messages or more to personal Gmail accounts in a 24-hour period. Google's [sender guidelines FAQ](https://support.google.com/mail/answer/14229414) documented a transition through June 1, 2024 for senders that already had an unsubscribe link and needed to add one-click unsubscribe to commercial and promotional messages. Yahoo uses its own policy wording. Its current sender guidance says bulk senders must implement a functioning `List-Unsubscribe` header that supports one-click unsubscribe for marketing and subscribed messages, honor unsubscribe requests within two days, and treat the RFC 8058 POST method as highly recommended. Those are Yahoo policy terms, not amendments to RFC 8058. For the broader, current provider checklist, use the [sender requirements hub](/learning/gmail-bulk-sender-guidelines). The [2024 Gmail and Yahoo sender update](/learning/gmail-bulk-sender-guidelines) provides the related historical context. ## How do I implement the requirement? ### 1. Identify the exact production sending path Identify the ESP, CRM, or application that composes the marketing or subscribed message. Determine where it inserts the headers and where the final DKIM signature is applied. Send a controlled message through the same path used for recipients. A staging application, alternate return path, or separate relay can produce different headers and DKIM signatures. ### 2. Configure the HTTPS unsubscribe URI Configure an HTTPS URI that the sender can use to identify the subscription and process the request without a cookie, login, HTTP authorization, or confirmation page. If a provider operates the endpoint, compare a delivered test message with that provider's current documentation. If your team operates it, test both permitted content encodings and confirm that the endpoint returns a direct response rather than a redirect. ### 3. Add the one-click signal before DKIM signing Add `List-Unsubscribe-Post: List-Unsubscribe=One-Click` with the HTTPS `List-Unsubscribe` URI. Confirm that the final valid DKIM signature includes both header names in `h=`. A DKIM pass alone is incomplete evidence. The relevant question is whether the valid signature on the delivered message covers the exact one-click headers. ### 4. Keep the visible unsubscribe path and suppression process Keep a visible unsubscribe link in the message body where applicable provider rules require one. Ensure the one-click endpoint updates the suppression source used by every relevant production sender, not only one campaign system. Do not make the one-click endpoint a general account-management route. Limit it to the recipient and list represented by its opaque identifier. ## How do I validate compliance? Validate RFC 8058 at the message and endpoint layers. - Send a real test campaign through the production path and inspect its raw headers. - Confirm `List-Unsubscribe` includes an HTTPS URI and `List-Unsubscribe-Post` has the exact one-click value. - Check a valid `DKIM-Signature` header and confirm its `h=` tag covers both one-click headers. - Send controlled POST requests using `multipart/form-data` and `application/x-www-form-urlencoded`. - Confirm neither request needs cookies or HTTP authorization and neither receives an HTTPS redirect. - Use a safely testable recipient, then verify that the source-of-truth suppression system records the removal. - Repeat a valid request to test idempotent handling, then test an invalid or expired token without exposing recipient data in logs. A public authentication check can still help identify published authentication posture. [Palisade's Email Security Score](/tools/email-security-score) can inspect public controls, but it cannot inspect `List-Unsubscribe` headers in a delivered message or test an unsubscribe endpoint. ## Confirm the rest of your bulk sender setup After you have validated the delivered message and endpoint behavior, review the wider Gmail and Yahoo requirements that apply to your sending program. [See the full Gmail and Yahoo bulk sender checklist](/learning/gmail-bulk-sender-guidelines) That checklist and public authentication checks do not prove that a delivered message includes the RFC 8058 header pair or that its unsubscribe endpoint accepts the required POST. ## Sources and further reading - [RFC 8058: Signaling One-Click Functionality for List-Unsubscribe Email Header Fields](https://datatracker.ietf.org/doc/html/rfc8058) - [RFC 2369: List-Unsubscribe and other mailing-list header fields](https://datatracker.ietf.org/doc/html/rfc2369) - [Google Email sender guidelines](https://support.google.com/a/answer/81126) - [Google sender guidelines FAQ](https://support.google.com/mail/answer/14229414) - [Yahoo Sender Hub best practices](https://senders.yahooinc.com/best-practices/) - [FTC CAN-SPAM Act compliance guide](https://www.ftc.gov/business-guidance/resources/can-spam-act-compliance-guide-business) ## Frequently asked questions ### Is a `mailto:` unsubscribe address enough for RFC 8058? No. RFC 8058 requires `List-Unsubscribe` to contain one HTTPS URI. The header may also contain a `mailto:` URI, but that does not replace the HTTPS endpoint required for one-click functionality. ### Must both RFC 8058 headers be covered by DKIM? Yes. A valid DKIM signature MUST cover `List-Unsubscribe` and `List-Unsubscribe-Post`, and both fields must appear in the signature's `h=` tag. ### Can a one-click unsubscribe endpoint redirect to a confirmation page? No. RFC 8058 says the mail sender MUST NOT return an HTTPS redirect for the one-click POST. A visible body-link unsubscribe flow can have different behavior, but it is not the RFC 8058 one-click transaction. ### Must a mailbox provider use `multipart/form-data`? No. RFC 8058 says the mailbox provider SHOULD use `multipart/form-data` and MAY use `application/x-www-form-urlencoded`. The endpoint must accept either encoding. ### Does RFC 8058 make a sender legally compliant? No. RFC 8058 defines a technical message-header and POST mechanism. Legal obligations, visible unsubscribe links, suppression timing, and provider-specific requirements are separate layers. --- # Why is my email going to spam in Outlook but not Gmail? Canonical: https://www.palisade.email/learning/why-is-my-email-going-to-spam-in-outlook-but-not-gmail > Mail lands in Outlook spam but not Gmail because Microsoft weighs IP reputation and its own authentication rules differently. Here's how to diagnose and fix it. Your mail lands in Outlook's Junk folder but Gmail's inbox because Microsoft and Google score senders differently: Microsoft leans heavily on your sending **IP reputation** and on its own consumer authentication rules, while Google weights **[domain reputation](/tools/domain-reputation)** and engagement. The same message can pass Gmail's checks and still trip Outlook's if your IP is unknown or lightly complained-about, or if you send high volume to Outlook.com without full SPF, DKIM, and DMARC. Start by confirming all three authentication checks pass and align, then check your IP reputation in Microsoft's free SNDS tool. ## Quick Takeaways - Outlook filtering is **IP-reputation-first**; Gmail is **domain-reputation-first**, so a clean domain with a cold or shared IP can inbox at Gmail and junk at Outlook. - Since **May 5, 2025**, Microsoft routes high-volume mail (5,000+/day to Outlook.com, Hotmail, Live, MSN) to Junk unless it has SPF, DKIM, **and** DMARC, per [Microsoft's sender requirements](https://techcommunity.microsoft.com/blog/microsoftdefenderforoffice365blog/strengthening-email-ecosystem-outlook%E2%80%99s-new-requirements-for-high%E2%80%90volume-senders/4399730). - The hard-reject version of that rule returns `550 5.7.515 Access denied, sending domain … does not meet the required authentication level`. - Check your IP reputation at Microsoft's free [Smart Network Data Services (SNDS)](https://sendersupport.olc.protection.outlook.com/snds/index) and enroll in the Junk Email Reporting Program (JMRP) to see complaints. - Gmail passing does **not** mean you are authenticated correctly for Outlook: verify SPF, DKIM, and DMARC all pass and align with your From domain. - Content and links that Gmail tolerates can still raise Outlook's spam score; Outlook is more sensitive to spammy formatting and low text-to-image ratios. ## Why does Outlook junk mail that Gmail delivers? Because the two providers optimize for different signals. Microsoft's consumer filters (Outlook.com, Hotmail, Live, MSN) put a lot of weight on the reputation of the **IP address** you send from, tracked per IP through its [SNDS](https://sendersupport.olc.protection.outlook.com/snds/index) program. Google's filters put more weight on **domain reputation** and recipient engagement: opens, replies, and "not spam" actions build a domain's standing over time. That difference explains the split you are seeing. If you send from a new, shared, or lightly-warmed IP, Gmail may still inbox you on the strength of your domain history and engagement, while Outlook (seeing an IP it does not trust) drops you in Junk. It also cuts the other way: a brand-new domain on a well-established IP can inbox at Outlook and struggle at Gmail. Neither provider is "wrong"; they are asking different questions about the same message. Authentication is the common denominator. Both require [email authentication](/learning/what-is-email-authentication-and-why-does-it-matter), but Microsoft made its consumer rules explicit and enforced them in 2025, so a gap that Gmail quietly tolerates can become a hard filter at Outlook. ## What signal maps to what fix? Read the symptom, then act. This table covers the common Outlook-but-not-Gmail patterns: | Signal you see | What it means | First action | |---|---|---| | Inbox at Gmail, Junk at Outlook, all auth passes | IP reputation or Outlook-specific filtering, not authentication | Check the sending IP in [SNDS](https://sendersupport.olc.protection.outlook.com/snds/index); warm the IP if new | | `550 5.7.515 … does not meet the required authentication level` | High-volume mail without full SPF + DKIM + DMARC | Publish all three and confirm DMARC alignment | | Junk at Outlook only after volume increased | Crossed Microsoft's 5,000/day high-volume threshold | Ensure DMARC is present and passing before scaling | | `5.7.1` / blocked at Outlook | IP on a Microsoft block or poor SNDS reputation | Review SNDS status; submit sender support / mitigation | | Gmail fine, Outlook flags content | Spammy formatting, image-heavy, risky links | Fix text-to-image ratio and link hygiene | ## Is my email properly authenticated for Outlook? Confirm that SPF, DKIM, and DMARC all pass **and align** with your From domain. Passing Gmail is not proof you have. Since May 5, 2025, [Microsoft requires](https://techcommunity.microsoft.com/blog/microsoftdefenderforoffice365blog/strengthening-email-ecosystem-outlook%E2%80%99s-new-requirements-for-high%E2%80%90volume-senders/4399730) any sender pushing 5,000 or more messages a day to its consumer domains to publish SPF and DKIM that pass, and a DMARC record of at least `p=none` that aligns with SPF or DKIM. Non-compliant high-volume mail is filtered to Junk; the enforced form returns `550 5.7.515 Access denied, sending domain [yourdomain] does not meet the required authentication level`, documented on [Microsoft's 550 5.7.515 support page](https://support.microsoft.com/en-us/outlook/fix-ndr-error-550-5-7-515-in-outlook-com). Work through it in order: 1. **Publish SPF** listing every server that sends for your domain, and verify it with the [SPF checker](/tools/spf). Keep it under the 10-DNS-lookup limit. 2. **Enable DKIM** in your sending platform and publish the public key; confirm the signature validates with the [DKIM checker](/tools/dkim). 3. **Publish DMARC** at `_dmarc.yourdomain.com` starting at `v=DMARC1; p=none; rua=mailto:reports@yourdomain.com`, and check it with the [DMARC checker](/tools/dmarc). 4. **Confirm alignment**: the domain that passes SPF or DKIM must match your visible From domain. This is the step people miss, and it is exactly the failure behind [Microsoft 365's 550 5.7.x access-denied bounces](/learning/fix-microsoft-365-550-5-7-x-access-denied) too. Read the message headers to verify: open the `Authentication-Results` header on a message that landed in Outlook Junk and check that `spf=pass`, `dkim=pass`, and `dmarc=pass` all reference your domain. ## How do I check and fix my IP reputation at Outlook? Use Microsoft's free tools, because Outlook's decision is driven by data you can actually see. [Smart Network Data Services (SNDS)](https://sendersupport.olc.protection.outlook.com/snds/index) shows how Microsoft rates each of your sending IPs: traffic volume, spam-trap hits, and complaint rate. If SNDS flags an IP as red or shows a high complaint rate, that is almost certainly why Outlook junks you while Gmail does not. Two Microsoft programs do the heavy lifting: - **SNDS**: request access for your sending IP ranges and monitor the reputation and complaint data Microsoft records per IP. It is IP-centric, so it is most useful when you control a dedicated IP. - **JMRP (Junk Email Reporting Program)**: a complaint feedback loop that forwards copies of messages Outlook users mark as junk, so you can suppress those recipients. Enroll and start removing complainers. If you send from a **shared IP** (most people on an ESP do), you inherit the reputation of everyone else on it, and you cannot fix that pool directly: your levers are cleaning your own list and, if the pool is bad, asking your provider to move you or moving to a dedicated IP you can warm. If you moved to a new IP recently, warm it: ramp volume gradually over days to weeks so Microsoft builds trust before you send at full scale. ## Why does volume change Outlook's behavior but not Gmail's? Because Microsoft's explicit consumer rules trigger at a volume threshold. Below roughly 5,000 messages a day to Outlook.com addresses you may skate by on a partial setup; cross it and Microsoft's [high-volume requirements](https://techcommunity.microsoft.com/blog/microsoftdefenderforoffice365blog/strengthening-email-ecosystem-outlook%E2%80%99s-new-requirements-for-high%E2%80%90volume-senders/4399730) apply, and a missing or misaligned DMARC record that never mattered before suddenly sends everything to Junk. This is the classic "it worked until we grew" report, nothing about your content changed, you simply tripped a rule that scales with volume. The fix is to get fully compliant *before* you scale: SPF, DKIM, and a passing, aligned DMARC record in place while you are still small, so growth never flips a switch. If your overall picture is broader than one provider, our guide on [why emails land in spam and how to fix it](/learning/why-am-i-not-receiving-emails-how-to-troubleshoot) covers the wider triage. ## Common issues with Outlook spam filtering ### Everything passes authentication but Outlook still junks me This is the signature of an IP-reputation problem. Check the sending IP in SNDS: a poor score or high complaint rate will junk you at Outlook while Gmail, weighting your domain history, still delivers. Clean your list, enroll in JMRP to shed complainers, and warm the IP if it is new. ### Only Outlook.com/Hotmail addresses are affected, not corporate Microsoft 365 Consumer Outlook.com and hosted Microsoft 365 tenants apply filtering differently. If corporate 365 recipients are the ones blocking you, you are more likely hitting a tenant-level rule or the `550 5.7.x` access-denied path, see [fixing Microsoft 365 550 5.7.x access denied](/learning/fix-microsoft-365-550-5-7-x-access-denied). Consumer-only junking points back at IP reputation and the high-volume rules. ### My content is fine but Outlook flags it anyway Outlook is stricter than Gmail on formatting. A high image-to-text ratio, link shorteners, mismatched or bare display links, and "spammy" phrasing raise its score faster than Gmail's. Send a plain, balanced message as a control; if that inboxes and your campaign does not, the content is contributing. ### It started right after we increased send volume You almost certainly crossed Microsoft's 5,000/day high-volume threshold. Confirm SPF, DKIM, and DMARC all pass and align, because that rule now applies to you even though it did not at lower volume. ## Frequently asked questions ### Does passing Gmail mean I will pass Outlook? No. Gmail and Outlook weight signals differently: Gmail leans on domain reputation and engagement, Outlook on IP reputation and its consumer authentication rules. Verify Outlook specifically by sending a test to an Outlook.com address and reading the `Authentication-Results` header. ### Do I need a dedicated IP to inbox at Outlook? Not necessarily. Plenty of senders inbox from well-managed shared pools. A dedicated IP helps when you send enough volume to build your own reputation and want to control it, but it must be warmed. A cold dedicated IP is worse than a good shared one. ### What is the fastest way to see why Outlook junks me? Request SNDS access for your sending IP and read the reputation and complaint data. Combined with the `Authentication-Results` header on a junked message, that tells you within minutes whether the problem is IP reputation or authentication. The free [email spam checker](/tools/email-deliverability-test) reads both sides from one message you send: it parses the authentication results and checks the sending IP against major blocklists. ### Will a stricter DMARC policy help delivery at Outlook? Having a passing, aligned DMARC record is what matters for Microsoft's high-volume rule; moving from `p=none` to `p=reject` mainly protects you from spoofing rather than boosting inbox placement. Fix alignment and IP reputation first: those move Outlook placement, policy strength does not. Palisade automates the authentication side of this for every domain you manage: it publishes correct, aligned SPF, DKIM, and DMARC records, reads your DMARC aggregate reports to surface unauthenticated or unaligned senders before they cost you delivery, and flags when a new sending source could break placement at Outlook or Gmail. Run your domain through the free [Email Security Score](/tools/email-security-score) tool to see exactly which of Microsoft's requirements you meet today. ## Related reading - [Why is Yahoo blocking my emails as unauthenticated?](/learning/why-is-yahoo-blocking-my-emails-as-unauthenticated) - [Why is Gmail rejecting my emails with a 550 error?](/learning/smtp-error-codes/550-5-7-26) - [Why am I not receiving emails? How to troubleshoot](/learning/why-am-i-not-receiving-emails-how-to-troubleshoot) --- # Domain key and DKIM: what the phrase means Canonical: https://www.palisade.email/learning/domainkeys-vs-dkim > Domain key DKIM means DomainKeys Identified Mail, while legacy DomainKeys is obsolete. Learn how DKIM signatures and selector records work today. The "domain key" in DKIM refers to DomainKeys Identified Mail, the current standard for signing email with a domain-controlled key. It does not mean that legacy DomainKeys and DKIM are interchangeable. [DomainKeys in RFC 4870](https://www.rfc-editor.org/info/rfc4870/) is Historic and obsolete, while [DKIM in RFC 6376](https://www.rfc-editor.org/info/rfc6376/) is the current Internet Standard. Both use DNS below `_domainkey`, but their headers and verification rules differ. ## Quick takeaways - DomainKeys uses the `DomainKey-Signature` header and is Historic. - DKIM uses the `DKIM-Signature` header and is Internet Standard STD 76. - A shared `_domainkey` DNS namespace does not make a DomainKeys key valid for DKIM. - [RFC 8301](https://www.rfc-editor.org/info/rfc8301/) says `rsa-sha1` MUST NOT be used for DKIM signing or verification. - DMARC can use an aligned passing DKIM identifier, but it does not define DomainKeys as an authentication path. - Retire DomainKeys only after checking every active and infrequent production sending route. ## Who is affected? This distinction matters to domain administrators, migration teams, and MSP technicians who find old selectors, legacy DNS records, archived headers, or outdated provider instructions. A new sender should configure DKIM through its current sending platform or signing service. An existing sender should identify the active protocol before removing anything. The shared `_domainkey` label can be misleading. A receiving system determines which protocol applies from the message header, then follows that protocol's own key lookup and signature-verification rules. A DNS record that looks related to DomainKeys cannot replace a DKIM public key solely because both use a selector. Keep the authentication layers separate: - DKIM signs selected message content and identifies a signing domain. - SPF authorizes an SMTP sender identity. - DMARC evaluates whether a passing DKIM or SPF identifier aligns with the visible RFC 5322 `From` domain, as defined by [RFC 9989](https://www.rfc-editor.org/info/rfc9989/). For broader context, see the [email authentication learning center](/learning). A valid DKIM signature alone does not prove DMARC alignment, future delivery, or a receiver's private mailbox decision. ## What does "domain key" mean in DKIM? DKIM expands to DomainKeys Identified Mail. The name reflects the mechanism: a sending system signs selected message content with a private key, and the domain publishes the matching public key in DNS. A receiver uses the signature's `d=` domain and `s=` selector to find that key below `_domainkey` and verify the signature. The phrase can also cause confusion because DomainKeys was the name of an earlier protocol. A header named `DomainKey-Signature` belongs to that legacy protocol. A header named `DKIM-Signature` belongs to DKIM. The shared word and DNS label show the protocols' relationship, but they do not make an old signature or record valid under DKIM. For a DKIM signature with `d=yourdomain.com` and `s=selector1`, the public-key lookup name has this structure: ```text selector1._domainkey.yourdomain.com ``` The selector and key value come from the sending system. Do not invent a selector or copy another domain's public key. ## What are the requirements? ### DomainKeys uses a legacy signature header [RFC 4870](https://www.rfc-editor.org/info/rfc4870/) specifies DomainKeys and its `DomainKey-Signature` header. The RFC Editor marks RFC 4870 Historic and obsolete. RFC 6376 did not directly obsolete RFC 4870. DomainKeys was superseded through earlier DKIM specification work, so the accurate operational description is that DKIM succeeded DomainKeys. The header name is the clearest first sign that an active route still uses the older protocol: ```text DomainKey-Signature: a=rsa-sha1; c=nofws; d=yourdomain.com; s=legacy; b=illustrative-signature-data ``` This is illustrative only. Do not copy a signature header, selector, or key value from another sender. ### DKIM has its own signing and verification model [RFC 6376](https://www.rfc-editor.org/info/rfc6376/) defines DKIM as Internet Standard STD 76. A signer adds `DKIM-Signature` with the signing domain in `d=`, the selector in `s=`, signed header fields in `h=`, a body hash in `bh=`, and the signature in `b=`. The optional `c=` tag specifies canonicalization. ```text DKIM-Signature: v=1; a=rsa-sha256; d=yourdomain.com; s=selector1; h=from:to:subject:date; bh=illustrative-body-hash; b=illustrative-signature-data ``` The verifier combines `s=` and `d=` to find the public key in DNS. A typical structural record shape is: ```text selector1._domainkey.yourdomain.com. IN TXT "v=DKIM1; k=rsa; p=illustrative-public-key" ``` > Do not publish another tenant's selector, public-key value, CNAME target, or provider-generated record. Obtain the live DNS value from the sender that owns the signing configuration. ![Comparison of DomainKeys and DKIM headers, DNS lookup labels, protocol status, and DMARC relationship](/images/editorial/domainkeys-vs-dkim/domainkeys-vs-dkim-protocol-comparison.webp "1200x488") *Source: Palisade.* A public DNS lookup proves that a record can be reached. It does not prove that the production application uses that selector, has the matching private key, or signs delivered mail. ### Current DKIM algorithm requirements replace old guidance [RFC 8301](https://www.rfc-editor.org/info/rfc8301/) updates RFC 6376's cryptographic requirements. It says `rsa-sha1` MUST NOT be used for DKIM signing or verification. It also requires signers to use `rsa-sha256` and verifiers to support it as specified in the RFC. [RFC 8463](https://www.rfc-editor.org/info/rfc8463/) adds `ed25519-sha256` as a DKIM signature method. That protocol update does not establish support in every sending platform. Use the algorithm supported by the platform's current configuration and confirm the algorithm on a delivered message. ### DMARC evaluates aligned DKIM, not DomainKeys [RFC 9989](https://www.rfc-editor.org/info/rfc9989/) defines the DKIM authentication path for DMARC. A message can pass that path when it has a passing DKIM authenticated identifier aligned with the RFC 5322 `From` domain. DomainKeys is not a DMARC pass path. A passing signature and DMARC alignment are separate checks. A third-party platform might produce a valid DKIM signature for its own `d=` domain, but that result can remain unaligned with your visible `From` domain. Inspect both values in the delivered message rather than treating a provider's signing status as proof of DMARC compliance. ## When does the requirement take effect? RFC 4870 was published in May 2007. The [RFC Editor record for RFC 4870](https://www.rfc-editor.org/info/rfc4870/) identifies it as Historic and obsolete. RFC 6376 was published in September 2011 and is Internet Standard STD 76. RFC 8301 updated DKIM cryptographic requirements in January 2018. RFC 8463 added Ed25519 support in September 2018. RFC 9989, the current DMARC specification, was published in May 2026. There is no universal deletion date for DomainKeys records. The retirement date depends on evidence from each sending route, including scheduled jobs and low-volume systems that might not appear in a short test window. ## How do I implement the requirement? ### 1. Collect headers from every sending route Send or collect a complete delivered message from transactional applications, marketing platforms, support systems, appliances, and scheduled jobs. Search the raw headers separately for `DomainKey-Signature` and `DKIM-Signature`. For each message, record the visible `From` domain, the DKIM `d=` domain, selector, sending-system owner, and message type. A provider dashboard can help identify a configuration, but it does not prove that the same production route signed a delivered message. ### 2. Map observed selectors to their DNS records For each `DKIM-Signature`, look up the observed selector under `_domainkey` and identify who controls the DNS record and private key. The [DKIM checker](/tools/dkim) can inspect a public selector record when you already know the selector from a message header. Use the exact selector found in the header. A guessed selector can return a valid record for a different sender. If the DNS lookup itself fails, the [A record vs AAAA record guide](/learning/a-record-vs-aaaa-record-whats-the-difference) can help separate an address-record question from a DKIM TXT-record question. ### 3. Configure current DKIM before retiring DomainKeys Use the sending platform's current DKIM setup process, publish the record it generates, and keep the private key only with the authorized signer. Use a current supported DKIM algorithm. Do not remove the DomainKeys configuration during this step. First capture a message from the same production path that contains `DKIM-Signature` and verifies successfully. Retaining the old route temporarily prevents an untested migration from interrupting mail authentication. ### 4. Check DMARC alignment on the delivered message Review the message's `Authentication-Results` header and compare the passing DKIM domain with the visible `From` domain. Then review DMARC aggregate-report data after traffic accumulates. Aggregate reports can reveal authentication outcomes and sources that a single test message misses. The distinction between spot checks and recurring evidence matters after a migration. A working DNS record today does not identify later DNS drift or a newly introduced sender. The [active vs passive monitoring guide](/learning/active-vs-passive-monitoring-whats-the-difference) explains why evidence collected over time answers a different question than a one-time check. ### 5. Retire DomainKeys only after the evidence window closes Keep an inventory of every sending route and the delivered-message evidence for its DKIM state. Include low-volume routes that may only send monthly, quarterly, or after an operational event. Remove a legacy DomainKeys record or signing configuration only when no current production message uses `DomainKey-Signature` and each active route has a verified DKIM replacement. Preserve a rollback record that identifies the retired selector, DNS owner, sending system, and last verification date. ## How do I validate compliance? Validate the migration at four layers: - DNS: Query the observed selector at the authoritative DNS service and at a public resolver. Confirm the published record matches the sender's generated configuration. - Vendor: Check the sending platform's current DKIM status for the exact domain and route. This confirms its configuration view, not message delivery. - Message: Send a real message through each production route and inspect the complete headers. Confirm `DKIM-Signature` is present and review `Authentication-Results` for DKIM and DMARC results. - DMARC: Review aggregate-report evidence after sufficient traffic has accumulated. Look for sources that still lack aligned DKIM or use an unexpected selector. A DNS result cannot prove that an application signs mail. A delivered-message check cannot prove future sender changes. Aggregate reports provide broader evidence after messages are received, but they do not guarantee an individual receiver's future delivery decision. ## Inspect the DKIM selector, then investigate the ongoing gap Start with the selector visible in a delivered message and use the [DKIM checker](/tools/dkim) to inspect its public DNS record. Compare the result with the signing domain and `Authentication-Results` in that same message before changing a record. A passing public record does not show every production sender that uses the domain or reveal which sources later fail alignment. For an ongoing migration across multiple senders, [Palisade's authentication-issue guidance](https://docs.palisade.email/guides/fixing-authentication-issues/) describes how the DMARC Agent analyzes aggregate-report data and identifies authentication and alignment issues. The agent drafts fixes and proposes policy steps. You approve before anything ships. When a DNS change is approved, [Smart DNS Deployment](/features/dns-deployment) writes the record into your own zone at your own provider. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=existing_content_migration&utm_content=domainkeys-vs-dkim) Palisade does not change the DMARC policy without approval or control a receiver's delivery decision. A public DKIM lookup also cannot prove that private decision. ## Sources and further reading - [RFC 4870: Domain-Based Email Authentication Using Public Keys Advertised in the DNS](https://www.rfc-editor.org/info/rfc4870/) - [RFC 6376: DomainKeys Identified Mail Signatures](https://www.rfc-editor.org/info/rfc6376/) - [RFC 8301: Cryptographic Algorithm and Key Usage Update to DKIM](https://www.rfc-editor.org/info/rfc8301/) - [RFC 8463: A New Cryptographic Signature Method for DKIM](https://www.rfc-editor.org/info/rfc8463/) - [RFC 9989: Domain-based Message Authentication, Reporting, and Conformance](https://www.rfc-editor.org/info/rfc9989/) - [Palisade guide to fixing authentication issues](https://docs.palisade.email/guides/fixing-authentication-issues/) ## Frequently asked questions ### Is DomainKeys the same as DKIM? No. DomainKeys is a Historic and obsolete protocol defined in RFC 4870. DKIM is the current Internet Standard defined in RFC 6376, with later cryptographic updates. ### Can a DomainKeys record work as a DKIM record? No. Both protocols use selector-based DNS names below `_domainkey`, but their record formats and verification rules differ. Configure the DKIM record generated for the specific sender and selector. ### Does a passing DKIM signature mean DMARC passes? No. DMARC requires a passing DKIM authenticated identifier that aligns with the visible `From` domain, unless the message passes through the aligned SPF path instead. ### Should I delete an old DomainKeys record immediately? No. First collect delivered-message evidence from every active and infrequent sending route. Remove DomainKeys only after each route has a verified DKIM replacement and no current message carries `DomainKey-Signature`. ### Must every DKIM sender use Ed25519? No. RFC 8463 adds `ed25519-sha256`, but platform support differs. Use a current supported algorithm and confirm it on a delivered message. --- # SPF hard fail vs softfail: which should you use? Canonical: https://www.palisade.email/learning/spf-hardfail-vs-softfail > SPF hard fail (-all) vs softfail (~all): what each qualifier means, why hard fail breaks forwarded mail, and why ~all plus DMARC is right for sending domains. Use `~all` (softfail) on domains that actively send email, and `-all` (hard fail) only on domains that send no email at all. Hard fail sounds more secure, but once DMARC is enforcing your policy, softfail gives you the same protection against spoofing without bouncing legitimate forwarded mail. Here is how every SPF `all` qualifier compares: | Qualifier | Name | Meaning | Typical receiver behavior | | --- | --- | --- | --- | | `-all` | Hard fail | Unlisted senders are not authorized | May reject the message during delivery | | `~all` | Softfail | Unlisted senders are probably not authorized | Accept but treat as suspicious, often routed to spam | | `?all` | Neutral | No assertion about unlisted senders | Treated much like having no SPF policy | | `+all` | Pass | Every server is authorized | Never use this, it authorizes the entire internet | The rest of this article explains what is behind that verdict: how mail servers actually interpret each qualifier, why forwarding breaks hard fail, and how DMARC changes the calculation entirely. ## Quick takeaways - The `all` mechanism always matches, so it belongs at the end of an SPF record. - `-all` returns `fail` for a client that did not match an earlier mechanism, and receivers may reject it outright. - `~all` returns `softfail`, which receivers may scrutinize but should not reject on that basis alone. - DMARC does not distinguish softfail from fail, so `~all` costs you nothing once DMARC is enforcing. - Forwarding is the reason hard fail loses legitimate mail that softfail keeps. - On a sending domain `~all` is the end state, not a step on the way to `-all`. - A domain that sends no mail should publish `v=spf1 -all` with DMARC `p=reject`. ## What do `~all` and `-all` mean in an SPF record? The `all` mechanism sits at the end of an SPF record and tells receiving servers what to do with mail from senders that are not listed earlier in the record. The qualifier in front of `all` sets the verdict: ```text v=spf1 include:_spf.google.com ~all ``` Mail from anywhere other than Google's servers gets a softfail: probably not authorized, but do not block it outright. ```text v=spf1 include:_spf.google.com -all ``` The same unlisted mail gets a hard fail: not authorized, reject it. Every other part of the record works identically. The only difference is how strongly you tell the world to treat unlisted senders. For a full breakdown of mechanisms and qualifiers, see the [SPF record syntax guide](/learning/spf-record-syntax-explained-mechanisms-qualifiers) and [the terminal `all` mechanism](/learning/spf-all-mechanism). ## How do mail servers treat softfail vs hard fail? SPF produces a signal, and the receiving server decides the outcome. [RFC 7208](https://www.rfc-editor.org/info/rfc7208/) defines the results this way: - **Fail (`-all`)** is an explicit statement that the client is not authorized to use the identity. Receivers are entitled to reject the message outright during the SMTP transaction. - **Softfail (`~all`)** sits between neutral and fail: the domain believes the mail is probably unauthorized but is not certain. The RFC says receiving software SHOULD NOT reject a message based solely on a softfail, but MAY subject it to closer scrutiny than normal, which in practice often means the spam folder. Think of `-all` as a red light and `~all` as a yellow light. One stops the message, the other says proceed with caution. Note what SPF evaluates. SPF checks an SMTP identity, normally the envelope sender, not the address a person sees in their mail client. The [SPF overview](/learning/what-is-spf) covers how that identity is chosen. The visible From domain is protected by [DMARC](/learning/what-is-dmarc) alignment, usually with [DKIM](/learning/what-is-dkim) as the second authentication path. ## What about `?all` and `+all`? `?all` and `+all` are the other two terminal qualifiers SPF defines. Neither belongs on a production sending domain: - **`?all` (neutral)** makes no assertion at all. Unlisted senders are neither authorized nor unauthorized, so receivers treat it roughly like having no SPF policy. Its only legitimate use is short-lived testing while you inventory senders. - **`+all` (pass)** declares that every server on the internet is authorized to send as your domain. It actively helps spoofers and is treated by many filters as a spam signal in its own right. There is no good reason to publish it. If your record ends without any `all` mechanism and has no `redirect`, unmatched senders default to neutral. That is why a complete record should always end with an explicit [`~all` or `-all`](/learning/glossary/spf-all-qualifier). ## Why does forwarding break SPF hard fail? Forwarding breaks SPF hard fail because the forwarding server relays your message from its own IP address, which your SPF record does not list. SPF cannot tell that hop apart from a spoof, so it fails on mail you legitimately sent. Here is the sequence: 1. When a recipient auto-forwards your email, say from a work address to Gmail, the forwarding server becomes the new sending server. 2. That forwarding server is not in your SPF record, so SPF fails. 3. With `-all`, the receiver may reject the forwarded message on the SPF result alone. A legitimate email is lost. 4. With `~all`, the message is accepted with suspicion, which gives DKIM and DMARC the chance to authenticate it properly. This is not hypothetical. Some receivers act on SPF hard fail before DMARC processing ever runs, which means a message can be rejected even though its valid DKIM signature would have passed DMARC. ## Is `~all` less secure than `-all` if you have DMARC? No. With DMARC enforcing your policy, softfail and hard fail provide equivalent protection against spoofing. [RFC 9989](https://www.rfc-editor.org/info/rfc9989/), the current DMARC specification that obsoletes RFC 7489, evaluates SPF as a pass or not a pass, plus alignment with the visible From domain. It does not distinguish a soft failure from a hard one: - If either SPF or DKIM passes and aligns, the message passes DMARC. - If neither does, your DMARC policy, `p=quarantine` or `p=reject`, is applied. So a spoofed message hitting `~all` is still quarantined or rejected by DMARC enforcement, exactly as it would be with `-all`. Meanwhile legitimate forwarded mail keeps its chance to pass through DKIM. The security backbone of modern email authentication is DMARC plus DKIM. SPF is a supporting signal, not the sole gatekeeper. ## What does the industry recommend? The industry recommendation for a domain that sends email is `~all`. The DMARC and deliverability world leans that way and says so in public: - **Google Workspace** recommends softfail outright. Its [SPF documentation](https://knowledge.workspace.google.com/admin/security/about-spf-records) gives `v=spf1 include:_spf.google.com ~all` as the record for a Workspace-only domain, and warns that with a hard fail qualifier "messages that fail the SPF check are more likely to be rejected by the receiving server, and you can't use those messages to troubleshoot your SPF record." - **Al Iverson**, of Spam Resource, [answered the question directly](https://www.spamresource.com/2021/12/ask-al-spf-all-or-all.html). His general answer was `-all`, but he added an update for anyone running DMARC: once your policy is at `p=quarantine` or `p=reject`, "`~all` (tilde all) is probably the better way to go," because SPF failures evaluated ahead of DMARC can cause rejections that never appear in your DMARC reporting at all. - **RFC 7208** is the reason the two results behave differently in the first place, since it tells receivers not to reject on a softfail alone. That middle point is the one operators underrate. A hard fail rejection happens during the SMTP transaction, so the message is gone before DMARC reporting can record it. You lose exactly the evidence you need in order to find the sender you forgot. **The notable dissent is Microsoft.** Its [Microsoft 365 SPF guidance](https://learn.microsoft.com/en-us/defender-office-365/email-authentication-spf-configure) recommends `-all`, on the grounds that "the DMARC policy is effectively ignored for SPF `~all` failures if the messages don't also contain DKIM signatures." Read that condition carefully, because it is the whole argument: it applies to messages carrying no DKIM signature at all. The DMARC specification itself draws no distinction between softfail and fail, so this describes one receiver's behavior rather than the standard. Sign every sending service with DKIM, which you should do regardless, and the objection stops applying to your mail. ## Which should you use: `~all` or `-all`? Whether you should use `~all` or `-all` depends on what the domain does, not on which qualifier sounds stricter. Decide by the domain's job: - **The domain sends email** (your primary domain): use `~all`, enable DKIM on every sending service, and enforce DMARC at `p=quarantine` and then `p=reject`. This blocks spoofing without sacrificing forwarded mail. - **The domain sends no email** (parked domains, web-only domains): publish the bare record `v=spf1 -all` plus DMARC `p=reject`. Nothing legitimate can be lost, and spoofing is shut down completely. - **You are still inventorying senders**: use `~all`, which is where a sending domain settles anyway. What the inventory changes is which senders you authorize, not the qualifier at the end. ![Three cases for choosing an SPF terminal qualifier: softfail on domains that send mail, hard fail on domains that send none, and softfail again while the sender inventory is still open.](/images/editorial/spf-hardfail-vs-softfail/spf-hardfail-vs-softfail-decision-flow.webp "1200x442") *Source: Result semantics follow [RFC 7208](https://www.rfc-editor.org/info/rfc7208/); DMARC evaluation follows [RFC 9989](https://www.rfc-editor.org/info/rfc9989/).* There is no industry migration date from `~all` to `-all`, and no deliverability bonus waiting at the end of one. On a domain that sends mail, `~all` is the end state rather than a stepping stone: the control you tighten over time is the DMARC policy, not the SPF qualifier. If you do change the record for any reason, keep the previous value and its TTL so you can roll back. ## How do you implement `~all` plus DMARC safely? Implementing `~all` plus DMARC safely means publishing softfail first, signing every sender with DKIM, and only then tightening the DMARC policy. Work the six steps in order: 1. **Publish SPF with softfail**, listing every legitimate sending service: ```text v=spf1 include:_spf.google.com include:sendgrid.net ~all ``` This record is illustrative. Publish the mechanisms documented for your own senders, not the example values. 2. **Enable DKIM signing** for every service that sends as your domain. This is what makes softfail safe, and what answers Microsoft's objection above. 3. **Publish a DMARC record starting at `p=none`.** The [DMARC record generator](/tools/dmarc-generator) builds one correctly. 4. **Monitor aggregate reports** until every legitimate source passes with alignment. Aggregate reports take a day or more to arrive. For an immediate read on a single stream, the [email deliverability test](/tools/email-deliverability-test) grades one message you send and shows whether SPF and DKIM aligned. 5. **Move DMARC to `p=quarantine`, then `p=reject`.** This is where the real anti-spoofing enforcement happens. 6. **Keep the record current** as you add new tools, and stay under SPF's limit of 10 DNS-querying terms. ![Evidence checklist for choosing an SPF terminal qualifier without losing a legitimate sender.](/images/editorial/spf-hardfail-vs-softfail/spf-hardfail-vs-softfail-qualifier-checklist.webp "1200x582") *Source: The checklist applies the authorization, processing-limit, and receiver-evidence rules in [RFC 7208](https://www.rfc-editor.org/info/rfc7208/).* You can validate the finished setup at any time with the [SPF checker](/tools/spf). Confirm there is one SPF record, the syntax is valid, `all` is last, and evaluation stays inside the 10-term limit. ## Check the published SPF policy first Run the domain through Palisade's [SPF checker](/tools/spf) before you change the qualifier, then compare its DNS result against the evaluated identity and connecting IP from a delivered message. The checker reads the public record; it cannot reproduce a receiver's private disposition. If repeated sender changes make the inventory hard to maintain, Palisade's [DMARC Agent remediation guide](https://docs.palisade.email/guides/fixing-authentication-issues/) documents how report findings become source-specific SPF, DKIM, and alignment work. [Get started](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=spf_policy&utm_content=spf-hardfail-vs-softfail) when recurring report-based sender monitoring is the remaining need. ## Sources and further reading - [RFC 7208: Sender Policy Framework](https://www.rfc-editor.org/info/rfc7208/) - [RFC 9989: Domain-based Message Authentication, Reporting, and Conformance](https://www.rfc-editor.org/info/rfc9989/) - [Google Workspace: About SPF records](https://knowledge.workspace.google.com/admin/security/about-spf-records) - [Spam Resource: Ask Al, SPF `-all` or `~all`?](https://www.spamresource.com/2021/12/ask-al-spf-all-or-all.html) - [Microsoft 365: Set up SPF](https://learn.microsoft.com/en-us/defender-office-365/email-authentication-spf-configure) - [Palisade guide to fixing authentication issues](https://docs.palisade.email/guides/fixing-authentication-issues/) ## Frequently asked questions ### What is an SPF softfail? An SPF softfail is the `~all` result: the sending server is not listed in the domain's SPF record, so the domain signals that the mail is probably not authorized but stops short of telling receivers to reject it. The message is still delivered, usually with extra scrutiny, which often means the spam folder. That deliver-but-distrust behavior is exactly why softfail pairs well with DMARC, because legitimate forwarded mail keeps flowing while DMARC handles enforcement. ### What does `spf=softfail` in an email header mean? It means the sending server was not listed in the domain's SPF record, and the record ends in `~all`. The receiver accepted the message but flagged it as suspect. If it is your own mail, add the sending service to your SPF record. ### Does `~all` hurt deliverability compared to `-all`? No. Mailbox providers judge your mail on authentication results, domain reputation, and engagement, not on which qualifier your SPF record ends with. Google's own Workspace guidance uses `~all` in its recommended record. ### Can I start with `-all` and loosen it later if problems appear? You can, but it is backwards. The problems show up as silently bounced legitimate mail that you discover only after the damage is done, and hard fail rejections often never reach your DMARC reports at all. Starting with `~all` and tightening enforcement at the DMARC layer reaches the same end state with visibility at every step. ### Do I still need DKIM if my SPF is set up correctly? Yes. SPF alone breaks on forwarding and does not survive mailing lists well, and DMARC needs at least one aligned pass. DKIM signatures travel with the message, which makes them the more resilient half of the pair. Set up both. ### Does `-all` mean DMARC `p=reject`? No. The SPF qualifier describes authorization for an SPF identity. DMARC policy and alignment govern the visible From domain, and the two are set independently. ### Can a non-sending domain publish `v=spf1 -all`? Yes, and it should. That record states that no SMTP client is authorized for the domain. Pair it with DMARC `p=reject` so the visible From domain is protected too. --- # What is ping spoofing and does it matter? Canonical: https://www.palisade.email/learning/what-is-ping-spoofing > Ping spoofing means faking network latency, a PvP game cheat, and separately an ICMP source-address trick. What each is, and which one actually matters. Ping spoofing means deliberately faking your network latency, the "ping" measured between a device and a server. The term has two unrelated meanings depending on who is using it: in online gaming it is a cheat that makes a player look laggy so their hits land while opponents' hits do not, and in networking it describes forging the source IP address of an ICMP echo (ping) packet. Neither has anything to do with the email [spoofing](/learning/what-is-spoofing) that threatens your domain, and confusing the three is the single most common mistake people make when they search the term. ## Quick Takeaways - In gaming, ping spoofing is a client-side cheat that simulates high latency to gain a player-versus-player advantage and evade anti-cheat systems. - In networking, ping spoofing means falsifying the source IP in an ICMP echo request, a form of IP spoofing used in denial-of-service techniques like the Smurf attack. - The two senses share a name only. One is a fair-play problem inside a game; the other is a network-abuse technique. - Ping spoofing is **not** email spoofing. It cannot forge a sender address or defeat [SPF](/learning/what-is-spf), DKIM, or [DMARC](/learning/what-is-dmarc). - For most businesses the networking sense matters little today: modern networks drop obviously forged ICMP, and the classic amplification attacks it enabled are largely mitigated. - If you searched "ping spoofing" worried about your email or domain, the technique you actually want to understand is [email spoofing](/learning/what-is-spoofing) and how DMARC stops it. ## What is ping spoofing in gaming? In online gaming, ping spoofing is a cheat that makes the game server believe a player has a much higher latency than they really do. The cheat software delays the packets the client sends to the server, simulating lag while the player's own connection stays stable and responsive. The effect is asymmetric, and that is the whole point. To everyone else the spoofer appears to teleport, stutter, and rubber-band across the screen, which makes them hard to hit and often cancels the knockback their opponents should receive. The spoofer, meanwhile, sees the game normally. In fast combat games (Minecraft PvP is the community where the term is most used) the result resembles other combat cheats: near-zero knockback and large hit delay, achieved without an aimbot. Because the client is only manipulating the timing of its own packets, ping spoofing is hard to detect. A server cannot easily tell the difference between a player faking lag and a player genuinely on a poor connection, so anti-cheat systems rely on statistical patterns (latency that switches on and off precisely during fights, for example) rather than a single reliable signal. ## What is ping spoofing in networking? In networking, ping spoofing is a specific case of [IP spoofing](/learning/what-is-spoofing) applied to the ICMP protocol that the `ping` command uses. An attacker forges the source IP address of an ICMP echo request so the reply is sent to a different machine, or so the origin of a flood of pings is hidden. This works because ICMP has no authentication. A device that receives an echo request assumes the source address in the packet header is genuine and dutifully sends its echo reply there. That trust is what older attacks abused: - **Smurf attack.** An attacker sends ICMP echo requests to a network's broadcast address with the *victim's* IP forged as the source. Every host on that network replies to the victim at once, amplifying a small request into a flood. Per the [Smurf attack definition](https://en.wikipedia.org/wiki/Smurf_attack), this is why networks are now configured to ignore pings sent to broadcast addresses. - **Ping flood and "ping of death."** Forged source addresses let an attacker bury the origin of a high volume of echo requests, tying up a target's resources as part of a broader denial-of-service effort. ## Does ping spoofing matter? Whether it matters depends entirely on which sense you mean: - **For competitive gaming, yes: as a fairness problem.** Ping spoofing degrades matches and is bannable on most servers. If you run a game community, it is a moderation and anti-cheat concern, not a security breach. - **For business network security, rarely on its own.** The ICMP tricks that made source spoofing dangerous are decades old and largely mitigated. Networks drop directed broadcasts, rate-limit ICMP, and providers deploy source-address validation (BCP 38) that discards packets with obviously forged origins. Spoofed ICMP is still a building block in some volumetric DDoS traffic, but it is not a standalone threat to a typical company's email or domain. - **For your email and brand, no: this is the wrong term.** This is the confusion worth clearing up. Ping spoofing cannot forge the `From:` address a recipient sees, register a lookalike domain, or make a phishing message pass authentication. The attack that does those things is email spoofing, and the control that stops it is [DMARC](/learning/what-is-dmarc) working with SPF and DKIM. ## How is ping spoofing different from email spoofing? They share the word "spoofing", impersonating something, but operate at completely different layers: - **Ping spoofing** manipulates ICMP echo timing or source addresses. It targets a game server's sense of your latency, or a network's willingness to trust a packet header. There is no message and no sender identity involved. - **Email spoofing** forges the sender of an email so a fraudulent message appears to come from a trusted domain. It is the mechanism behind most domain-based [phishing](/learning/what-is-phishing) and business email compromise. Only email spoofing threatens the trust in your domain, and only email authentication addresses it. Publishing SPF and DKIM and [enforcing a `p=reject` DMARC policy](/learning/glossary/dmarc-p-reject) means receiving servers reject mail that forges your domain in the visible `From:` address. Something no amount of ICMP hardening can do. If you are unsure where your domain stands, the [Email Security Score](/tools/email-security-score) checks all three records at once, and Palisade automates the monitoring and enforcement rollout behind them so a forged-sender attack has nowhere to land. ## Frequently asked questions ### Is ping spoofing illegal? Faking your ping in a game is not itself a crime, but it violates the terms of service of virtually every online game and will get an account banned. The networking sense is different: forging packet source addresses as part of a denial-of-service attack is illegal under computer-misuse laws in most jurisdictions. ### Can ping spoofing hack my account or steal data? No. Neither sense of ping spoofing reads or steals data. The gaming cheat only misrepresents latency; the networking technique misdirects ICMP traffic. Account theft and data breaches come from [phishing](/learning/what-is-phishing), credential reuse, and malware, different attacks entirely. ### Does a VPN cause ping spoofing? No. A VPN routes your traffic through another server, which changes your measured ping and your apparent IP address, but it is doing so honestly for every packet, not selectively faking latency to deceive a game server or forging a source address to misdirect replies. Higher ping on a VPN is a routing side effect, not spoofing. ### How do I protect my domain from spoofing? Ping spoofing is not the risk to your domain. Email spoofing is. Publish SPF, DKIM, and a DMARC record, start DMARC at `p=none` to monitor, then move to `p=quarantine` and `p=reject` once every legitimate sender authenticates. See [how to set up DMARC](/dmarc-setup) for the safe rollout. ## Related reading - [What is spoofing?](/learning/what-is-spoofing) - [What is pharming and how do you prevent it?](/learning/what-is-pharming-and-how-do-you-prevent-it) - How do DDoS and DoS attacks differ, and how do you defend against them? --- # What format do DMARC aggregate reports use? Canonical: https://www.palisade.email/learning/dmarc-aggregate-report-format > DMARC aggregate reports use RFC 9990 XML data, commonly delivered as .xml.gz files. Learn the report fields, validation, and safe ingestion. DMARC aggregate reports use the XML format defined by [RFC 9990](https://www.rfc-editor.org/rfc/rfc9990.html). Receivers commonly package the XML as a compressed `.xml.gz` file for delivery to the reporting address published in a DMARC `rua` tag. One report groups messages with matching evaluation results over a date range, so it is useful evidence about sending sources and authentication outcomes, but it is not the same as a delivered message's full headers. ## Quick takeaways - RFC 9990 defines the XML structure for DMARC aggregate reports. - Aggregate report files commonly arrive as XML compressed with gzip, often using a `.xml.gz` filename. - `report_metadata` identifies the reporting organization, report ID, and covered time range. - `policy_published` records the DMARC policy the receiver evaluated for the domain. - Each `record` groups message counts and DMARC evaluation results for a source and identifier combination. - Aggregate data helps identify trends and sources, but it does not prove delivery, inbox placement, or a receiver's private decision for one message. ## Who is affected? Domain owners that publish a DMARC record with an aggregate reporting destination are affected, along with the teams or MSPs that receive and process those reports. The reporting destination is specified with the `rua` tag in the domain's DMARC record. [RFC 9990's aggregate-reporting specification](https://www.rfc-editor.org/rfc/rfc9990.html) defines the report format and report-generation framework. A domain can publish DMARC without requesting aggregate reports. A receiver can also have its own reporting practices, so a `rua` destination is not a promise that every receiver will send a report on the same schedule or with identical grouping. Aggregate reports concern DMARC evaluation. The policy and identifier-alignment rules that produce those results are defined in [RFC 9989](https://www.rfc-editor.org/rfc/rfc9989.html), the current DMARC specification. RFC 9991 is separate: it covers DMARC failure reporting, not aggregate XML reports. If you need to decide where reports should be sent, see [what a DMARC RUA tag is](/learning/what-is-a-rua). This page focuses on what arrives at that destination and how to interpret its structure safely. ## What are the requirements? ### The report uses RFC 9990 XML RFC 9990 defines an XML schema with a top-level `feedback` element. Inside it, the major sections are `report_metadata`, `policy_published`, and one or more `record` elements. ```text feedback ├── report_metadata ├── policy_published └── record ├── row ├── identifiers └── auth_results ``` The XML is machine-readable, which allows a report processor to extract fields consistently. It is not designed as a human-readable incident record. A parser should preserve the original file and validate the document before treating its contents as operational evidence. ![DMARC aggregate report anatomy showing RFC 9990 XML sections for metadata, published policy, grouped records, identifiers, and authentication results](/images/editorial/dmarc-aggregate-report-format/dmarc-aggregate-report-format-report-anatomy.webp "1200x600") *Source: Palisade.* ### Report metadata identifies the sender and reporting period The `report_metadata` element contains information about the organization that generated the report, a report identifier, and the report's date range. RFC 9990 represents the beginning and end of that range as Unix epoch timestamps. ```xml <!-- Illustrative only. Do not publish production report IDs or reporting addresses. --> <report_metadata> <org_name>receiver.example</org_name> <email>dmarc-reports@receiver.example</email> <report_id>example-report-20260813-001</report_id> <date_range> <begin>1786579200</begin> <end>1786665600</end> </date_range> </report_metadata> ``` The date range tells you when the receiver grouped the observed mail. It does not tell you when every message was delivered, rejected, deferred, or placed in a mailbox. Use the range when comparing reports, but do not assume separate receivers use the same reporting window. ### Published policy records the evaluated DMARC policy The `policy_published` element records the DMARC policy information the receiver used for the evaluated domain, including the domain and applicable alignment and disposition settings. This is useful context because it distinguishes a report generated while the domain published `p=none` from one generated while a stricter policy was published. ```xml <!-- Illustrative only. Use the domain's actual published record for a policy decision. --> <policy_published> <domain>yourdomain.com</domain> <adkim>r</adkim> <aspf>r</aspf> <p>none</p> <sp>none</sp> <pct>100</pct> </policy_published> ``` The published-policy block is historical report context. Before changing a DMARC policy, check the current DNS record and compare it with recent aggregate evidence. The [DMARC learning hub](/learning/dmarc) covers the broader protocol and policy rollout process. ![DMARC aggregate report processing workflow from compressed attachment through validation, deduplication, and sender investigation](/images/editorial/dmarc-aggregate-report-format/dmarc-aggregate-report-format-report-processing-workflow.webp "1200x676") *Source: Palisade.* ### Each record is grouped evidence, not a message copy A `record` contains a `row`, `identifiers`, and `auth_results`. The `row` includes the source IP address, the number of messages represented by the grouping, and the receiver's DMARC policy evaluation. The `identifiers` section includes identifiers such as the visible `header_from` domain. The `auth_results` section reports the receiver's observed DKIM and SPF results. ```xml <!-- Illustrative only. This is sample data, not a receiver interface or a production report. --> <record> <row> <source_ip>192.0.2.10</source_ip> <count>42</count> <policy_evaluated> <disposition>none</disposition> <dkim>pass</dkim> <spf>pass</spf> </policy_evaluated> </row> <identifiers> <header_from>yourdomain.com</header_from> </identifiers> <auth_results> <dkim> <domain>mail.yourdomain.com</domain> <result>pass</result> </dkim> <spf> <domain>mail.yourdomain.com</domain> <result>pass</result> </spf> </auth_results> </record> ``` A count of 42 means the receiver grouped 42 messages under the reported conditions. It does not expose 42 individual message headers. For a single-message investigation, collect the raw headers from the delivered or rejected message and inspect its `Authentication-Results` fields. Aggregate reporting is evidence about patterns, while a message header is evidence about one delivery path. ## When does the requirement take effect? RFC 9990 was published in May 2026 as an IETF Standards Track RFC. It is the current aggregate-reporting specification and replaces the aggregate reporting material previously carried in RFC 7489. [RFC 9990's RFC Editor record](https://www.rfc-editor.org/rfc/rfc9990.html) lists its publication status and obsoleted documents. RFC 9989, published at the same time, is the current core DMARC specification. Its policy-evaluation rules explain the `policy_evaluated`, SPF, DKIM, and identifier-alignment information that appears in an aggregate report. There is no universal receiver enforcement date for aggregate reporting: report generation and delivery remain receiver behavior within the RFC's framework. ## How do I implement the requirement? ### 1. Publish a DMARC record with an aggregate destination Publish a DMARC TXT record at `_dmarc.yourdomain.com` and add a `rua` URI that your organization controls. ```text ; Illustrative only. Replace the address with a reporting mailbox or processor you control. _dmarc.yourdomain.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com" ``` The domain that receives reports needs to be able to accept attachments and retain them safely. If the reporting destination uses a different organizational domain, RFC 9990's external-report authorization rules apply. ### 2. Accept compressed report attachments safely Treat `.xml.gz` as transport packaging, not as a different report format. Store the original attachment, decompress it in a controlled process, and enforce file-size and expansion limits before parsing. Do not execute anything embedded in an attachment. Configure XML parsing to reject external entity resolution and unexpected document types. An aggregate report is data from a remote reporting organization, so it should enter the same controlled ingestion path as other untrusted files. ### 3. Validate the XML shape before extracting fields Validate that the document follows the RFC 9990 aggregate-report structure before mapping values into tickets, dashboards, or automation. Reject malformed documents and record why they failed validation without exposing full report contents in routine logs. Keep parsing separate from policy action. A DMARC result in one record can identify a source that needs investigation, but it does not by itself require a DMARC policy change. ### 4. Deduplicate before aggregating results Use the reporting organization, report ID, policy domain, and date range as part of a deduplication key. A recipient mailbox may receive a duplicate attachment through forwarding, retry, or an ingestion error. Keep the raw report and the normalized record set associated with that key. If a corrected report arrives, preserve enough provenance to determine whether it replaces or supplements prior data rather than silently double-counting message volume. ### 5. Compare grouped results with the actual sending path Investigate sources that fail DMARC, show an unexpected identifier, or appear at meaningful volume. Then verify the sender configuration and inspect a real message from that same production path. For SPF and DKIM investigations, use the current DNS configuration and message evidence together. A valid DNS record does not prove that an application used the expected return path or selector for a given message. ## How do I validate compliance? Validate aggregate-report processing at four layers. - DNS: query the domain's DMARC record through the authoritative DNS path and a public resolver. Confirm that the `rua` destination matches the intended reporting workflow. - Report transport: confirm that the reporting mailbox or processor receives the attachment and retains the original compressed file. - XML: decompress the file safely, validate the RFC 9990 structure, and confirm that metadata, policy, records, identifiers, and authentication results can be extracted without duplicates. - Message and DMARC evidence: compare a reported source with a real message from that production source, then use successive aggregate reports to determine whether the same pattern persists. If you have a report attachment to inspect, the [DMARC report analyzer](/tools/dmarc-report-analyzer) can help you examine its contents. A report analyzer cannot prove that every message was delivered, show a receiver's private filtering decision, or determine that a policy change is required. > Do not raise a DMARC policy solely because one XML record parses successfully. Review legitimate and unauthorized sending sources across enough report data to understand the operational risk. ## Turn aggregate XML into prioritized sender work A valid XML report can show that a source exists and how a receiver grouped its DMARC results. It does not inventory every future sender, repair SPF or DKIM configuration, or decide when your domain should move to a stricter DMARC policy. [Palisade's DMARC Agent](https://docs.palisade.email/guides/fixing-authentication-issues/) analyzes aggregate-report data, identifies sending sources and authentication or alignment issues, and creates prioritized remediation tickets for human review. It does not decide the policy change or apply it automatically. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=email_authentication&utm_content=dmarc-aggregate-report-format) Signup and the trial do not require a credit card. Palisade does not autonomously change your DMARC policy, guarantee delivery, or prove a receiver's decision for any individual message. ## Sources and further reading - [RFC 9990: DMARC Aggregate Reporting](https://www.rfc-editor.org/rfc/rfc9990.html) - [RFC 9989: Domain-based Message Authentication, Reporting, and Conformance](https://www.rfc-editor.org/rfc/rfc9989.html) - [RFC 9991: DMARC Failure Reporting](https://www.rfc-editor.org/rfc/rfc9991.html) - [Palisade guide to fixing DMARC authentication issues](https://docs.palisade.email/guides/fixing-authentication-issues/) ## Frequently asked questions ### Are DMARC aggregate reports XML files? Yes. RFC 9990 defines DMARC aggregate reports as XML documents. They are often delivered as compressed `.xml.gz` attachments, but gzip is packaging around the XML report. ### Does one aggregate report row represent one email? No. A `record` includes a `count` that represents multiple messages grouped by the receiver's reported evaluation conditions. It is not a copy of an individual message or its complete headers. ### Does a DMARC aggregate report prove inbox placement? No. Aggregate reports provide grouped DMARC evaluation evidence. They do not prove inbox placement, delivery for every message, or a receiver's private spam and filtering decisions. ### Can I use the published policy in a report to change DMARC enforcement? Only as historical context. The `policy_published` section shows the policy evaluated for that report. Check the current DNS record, real production message headers, and recurring aggregate evidence before proposing a policy change. ### Is RFC 9991 the format for DMARC aggregate reports? No. RFC 9991 defines DMARC failure reporting. RFC 9990 defines the XML format and framework for DMARC aggregate reports. --- # What does no MX record found mean in a bounce? Canonical: https://www.palisade.email/learning/no-mx-record-found-bounce > No MX record found in a bounce can mean no usable mail route, a null MX, DNS failure, or a bad address. Diagnose the DNS result and retest safely. A `no MX record found` bounce means the sending system did not find a usable SMTP route for the recipient domain. It does not always mean the domain has no mail service. SMTP can fall back to the domain's A or AAAA address when no MX record exists, while NXDOMAIN, a DNS failure, a null MX, or an unusable fallback route can all stop delivery. Start by preserving the bounce and checking the recipient domain's DNS result. ## Quick takeaways - `no MX record found` is a sender-side routing symptom, not a complete DNS diagnosis. - A domain with no MX record can still receive mail through SMTP's implicit MX fallback. - `NXDOMAIN`, no-data answers, temporary DNS failures, and null MX records require different actions. - A null MX explicitly says that a domain does not accept email. - Public DNS checks cannot prove a mailbox exists, that a recipient owns a domain, or why a provider rejected one message. - Retest through the same sending system after the DNS or recipient-address issue is resolved. ## What does the failure mean? The bounce text is evidence that the sending system could not establish a usable destination route. It is not the authoritative DNS response by itself. Preserve the full bounce, including any enhanced status code, timestamp, and recipient address, before changing anything. ```text no MX record found ``` [RFC 5321 section 5.1 defines SMTP destination lookup](https://www.rfc-editor.org/rfc/rfc5321.html#section-5.1). If a domain has no MX records, an SMTP sender can treat the domain itself as an implicit MX with preference `0`, then look up an A or AAAA address for that domain. That fallback only works when the address is reachable and the host accepts SMTP. A true no-data MX response therefore does not prove that a domain cannot receive email. It can indicate that the domain relies on its own address record for inbound mail. It also cannot prove that a specific inbox exists, that the recipient controls the address, or that the sending domain has a reputation problem. Other DNS outcomes look similar in some sender logs but have different meanings: - `NXDOMAIN` means the queried domain name does not exist. - `NOERROR` with no MX answer means the domain exists but has no published MX record. - A timeout or `SERVFAIL` means DNS resolution did not complete and may be temporary. - A null MX is a deliberate declaration that the domain accepts no email. [RFC 7505 defines a null MX](https://www.rfc-editor.org/rfc/rfc7505.html): one MX record with preference `0` and exchange `.`. A sender that recognizes the record must not attempt delivery to that domain. This is recipient-routing evidence. It is separate from sender authentication. SPF, DKIM, and DMARC can affect how a receiver evaluates a message, but they do not create an inbound SMTP route for the recipient domain. If a DKIM lookup also fails elsewhere in your environment, see [why a DKIM checker says no record found](/learning/no-dkim-record-found). ![Decision flow showing how a no MX record found bounce can lead to an implicit MX check, a null MX result, a DNS error, or an invalid recipient domain](/images/editorial/no-mx-record-found-bounce/no-mx-record-found-bounce-dns-routing-flow.webp "1200x829") *Source: Palisade.* ## What usually causes it? ### The recipient domain does not exist A malformed address, expired domain, failed delegation, or typing error can return `NXDOMAIN`. SMTP cannot route mail to a domain name that DNS says does not exist. This is a recipient-address or domain-ownership issue, not a sender-authentication failure. Do not create or alter DNS records for a domain your organization does not control. Confirm the recipient address with the recipient through a trusted channel. ### The domain has no MX and no usable implicit route When MX records are absent, RFC 5321 allows the domain's A or AAAA record to act as the destination. The sender can still fail if the domain has no usable address record, the address is unreachable, or the target does not accept SMTP on port 25. This is an inference from the route lookup and SMTP result. A public MX query alone cannot show how the sender's production resolver or outbound system handled the fallback. ### The domain publishes a null MX A null MX uses the following shape: ```text yourdomain.com. IN MX 0 . ``` The record tells SMTP senders that the domain does not accept mail. It is common for domains that are used for websites or other non-mail purposes. Do not remove a null MX unless the domain owner intends to accept inbound email and has an inbound mail service ready. ### DNS resolution failed temporarily A timeout, unreachable authoritative server, or `SERVFAIL` can prevent a sender from discovering valid mail routes. [RFC 5321 requires SMTP clients to handle temporary DNS errors differently from permanent name errors](https://www.rfc-editor.org/rfc/rfc5321.html#section-5.1). The sender may retry, depending on its queue policy. Treat this as a resolution incident until you compare the sender's result with authoritative and public-resolver answers. Publishing a new MX record is not a safe response until you know the zone's intended configuration. ### A resolver still has a negative DNS answer cached After a domain or MX record is corrected, a recursive resolver can retain an earlier NXDOMAIN or no-data answer. [RFC 2308 defines DNS negative caching](https://www.rfc-editor.org/rfc/rfc2308.html). Compare timestamps and TTLs before assuming the correction failed. ## How do I diagnose the failure? ### 1. Preserve the bounce from the original sending path Capture the recipient domain exactly as submitted to the sending system. Save the full SMTP bounce text, status code if present, sending-system name, send time, and message identifier. Do not rely on a screenshot or a shortened application notification. The original delivery log or non-delivery report may distinguish a DNS error from a permanent recipient-domain error. ### 2. Build a DNS and bounce evidence packet Use one packet for the incident so the DNS result, sender evidence, and retest are tied to the same recipient domain. ```text Recipient domain: recipientdomain.com MX query: MX recipientdomain.com Resolver and query time: resolver.example, 2026-08-12T12:00:00Z Returned response: NOERROR, no MX answer A/AAAA fallback result: A recipientdomain.com = 192.0.2.25 SMTP bounce text/code: no MX record found Sending system: outbound-mail-system Retest time: pending ``` Redact recipient local parts, message content, internal hostnames, and customer data before sharing this packet outside the incident team. Keep the complete original in the access-controlled incident record. ![DNS evidence packet showing the recipient domain, MX response, fallback address, bounce text, and retest status](/images/editorial/no-mx-record-found-bounce/no-mx-record-found-bounce-evidence-packet.webp "1200x726") *Source: Palisade.* ### 3. Check the recipient domain's MX answer Use Palisade's [MX records checker](/tools/mx) to inspect the public MX result for the exact recipient domain. Record whether the result is an MX record, no-data answer, null MX, or an error. A public MX lookup checks a current public DNS view. It does not prove that the recipient mailbox exists, that the destination server will accept your message, or that the production sender used the same resolver. ### 4. Test the implicit MX branch when there is no MX answer If DNS returns `NOERROR` with no MX records, query A and AAAA records for the recipient domain itself. RFC 5321 permits that domain-address fallback. For an address record returned by the domain, test only from an approved network and only against the public SMTP endpoint. Record whether the target returns an SMTP greeting. Do not attempt authentication, mailbox probing, or repeated delivery attempts. > A website address is not proof of a working implicit MX route. A host can answer HTTP while SMTP is unavailable or intentionally blocked. ### 5. Compare authoritative, public, and sender-side evidence Query the authoritative DNS servers for the zone, then compare the answer with a public resolver and the sender's own resolver or delivery logs. Different answers can point to delegation errors, stale negative caching, split DNS, or a resolver outage. If the recipient is managed by a provider, use that provider's documented status or administrator console as the vendor layer of evidence. A provider-controlled mailbox may have rules or routing states that public DNS cannot expose. ## How do I fix it? ### Correct a malformed recipient address or nonexistent domain When the evidence packet shows `NXDOMAIN`, confirm the address with the intended recipient. Correct the domain only after the recipient confirms it, then resend through the original sending system. Do not guess at similarly named domains. A guessed replacement can disclose message content to the wrong organization. ### Repair the intended inbound DNS route for a domain you control If your organization owns the recipient domain and it should receive mail, publish valid MX records whose exchange hostnames resolve to working SMTP servers. If the domain intentionally relies on implicit MX, restore its usable A or AAAA address and SMTP listener instead. The required record values come from the inbound mail provider. Do not copy illustrative values or another organization's MX targets. ### Wait and retest after a temporary DNS problem If the sender recorded a timeout or `SERVFAIL`, check authoritative DNS health and resolver status. Avoid unrelated record changes while the failure remains temporary. Retest after the affected resolver can return a complete answer. If a prior negative result was cached, wait for the applicable TTL to expire before treating the production retry as evidence of a failed repair. ### Use the recipient provider's process for provider-controlled mail When the recipient domain, mailbox service, or routing is controlled by another organization, provide the redacted evidence packet to that organization's administrator or provider support channel. They can verify mailbox state, routing policy, and tenant-specific configuration. Do not promise that a DNS correction will cause delivery. The recipient provider can still reject or defer a message for reasons that public DNS does not reveal. ## How do I validate the repair? First validate DNS. Check the authoritative answer and at least one public resolver. For a no-MX domain using the implicit route, confirm the A or AAAA answer and the approved SMTP test result. For explicit MX, confirm that each intended exchange hostname resolves. Then validate the vendor layer where it applies. Confirm the recipient's mail provider or administrator reports the intended inbound configuration as active. A green provider status does not replace a same-path message test. Send a controlled message through the same application, outbound service, sender domain, and recipient domain that produced the bounce. Preserve the resulting SMTP response and delivered message headers. A successful delivery to a valid test mailbox is message-layer evidence, while the old bounce alone is not. Finally, keep this incident separate from DMARC remediation. Palisade's [DMARC Agent domain overview](https://docs.palisade.email/page-breakdowns/domain-overview/) explains how Palisade analyzes DMARC aggregate-report data, identifies sending sources and authentication or alignment issues, and creates prioritized remediation tickets. DMARC reports do not diagnose or repair a recipient's MX route. ## Track sender-authentication work after the bounce is resolved After you have corrected the recipient address or confirmed the recipient DNS route, use Palisade to investigate the separate ongoing question: which production sending sources still have SPF, DKIM, or DMARC alignment issues? Palisade is agentic DMARC software that analyzes DMARC aggregate-report data and proposes the next policy step for human review. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=existing_content_migration&utm_content=no-mx-record-found-bounce) Palisade does not control another organization's recipient DNS, mailbox state, SMTP acceptance decision, or this individual bounce. ## Sources and further reading - [RFC 5321 section 5.1: SMTP destination lookup and implicit MX](https://www.rfc-editor.org/rfc/rfc5321.html#section-5.1) - [RFC 7505: A "Null MX" no-service resource record](https://www.rfc-editor.org/rfc/rfc7505.html) - [RFC 2308: DNS negative caching](https://www.rfc-editor.org/rfc/rfc2308.html) - [Palisade MX records checker](/tools/mx) - [Palisade DMARC Agent domain overview](https://docs.palisade.email/page-breakdowns/domain-overview/) ## Frequently asked questions ### Can email work without an MX record? Yes. SMTP can use the recipient domain's A or AAAA record as an implicit MX when the MX query returns no records. The address must lead to a host that accepts SMTP. ### Does no MX record found mean the recipient inbox does not exist? No. The phrase does not prove whether an individual inbox exists. It only indicates that the sending system did not obtain a usable route from the evidence it recorded. ### Is a null MX the same as a missing MX record? No. A null MX is an explicit DNS record with preference `0` and exchange `.` that says the domain does not accept email. A missing MX record can still allow implicit MX fallback. ### Should I add an MX record to another company's domain? No. Only the domain owner or its authorized administrator should change recipient DNS. Send the redacted DNS and bounce evidence packet to the recipient's approved contact or provider support process. ### Can SPF, DKIM, or DMARC fix a no MX record found bounce? No. SPF, DKIM, and DMARC evaluate sender authentication. They do not create an SMTP route for the recipient domain. See the [email deliverability learning hub](/email-deliverability) for related delivery diagnostics. --- # What does SMTP 550 permanent failure mean? Canonical: https://www.palisade.email/learning/smtp-550-permanent-failure > SMTP 550 permanent failure means a receiving server rejected an SMTP action. Use the enhanced code, response text, and command stage to diagnose it. SMTP `550` permanent failure means the receiving server rejected the requested SMTP action and considers that exact request unsuccessful until its underlying condition changes. It is a reply class, not one universal diagnosis. Preserve the complete reply, enhanced status code, SMTP command stage, and recipient context before deciding whether to correct an address, repair authentication, or escalate a receiver-specific policy decision. ## Quick takeaways - SMTP `550` is a permanent negative completion reply for the request as sent. - The enhanced status code, such as `5.1.1` or `5.7.1`, narrows the type of failure. - A `550` response after `RCPT TO` has different likely causes than one after `DATA`. - A bare `550` does not prove an invalid address, spam classification, blocklist listing, or DMARC failure. - Retry only after changing the condition identified by the response and recipient context. - SMTP acceptance after a repair does not guarantee inbox placement. ## What does the failure mean? [RFC 5321 defines `5xx` replies as permanent negative completion replies](https://www.rfc-editor.org/rfc/rfc5321.html#section-4.2.1). For `550`, the server did not perform the requested action. The sending system should not keep retrying the unchanged transaction as though it were a temporary connection failure. The reply becomes useful when paired with the enhanced status code and the command that received it. [RFC 3463 defines enhanced status codes as a class, subject, and detail](https://www.rfc-editor.org/rfc/rfc3463.html). The subject can identify addressing, mailbox, mail-system, routing, protocol, content, or security and policy concerns. [The IANA enhanced-status-code registry model](https://www.rfc-editor.org/rfc/rfc5248.html) permits additional registered details, so retain the complete response rather than reducing it to `550`. ```text 550 5.1.1 <redacted-recipient@example.com>: <receiver-supplied response text> ``` This illustrative redacted response fragment shows the evidence shape to save. It does not state a universal receiver message. `550 5.1.1` can establish that the responding server returned a permanent failure in the addressing subject area. Without the full text, the SMTP stage, and recipient-domain context, it cannot establish whether a mailbox was deleted, an alias changed, a recipient system rejected the address, or the message reached the intended recipient organization. ![Flow showing an SMTP client preserving the full 550 response, identifying the command stage and enhanced code, then selecting an evidence-based repair branch](/images/editorial/smtp-550-permanent-failure/smtp-550-permanent-failure-evidence-flow.webp "1200x980") *Source: Palisade.* ![Diagnostic branches for SMTP 550 failures based on the enhanced status code, command stage, recipient context, and sender authentication evidence](/images/editorial/smtp-550-permanent-failure/smtp-550-permanent-failure-diagnostic-branches.webp "1200x829") *Source: Palisade.* ## What usually causes it? ### The recipient address or recipient domain is wrong A reply with an addressing subject, including `5.1.1`, can point to a destination mailbox that does not exist. The exact response and recipient organization's records determine the next action. An address can also fail after an alias removal, domain migration, or recipient-side provisioning change. Confirm the recipient through an authoritative business source before suppressing it. Do not treat an address-shaped error as proof that every address at the domain is invalid. ### The receiving server will not relay or accept the route A server can reject mail when it is not responsible for the destination or when a relay path lacks the required authorization. The SMTP command stage matters. A failure at `RCPT TO` may concern recipient acceptance or relay permission, while a failure earlier at `MAIL FROM` may concern the submitted sender or relay policy. Check that the sending service connected to the intended recipient route. A separate [SMTP connection refused troubleshooting guide](/learning/smtp-connection-refused) covers a connection failure, which occurs before an SMTP `550` reply can be returned. ### The receiver applied sender authentication or policy rules A `5.7.x` enhanced code can indicate a security or policy subject under RFC 3463. It does not, by itself, identify SPF, DKIM, DMARC, IP reputation, content, or a private provider rule. Treat a connection between the response text and a particular policy as an inference unless the responding provider documents that exact mapping. When the receiver's response names authentication, inspect a real message from the same production path. Its trusted authentication results and the sender service's status are stronger evidence than a public DNS lookup alone. ### The policy applies only to that recipient or recipient group Some rejections depend on recipient tenancy, recipient configuration, consent state, or a receiver decision that is not published. The sender may deliver successfully to other recipients while one destination rejects the same message. A recipient-specific result does not prove a domain-wide sender defect. Ask the recipient organization for its remediation path when the response or provider documentation directs you there. ### The provider-owned sending IP needs provider action If a hosted email service or ESP owns the sending IP and the response points to that IP, do not attempt an IP change yourself. Collect the queue ID, timestamp, response, recipient domain, and sending path, then open a support case with the provider that controls the IP. A public reputation check can provide context, but it cannot expose a receiver's private reputation decision or prove the cause of this one `550` response. ## How do I diagnose the failure? ### 1. Capture the SMTP evidence packet Start with the non-delivery report, sending-service event, or MTA log for the exact failed delivery. Save the evidence before retrying or changing configuration. Use this labelled packet in the incident record: ```text Complete SMTP response: 550 <enhanced-code> <full receiver text> Message or queue ID: <redacted-id> Timestamp and timezone: <YYYY-MM-DDThh:mm:ssZ> Recipient domain and scope: <domain and affected recipient or group> SMTP command stage: <MAIL FROM | RCPT TO | DATA> Remote hostname: <receiving host> Sending IP or service: <provider-owned IP or sending service> Authenticated identifiers: <From domain, envelope sender, DKIM d= domain> Sender application: <application or workflow name> Controlled retest outcome: <same path, changed condition, resulting SMTP reply> ``` Redact local parts, customer identifiers, tokens, and message content before sharing the packet outside the team. Keep access-controlled originals where they are needed for provider support. ### 2. Identify the command stage and enhanced status code Record whether the server rejected `MAIL FROM`, `RCPT TO`, or the message after `DATA`. Then retain all three parts of the enhanced code. The first part identifies success or failure class, the second identifies the subject, and the final part adds detail under [RFC 3463's enhanced status-code structure](https://www.rfc-editor.org/rfc/rfc3463.html). Do not convert every `5.1.x` result into "bad address" or every `5.7.x` result into "spam." The remote server's complete response is the evidence that narrows the branch. ### 3. Confirm the recipient domain route For a recipient-domain or routing concern, inspect the current public MX records before changing the sender. Use the [MX records checker](/tools/mx) to look up the recipient domain's published mail exchangers, then compare the result with the remote hostname recorded in the SMTP evidence packet. A public MX lookup cannot prove the receiver accepted the recipient, expose private routing controls, or show the production delivery path used by a particular sending provider. ### 4. Inspect the same-path authentication evidence When the response names authentication or security policy, send a controlled test through the same application, provider, sender identity, and recipient domain. Preserve the delivered message headers if it is accepted elsewhere. Compare trusted `Authentication-Results` with the visible From domain, envelope sender, and DKIM signing domain. Do not use a passing DNS record as proof that the application signed the message or used that authenticated path. The [SMTP 550 5.1.1 guide](/learning/smtp-error-codes/550-5-1-1) is the narrower next reference when the response specifically identifies a nonexistent recipient account. ### 5. Separate a sender-wide issue from a recipient-specific decision Test one approved control recipient at the same destination domain if the recipient organization permits it. Also test a known-good destination outside that organization. Keep message content and sending path stable unless the response directs a specific change. This comparison is evidence, not a workaround. A pass to another provider does not overrule the original receiver's policy. A failure at only one recipient can support escalation to that recipient organization or the sending provider. ## How do I fix it? ### Correct or suppress a confirmed bad recipient Correct a typo, restore a documented alias, or suppress a recipient that the owning organization confirms is no longer valid. Update the source application or CRM so the address is not reintroduced on later sends. > Do not repeatedly retry an unchanged `550 5.1.1` response. Repeated attempts can create unnecessary traffic and do not repair a recipient that the receiver will not accept. This repair changes recipient data. It does not change DNS, authentication, or DMARC enforcement. ### Repair the confirmed sender authentication condition If the receiver's response and same-path message evidence point to SPF, DKIM, or DMARC, repair the named condition at the sending service and DNS layer. Confirm the vendor's authentication status, then send a new message through the same production route. Keep the repair narrow. Do not loosen a DMARC `p=` policy as a substitute for correcting a sender's authentication or alignment problem. A DMARC policy change affects requested enforcement and reporting. It does not make a failed sender authenticate. ### Escalate recipient-specific policy with the evidence packet When the rejection applies to one recipient domain or group and no published remediation exists, provide the recipient organization's mail administrator with the redacted evidence packet. Ask which sender identity, recipient rule, or documented condition triggered the rejection. The sender cannot inspect private receiver rules or override the receiver's decision. Do not alter message content, routing, or identities blindly to search for an acceptance path. ### Open a case with the sending provider for a provider-owned IP When a provider owns the sending IP, send it the complete SMTP response, queue ID, timestamp, recipient domain, authenticated identifiers, and controlled retest outcome. Ask the provider to inspect the exact outbound transaction. The provider owns any IP-level remediation. Changing public DNS records does not repair a private receiver decision about a provider-managed sending IP. ## How do I validate the repair? Repeat the same sending path after the underlying condition changes: the same sender application, authenticated identity, provider, recipient domain, and representative message type. Record the SMTP response at the stage that previously failed. A `250` response at that stage shows that the receiving server accepted responsibility for the message in that transaction. Validate across the applicable layers: - Check DNS through the authoritative source and a public resolver when the repair changed MX, SPF, DKIM, or DMARC records. - Confirm the sending vendor's current authentication or domain-verification state when its configuration changed. - Inspect a real delivered message from the same production path and preserve its trusted authentication results. - Review DMARC aggregate-report data after it accumulates when the failure involved a domain's authentication posture. For a public review of the sender domain's exposed configuration, run the [Email Security Score](/tools/email-security-score). That check cannot identify the exact receiver policy, monitor the production route continuously, or guarantee future delivery. ## Track the authentication gaps behind repeated policy failures If repeated `550` responses point to SPF, DKIM, or DMARC issues across domains or sending sources, Palisade's [DMARC Agent domain overview](https://docs.palisade.email/page-breakdowns/domain-overview/) explains how it analyzes DMARC aggregate-report data, identifies sources and authentication or alignment issues, and creates prioritized remediation tickets. It can propose the next DMARC policy stage when evidence supports it, while your team reviews the evidence and applies the change. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=smtp_550_permanent_failure&utm_content=smtp-550-permanent-failure) Palisade does not control a receiving server's private rejection decision, repair an individual recipient address, or guarantee that a future message will be accepted or placed in the inbox. ## Sources and further reading - [RFC 5321 section 4.2.1: SMTP reply codes](https://www.rfc-editor.org/rfc/rfc5321.html#section-4.2.1) - [RFC 3463: Enhanced mail system status codes](https://www.rfc-editor.org/rfc/rfc3463.html) - [RFC 5248: IANA registration procedures for enhanced status codes](https://www.rfc-editor.org/rfc/rfc5248.html) - [Palisade DMARC Agent domain overview](https://docs.palisade.email/page-breakdowns/domain-overview/) - [Palisade MX records checker](/tools/mx) ## Frequently asked questions ### Is every SMTP 550 failure a bad email address? No. SMTP `550` can cover recipient addressing, relay, mailbox, routing, content, or security-policy failures. Use the complete response, enhanced status code, and SMTP command stage to identify the supported branch. ### Should a sender retry SMTP 550? No, not without changing the underlying condition. SMTP `550` is permanent for the request as sent. Correct the address, configuration, route, or documented policy condition before a controlled retest. ### What is the difference between SMTP 450 and 550? SMTP `450` is a transient negative completion reply, while `550` is a permanent negative completion reply for the request as sent. A transient failure may be retried later. A `550` response needs evidence-based correction before retrying. ### Does SMTP 550 prove the message was spam? No. A `550` response alone does not establish a spam classification or blocklist listing. Only the complete provider response and applicable provider evidence can narrow a policy decision. ### Can an MX lookup fix an SMTP 550 response? No. An MX lookup can help verify a recipient domain's public mail route when routing is relevant. It cannot prove why a receiver rejected a specific recipient, message, or sender identity. ### Can a hosted email provider fix a 550 tied to its sending IP? Only the provider that controls the sending IP can investigate or change its outbound IP configuration. Give that provider the exact SMTP response, queue ID, timestamp, recipient scope, and same-path retest result. --- # What does the DMARC adkim tag do? Canonical: https://www.palisade.email/learning/dmarc-adkim-tag > DMARC adkim sets DKIM alignment to relaxed or strict. Learn how each mode compares domains, affects senders, and how to validate a safe change. The DMARC `adkim` tag tells a receiving system how a passing DKIM signature's `d=` domain must align with the visible RFC 5322 `From:` domain. `adkim=r` uses relaxed alignment and is the default. `adkim=s` uses strict alignment and requires an exact domain match. The setting affects domains that rely on DKIM to achieve a DMARC pass. This page focuses on changing `adkim` safely: identify affected senders, preserve the current record, validate the new mode with delivered messages and aggregate reports, and roll back if a legitimate path loses its aligned pass. For the broad `aspf` versus `adkim` comparison, use the [DMARC alignment guide](/resources-post/dmarc-and-subdomains-aspf-adkim-and-sp-tags-explained). For `p`, `sp`, `np`, and inherited subdomain policy, use the [DMARC policy inheritance guide](/learning/dmarc-policy-for-subdomains). ## Quick takeaways - `adkim` is an optional DMARC record tag that selects the DKIM identifier alignment mode. - When `adkim` is absent, RFC 9989 defaults it to relaxed alignment, `r`. - Relaxed alignment accepts domains with the same Organizational Domain. - Strict alignment, `s`, requires the passing DKIM `d=` domain to exactly match the visible From domain. - The `adkim` tag does not make a DKIM signature pass and does not set SPF alignment behavior. - A public DNS check confirms the published tag, while delivered-message headers and DMARC reports show whether production senders align. ## Safe-change decision at a glance | Evidence before the change | What `adkim=s` would do | Safe next action | |---|---|---| | Passing DKIM `d=` exactly matches the visible From domain | DKIM can remain aligned | Validate a fresh production message and confirm the same identity in aggregate reports | | Passing DKIM `d=` is a subdomain of the visible From domain | A relaxed-only DKIM path loses alignment | Reconfigure the signer, retain `adkim=r`, or verify a separate aligned SPF path before changing | | DKIM fails or no signature passes | `adkim` cannot make DKIM pass | Repair DKIM first; do not use an alignment-mode change as the fix | | Sender identity is unknown | Impact cannot be established from DNS | Inventory the source and inspect delivered-message headers before publication | Before editing DNS, save the complete current DMARC TXT value, its owner name, TTL, lookup time, and change owner. A rollback means restoring that known-good complete record—not publishing a second DMARC record. ## Who is affected? [RFC 9989, the current DMARC specification](https://www.rfc-editor.org/rfc/rfc9989.html#section-4.7), defines `adkim` as the DKIM identifier alignment mode in a DMARC record. The rule applies when a receiver evaluates whether a passing DKIM signature can satisfy DMARC for the domain in the visible RFC 5322 `From:` field. The tag does not apply to a DKIM signature by itself. DKIM must first pass validation. DMARC then compares the authenticated DKIM identifier with the RFC 5322 From Author Domain under the selected alignment mode. The relevant identifiers are: - The From domain is the domain in the visible `From:` address. - The DKIM authenticated identifier is the `d=` domain in a passing DKIM signature. - The Organizational Domain is the domain boundary RFC 9989 uses for relaxed alignment. For example, `From: alerts@yourdomain.com` and a passing DKIM signature with `d=mail.yourdomain.com` share an Organizational Domain. They can align under relaxed mode. They do not align under strict mode because the two domains are different. This can affect any legitimate production sender, including transactional platforms, support systems, marketing tools, billing mail, monitoring alerts, and MSP-managed client domains. Review each sending path separately. A domain's published DKIM records do not show which signer an application actually uses. For broader DMARC terminology and policy behavior, see the [Palisade DMARC learning hub](/learning/dmarc). ## What are the requirements? ### The DMARC record may select relaxed or strict DKIM alignment [RFC 9989 defines `adkim` as an optional tag](https://www.rfc-editor.org/rfc/rfc9989.html#section-4.7). Its valid values are `r` for relaxed DKIM identifier alignment and `s` for strict DKIM identifier alignment. If the tag is omitted, the default is `r`. ```text v=DMARC1; p=none; adkim=r v=DMARC1; p=none; adkim=s ``` These are illustrative only. Publish one DMARC TXT record for the domain and retain the policy and reporting values your organization has approved. ![DMARC adkim comparison showing relaxed Organizational Domain matching and strict exact domain matching](/images/editorial/dmarc-adkim-tag/dmarc-adkim-alignment.webp "1200x442") *Source: Palisade.* The `adkim` setting changes only the domain relationship DMARC accepts after DKIM passes. It does not select a DKIM key, change a selector, repair an invalid signature, or alter the message content covered by DKIM. ### Relaxed alignment compares Organizational Domains [RFC 9989 defines relaxed DKIM alignment](https://www.rfc-editor.org/rfc/rfc9989.html#section-4.4.1) as a match when the DKIM authenticated identifier and RFC 5322 From Author Domain have the same Organizational Domain. ```text From: alerts@yourdomain.com DKIM-Signature: d=mail.yourdomain.com; s=selector1; ... ``` With `adkim=r`, the example can align after the DKIM signature passes because `mail.yourdomain.com` and `yourdomain.com` share the same Organizational Domain. The selector name does not establish DMARC alignment. Relaxed alignment permits a legitimate sender to use a DKIM subdomain while presenting a parent domain in `From:`. It does not allow an unrelated third-party domain to align merely because the message appears to come from your domain. ### Strict alignment requires an exact domain match [RFC 9989 defines strict DKIM alignment](https://www.rfc-editor.org/rfc/rfc9989.html#section-4.4.1) as an exact match between the DKIM authenticated identifier and the RFC 5322 From Author Domain. Using the same message example, `adkim=s` does not align `d=mail.yourdomain.com` with `From: alerts@yourdomain.com`. For strict DKIM alignment, the sender needs a passing `d=yourdomain.com` signature, or the visible From domain needs to match the signing domain exactly. Strict alignment can express a narrower domain-identity rule. It can also remove the DKIM-based DMARC pass for a legitimate sender that previously depended on relaxed alignment. ### DMARC may still pass through aligned SPF The `adkim` tag controls DKIM alignment only. DMARC can pass when either DKIM or SPF passes and aligns with the visible From domain under the applicable alignment rule. A message that loses aligned DKIM after an `adkim=s` change may still have aligned SPF. Do not assume that every message signed with a subdomain will fail DMARC after a strict-DKIM change. Inspect the full authentication result for the exact delivered message, including its SPF result and authenticated domain. The [DMARC `fo` tag]( /learning/dmarc-fo-tag) controls failure-reporting options, not DKIM alignment. ## Does RFC 9989 require strict DKIM alignment? RFC 9989 was published in May 2026 as a Proposed Standard and obsoletes RFC 7489. It is the current core DMARC specification, and it defines the `adkim` tag and the two DKIM alignment modes. The `adkim` tag remains optional. RFC 9989 does not require domain owners to publish `adkim=s`, and it does not set a rollout date for strict alignment. A mailbox provider can make local filtering or delivery decisions beyond DMARC's published protocol rules. A public DNS lookup cannot prove a receiver's private decision or future inbox placement. ## How do I change `adkim` safely? ### 1. Collect the visible From and passing DKIM identities For each production source, send a message through its normal path to a mailbox where you can inspect the raw headers. Record the visible From domain, every passing DKIM `d=` value, the SPF result, and the DMARC result. Include mail from every application that uses the domain. For MSP work, maintain this evidence per customer domain and sender rather than applying one shared alignment decision. ### 2. Identify relaxed-only DKIM paths Compare the visible From domain with each passing DKIM `d=` domain. A sender relies on relaxed DKIM alignment when both domains share an Organizational Domain but are not an exact match. For example, `d=mail.yourdomain.com` with `From: alerts@yourdomain.com` is a relaxed-only match. A DNS inventory cannot prove this relationship because it does not expose the signer used on a delivered production message. ### 3. Confirm another aligned path before tightening alignment Use `adkim=s` only after evidence shows every sender that needs DKIM-based DMARC pass has an exact-match DKIM identity, or another verified aligned authentication path. A platform that relies on a subdomain may offer a custom DKIM domain, a configurable visible From domain, or an aligned SPF return path. Verify the platform's real production headers before changing the DMARC record. > Changing to `adkim=s` before testing every production sender can cause legitimate mail to fail DMARC. Start with delivered-message evidence and aggregate-report data. ### 4. Publish one complete DMARC record Add the chosen `adkim` value to the existing DMARC record at `_dmarc.yourdomain.com`. Do not publish a second DMARC record. ```text _dmarc.yourdomain.com TXT "v=DMARC1; p=none; adkim=s; rua=mailto:dmarc@yourdomain.com" ``` This is illustrative only. Use your approved reporting address and current policy values. Review the whole record before publication because an invalid or duplicate record can affect DMARC policy discovery. The [DMARC `np` tag](/learning/dmarc-np-tag) has a separate purpose. It controls policy treatment for non-existent subdomains and does not change DKIM alignment. ### 5. Define the rollback trigger before publication Record the exact condition that will cause a rollback. A practical trigger is evidence that an authorized production sender lost its DKIM-aligned DMARC pass after the change and does not have another verified aligned authentication path. Keep the previous complete DMARC value in the change record. If the trigger occurs, restore that value at the same `_dmarc` owner name. Do not add a second TXT record and do not change `p`, `sp`, reporting addresses, or unrelated tags during the rollback. DNS caches can retain the strict value until its TTL expires, so continue testing through the same sender and receiver path while the restored value propagates. If the previous record omitted `adkim`, restoring it also restores the RFC default of relaxed alignment. Confirm that result with authoritative DNS and a public resolver rather than assuming that the control panel's saved state is already visible to Mail Receivers. ## How do I validate the change? Validate a change at four layers. First, confirm DNS. Use the [DMARC checker](/tools/dmarc) to inspect the public DMARC record and verify that one valid record publishes the intended `adkim` mode. Check the authoritative DNS server and at least one public resolver when you control the DNS change. Second, confirm the sender's own authentication status where its interface provides it. A green vendor status is useful evidence, but it does not prove that the exact production message used the expected DKIM identity. Third, inspect a delivered message from each production path. Confirm that DKIM passes, identify the signature's `d=` domain, compare it with the visible From domain, and check the receiver's DMARC result. This is the evidence that shows whether the sender aligns under the mode you published. Finally, review DMARC aggregate reports after data accumulates. Look for legitimate sources that now show DKIM alignment failures or a changed DMARC disposition. Aggregate data helps identify sources that a test-message inventory missed. Compare the post-change evidence with the baseline captured before publication. If an expected sender changes from aligned DKIM to unaligned DKIM, determine whether aligned SPF still produces the DMARC pass. If neither path aligns, use the predefined rollback rather than changing several authentication controls at once. A passing public record check does not prove that every production source signs with the configured domain, that a receiver will make a particular filtering decision, or that future messages will authenticate. ## Inspect the published DMARC alignment mode Check the public record before changing `adkim`, then compare it with delivered-message headers from the senders that rely on DKIM. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=email_authentication&utm_content=dmarc-adkim-tag) Palisade autonomously analyzes DMARC aggregate-report data, identifies sending sources and authentication or alignment issues, and creates prioritized remediation tickets. It can propose the next policy step when the evidence supports it, while a human reviews the evidence and applies the DNS change. A DMARC record check cannot prove the DKIM identity used by every production application or control a receiver's private delivery decision. ## Sources and further reading - [RFC 9989: DMARC record tags, including adkim](https://www.rfc-editor.org/rfc/rfc9989.html#section-4.7) - [RFC 9989: DKIM identifier alignment rules](https://www.rfc-editor.org/rfc/rfc9989.html#section-4.4.1) - [RFC 9989: Domain-based Message Authentication, Reporting, and Conformance](https://www.rfc-editor.org/rfc/rfc9989.html) - [RFC 8601: Authentication-Results header field](https://www.rfc-editor.org/rfc/rfc8601.html) ## Frequently asked questions ### What is the default value of the DMARC adkim tag? Relaxed alignment, `adkim=r`, is the default when the `adkim` tag is absent from a DMARC record. ### Does adkim=s require the DKIM selector to match the From domain? No. Strict alignment compares the passing DKIM signature's `d=` domain with the visible From domain. The DKIM selector in `s=` is not the domain alignment value. ### Can a message pass DMARC if DKIM fails strict alignment? Yes. A message may still pass DMARC through aligned SPF. Inspect the delivered message's SPF, DKIM, and DMARC results rather than relying on the DKIM result alone. ### Should every domain use strict DKIM alignment? No. RFC 9989 permits both relaxed and strict alignment. Use strict alignment only after production evidence shows that legitimate senders have an exact-match DKIM identity or another verified aligned authentication path. ### Does a DMARC checker prove that all senders align with adkim? No. A DMARC checker can inspect the published record. It cannot prove the DKIM `d=` domain used by every production sender or a receiver's private filtering decision. --- # What does the DMARC fo tag mean? Canonical: https://www.palisade.email/learning/dmarc-fo-tag > The fo tag controls when receivers send failure reports, and does nothing without ruf. What each value asks for, and why large receivers often ignore it. The DMARC `fo` tag requests the conditions under which a receiver may send a message-specific failure report to a destination named by `ruf`. It does not change the DMARC policy or force any receiver to send reports. Under [RFC 9989 section 4.7](https://www.rfc-editor.org/rfc/rfc9989.html#section-4.7), `fo=0` is the default request, while `fo=1`, `fo=d`, and `fo=s` request broader or mechanism-specific failure conditions. ## Quick takeaways - The DMARC `fo` tag applies only to failure reports requested through `ruf`, not aggregate reports sent through `rua`. - If a DMARC record has no `ruf` tag, RFC 9989 says the `fo` tag's content "MUST be ignored." - `fo=0` requests a report when all evaluated authentication mechanisms fail to produce an aligned pass. - `fo=1` requests a report when any evaluated authentication mechanism fails to produce an aligned pass. - `fo=d` and `fo=s` request DKIM-specific and SPF-specific failure reports under the conditions defined by RFC 9989. - A receiver can choose whether to honor a failure-report request. ## Who is affected? The `fo` tag matters to domain owners that publish a DMARC record with `ruf` and want message-specific failure reports. It does not affect a domain that only receives aggregate DMARC reports through `rua`. [RFC 9989's DMARC reporting model](https://www.rfc-editor.org/rfc/rfc9989.html#section-3.2) distinguishes aggregate feedback about groups of messages from failure reports tied to individual messages. Failure reports may contain message-specific information, so access, retention, and incident handling need more care than an aggregate-report mailbox. The tag also does not determine mail handling. The DMARC `p`, [`sp`](/learning/glossary/dmarc-sp), and `np` tags request policy treatment for messages that fail DMARC. For the subdomain policy distinction, see [what the DMARC `np` tag means](/learning/glossary/dmarc-np). For broader context, start with the [DMARC learning hub](/learning/dmarc). ## What are the requirements? RFC 9989, "Domain-based Message Authentication, Reporting, and Conformance (DMARC)," is the controlling published RFC. It is a final RFC, not a draft. The `fo` option is optional, and it is a request to a report generator rather than a receiver enforcement rule. ### The `fo` tag requires `ruf` A domain owner must include `ruf` for `fo` to have an effect. RFC 9989 states that the `fo` tag's content "MUST be ignored" when `ruf` is absent. ```text v=DMARC1; p=none; rua=mailto:dmarc-aggregate@yourdomain.com; ruf=mailto:dmarc-failures@yourdomain.com; fo=0 ``` This is illustrative only. Use reporting addresses controlled by your organization. Do not copy example addresses into a production DMARC record. The `ruf` tag provides one or more destinations for failure reports. The `fo` tag tells a report generator which failure condition the domain owner is requesting. Neither tag changes whether the message passes DMARC, and neither changes the policy requested by `p`, which in the example above is [`p=none`](/learning/glossary/dmarc-p-none). ### `fo=0` requests complete aligned-authentication failure When `fo` is absent, its default value is `0`. Under RFC 9989, `fo=0` requests a failure report when all underlying authentication mechanisms fail to produce an aligned pass. An SPF or DKIM check can pass without satisfying DMARC alignment. The relevant test is whether an evaluated mechanism produces an aligned pass for the RFC 5322 From domain. A receiver can still decline to send a failure report. ![DMARC fo tag values and the failure-report conditions they request](/images/editorial/dmarc-fo-tag/dmarc-fo-tag-decision-rules.webp "1200x980") *Source: Palisade.* ### `fo=1` requests any aligned-authentication failure RFC 9989 defines `fo=1` as a request for a failure report if any underlying authentication mechanism fails to produce an aligned pass. ```text v=DMARC1; p=none; ruf=mailto:dmarc-failures@yourdomain.com; fo=1 ``` This request can produce more potential report events than `fo=0`, because one mechanism can meet the requested condition even if another mechanism produces an aligned pass. More requested reports do not prove stronger authentication, and they do not require a mailbox provider to send message-level data. ### `fo=d` and `fo=s` request mechanism-specific reports RFC 9989 defines `fo=d` as a request for a DKIM failure report when the message had a signature that failed evaluation, regardless of alignment. It defines `fo=s` as a request for an SPF failure report when SPF evaluation fails, regardless of alignment. Multiple `fo` values use colon separation. ```text v=DMARC1; p=none; ruf=mailto:dmarc-failures@yourdomain.com; fo=0:d ``` This is illustrative only. The values request different report conditions. They do not modify the SPF record, repair a DKIM signature, or alter DMARC disposition. The separate [DMARC `rf` tag](/learning/glossary/dmarc-rf) controls the requested failure-report format. ### Receivers retain discretion The `fo` value is a request. RFC 9989 permits report generators to decide whether to honor the requested conditions. Privacy, abuse prevention, and local operating policy can affect whether a receiver generates or sends failure reports. A missing failure report therefore does not prove that the DMARC record is invalid, that no message failed, or that a receiver ignored `fo`. Use aggregate reporting and delivered-message authentication results to investigate production sending behavior. ## When does the requirement take effect? RFC 9989 was published in May 2026 and is the current DMARC specification. It obsoleted [RFC 7489](https://www.rfc-editor.org/rfc/rfc7489.html), which had previously defined DMARC reporting behavior. There is no mailbox-provider enforcement date for `fo` in RFC 9989. A receiver can evaluate the option after it obtains a valid DMARC record containing `ruf`, but the RFC leaves failure-report generation to the receiver's local policy. Treat `fo` as an optional diagnostic request, not as a compliance deadline or a guaranteed reporting channel. ## How do I implement the requirement? ### 1. Decide whether failure reports answer a defined question Start with the operational question that aggregate reports cannot answer. Message-specific failure reports may help investigate a narrow authentication incident, but they are not a replacement for aggregate DMARC data. If your team does not have a controlled process for receiving and reviewing message-level data, do not add `ruf` and `fo` only because the tags are available. The [DMARC `ri` tag](/learning/glossary/dmarc-ri) concerns the requested aggregate-report interval, which is a separate reporting function. ### 2. Set up a controlled `ruf` destination Use a mailbox or report processor with restricted access and a retention process appropriate for message-specific data. If `ruf` uses a reporting domain different from the policy domain, follow the external reporting authorization rules in RFC 9989 before expecting reports. > Failure reports can contain information about an individual message. Do not send them to a broadly shared mailbox or an unmanaged third-party address. ### 3. Choose the narrowest useful request Leave `fo` absent when the default `fo=0` request is sufficient, or publish `fo=0` when you need the value to be explicit. Use `fo=1`, `fo=d`, or `fo=s` for a specific investigation with a defined review process. Do not treat a broader report request as proof of authentication. The tag cannot correct an SPF authorization failure, restore a broken DKIM signature, or create DMARC alignment. ### 4. Publish one valid DMARC record Publish one DMARC TXT record at `_dmarc.yourdomain.com`. Include `ruf` and `fo` in the same record as the DMARC version and policy. ```text _dmarc.yourdomain.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-aggregate@yourdomain.com; ruf=mailto:dmarc-failures@yourdomain.com; fo=0" ``` This DNS record is illustrative only. Query the authoritative DNS server and at least one public resolver after publication. Keep a change record so an operator can distinguish intended changes from DNS drift. ## How do I validate compliance? First, inspect the public record. Confirm that one valid DMARC record is published at `_dmarc.yourdomain.com`, that `ruf` is present, and that each `fo` value is one of the values defined by RFC 9989. A public lookup is DNS evidence only. It does not prove that a receiver will send failure reports. Next, check the receiving system or report destination for accepted and processed reports. If you use an external destination, verify the required authorization record and the destination's handling controls. Then test the exact production sending path. Send a controlled message and inspect its delivered headers to establish SPF, DKIM, alignment, and DMARC results. A green DNS result cannot prove that the application signed the message or used the expected return path. Finally, use DMARC aggregate reports after data accumulates to identify sending sources and alignment outcomes. Failure reports are supplemental evidence because receivers may suppress them. ## Check the DMARC record before relying on `fo` Use the [DMARC record checker](/tools/dmarc) to inspect the published `ruf` and `fo` values before changing a reporting request. Compare the DNS result with delivered-message headers and aggregate-report evidence. [Check the DMARC record](/tools/dmarc) A public DNS check cannot prove that a receiver will send a failure report, show every production sender, or explain a receiver's private reporting decision. For ongoing work, Palisade is DMARC software that analyzes aggregate-report data, identifies sending sources and authentication or alignment issues, and creates prioritized remediation tickets. It can propose a next policy step when evidence supports it, while a human reviews the evidence and applies the change. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=email_authentication&utm_content=dmarc-fo-tag) ## Sources and further reading - [RFC 9989 section 4.7: DMARC failure reporting options](https://www.rfc-editor.org/rfc/rfc9989.html#section-4.7) - [RFC 9989 section 3.2: DMARC reporting](https://www.rfc-editor.org/rfc/rfc9989.html#section-3.2) - [RFC 9989: Domain-based Message Authentication, Reporting, and Conformance](https://www.rfc-editor.org/rfc/rfc9989.html) ## Frequently asked questions ### What does `fo=0` mean in DMARC? `fo=0` requests a failure report when all underlying authentication mechanisms fail to produce an aligned pass. It is the default request when the DMARC record has no `fo` tag. ### Does the DMARC `fo` tag change enforcement? No. The `fo` tag only requests conditions for failure reporting. The DMARC policy tags, such as `p`, request how a receiver handles messages that fail DMARC. ### Does `fo` work without `ruf`? No. RFC 9989 says the `fo` tag's content "MUST be ignored" when the record does not contain `ruf`. ### Does `fo=d` mean DKIM must align? No. `fo=d` requests a DKIM failure report when a message signature fails evaluation, regardless of alignment. DMARC pass still depends on an aligned SPF or DKIM pass. ### Will every receiver send a DMARC failure report? No. RFC 9989 allows report generators to choose whether to honor a failure-report request. A receiver can suppress reports under its local policy. --- # Why does Outlook show an unverified sender warning? Canonical: https://www.palisade.email/learning/outlook-unverified-sender-warning > Outlook flags a sender as unverified when it cannot authenticate the From domain with SPF, DKIM, or DMARC. Find the failing path and fix it. Outlook can show an unverified sender warning when it cannot confirm the visible From address through the authentication evidence it evaluates, or when the authenticated identity differs from the displayed sender. Microsoft treats the indicator as a caution signal, not proof that a message is malicious. The repair is usually in the application, relay, or DNS configuration that sent the affected message, rather than in an Outlook setting. If the notice instead says ["Caution: This email originated from outside of the organization"](/learning/caution-email-originated-outside-organization), it is an external-origin label rather than an unverified-sender result. ## Quick takeaways - An Outlook unverified sender warning means Outlook could not confirm the displayed sender identity from the evidence it evaluated. - A legitimate message can show the warning when its SPF or DKIM identity does not align with the visible From domain. - A passing SPF or DKIM result alone does not prove that DMARC passes for the visible From address. - The affected message's raw headers identify the sending path that needs investigation. - A public DNS lookup can inspect a published record, but cannot prove Microsoft's private sender decision or future inbox placement. - Validate a repair with a new message sent through the same production application, relay, and gateway. ## What should I check before configuring Outlook? First identify the path that produced the warning. Mailbox-hosted Microsoft 365 mail, a marketing platform, a ticketing system, an invoice application, and a transactional sender can all use the same visible From domain while using different envelope senders, DKIM signatures, and relays. Preserve the original message source from the affected delivery before changing DNS or sender settings. A screenshot of the warning is useful context, but it does not show enough evidence to identify the sender-side change. Confirm who controls each part of that path: - The administrator for the sending application or SMTP relay. - The administrator for the domain's authoritative DNS zone. - The Microsoft 365 administrator when Microsoft-hosted mail is involved. - The owner of any security gateway that rewrites links, adds footers, or re-signs messages. > Copy DNS values from the account and domain you are configuring. Do not publish selectors, targets, tokens, or hostnames from another account or from an online example. Microsoft's [guidance on phishing and suspicious behavior in Outlook](https://support.microsoft.com/en-US/Outlook/mail/phishing-and-suspicious-behavior-in-outlook) documents the sender indicator. It does not document one tenant setting that removes the warning for every third-party sender. The correct change depends on the service that submitted, relayed, or signed the message. ## Which setup method should I use? Use the sender configuration that matches the failing production route. If only one application produces the warning, investigate that application's domain-authentication settings. Do not alter unrelated Microsoft 365 mailbox mail that already authenticates correctly. If the application offers custom return-path or DKIM-domain settings, generate records in that account for the domain being configured. Those values are account-specific. A dedicated IP address does not authenticate the visible From identity. It may affect infrastructure or reputation decisions, but it does not replace SPF authorization, DKIM signing, or DMARC alignment. ![Outlook notice indicating that a message did not pass sender authentication](/images/editorial/outlook-unverified-sender-warning/outlook-unauthenticated-sender-docs.jpg "552x126") *Source: [Phishing and suspicious behavior in Outlook](https://support.microsoft.com/en-us/Outlook/mail/phishing-and-suspicious-behavior-in-outlook), checked 2026-07-18.* If a security gateway changes headers or body content after a service signs the message, establish which permitted system signs last. A later modification can break DKIM. The correction may belong in the gateway configuration or in the final sender's signing workflow. For broader vendor-specific setup paths, use Palisade's [vendor email authentication guides](/learning/esp-setup). ## How do I configure SPF and DKIM for Outlook sending? ### 1. Open the settings for the system that sent the affected message Identify the application from the delivered message's routing and header evidence. Open that application's sending-domain or authentication settings, rather than an unrelated Outlook mailbox setting. For Microsoft-hosted mailbox mail, use the tenant's documented Microsoft 365 administration workflow. For a third-party sender, use that provider's domain-authentication workflow. Outlook's warning is recipient-side evidence. It does not identify the console that owns the repair. ### 2. Record the identities from the affected message Select the visible From domain that appears on the warning, then collect the following evidence from the original message: - **Visible From domain:** the domain after `@` in the RFC 5322 From address shown to the recipient. - **Return-Path or sender address:** the envelope-sender identity, when the receiver exposes it. - **Authentication-Results:** SPF, DKIM, and DMARC outcomes added by a trusted receiving system. - **DKIM `d=` domain:** the signing domain in `DKIM-Signature`. - **Producing system:** the Microsoft 365 tenant, application, SMTP relay, or other sender that generated the message. [RFC 8601 defines the `Authentication-Results` header field and explains that its results are meaningful only when the receiving system is trusted](https://www.rfc-editor.org/rfc/rfc8601.html). Treat copied results from an unknown relay with caution. **Illustrative redacted header fragment:** ```text Authentication-Results: mx.receiver.example; spf=pass smtp.mailfrom=mailer.example; dkim=pass header.d=mailer.example header.s=selector1; dmarc=fail header.from=yourdomain.com ``` This example shows why an unverified-sender indicator can appear even when SPF or DKIM passes. The example's SPF and DKIM domains are `mailer.example`, while the visible From domain is `yourdomain.com`. A pass for an unrelated identifier does not establish DMARC alignment. The indicator plus a passing result also does not prove that the message is malicious, that Outlook made its decision solely from DMARC, or that one DNS change will remove the warning. ### 3. Publish the generated DNS records Publish only SPF or DKIM records generated by the service and account that sends the affected message. SPF is a TXT policy for the envelope-sender domain. DKIM is commonly a TXT record below `_domainkey`, although some senders use CNAME delegation. **SPF record type:** `TXT` **Host, illustrative only:** ```text yourdomain.com ``` **Value, illustrative only:** ```text v=spf1 include:sender.example -all ``` **DKIM record type:** `TXT` **Host, illustrative only:** ```text selector1._domainkey.yourdomain.com ``` **Value, illustrative only:** ```text v=DKIM1; k=rsa; p=ZmFrZS1leGFtcGxlLWtleS1ub3QtYS1yZWFsLWRraW0ta2V5 ``` > Do not publish these examples. Copy the exact host and complete value generated by the sending service for the account and domain you are configuring. A domain has one SPF policy record. Merge a required sender mechanism into the existing policy after confirming the sender requires it, rather than publishing a second SPF TXT record. Do not overwrite an active DKIM selector unless the sender documents a rotation procedure. Many DNS interfaces append the zone name to a host field. If the zone is `yourdomain.com`, entering `selector1._domainkey.yourdomain.com` can create a duplicated owner name. Confirm the final fully qualified owner before saving. ### 4. Verify the configuration in the sending service Return to the sender's authentication page and wait for its verification status. This confirms what that sender can evaluate for the selected configuration. A green vendor indicator does not prove that the affected application used the configured route for the message that Outlook marked. ### 5. Send a new message through the same route Send a new message from the same application, tenant, relay, and gateway that triggered the warning. Deliver it to a mailbox where you can inspect complete source. Do not validate with a message sent before the DNS change, an internal test that bypasses the production relay, or a different application. Those paths can use different return-path domains, selectors, signatures, and transformations. ## How does this setup affect DMARC? DMARC evaluates the visible From domain against SPF and DKIM identifiers. [RFC 9989 defines DMARC alignment between the RFC 5322 From domain and the authenticated SPF or DKIM domain](https://www.rfc-editor.org/rfc/rfc9989.html). SPF helps only when the passing envelope-sender domain aligns with the visible From domain. DKIM helps only when the passing `d=` signing domain aligns with it. Use Palisade's [DMARC checker](/tools/dmarc) to inspect the published policy for the visible From domain. The checker accepts a public domain and can show the current DNS record. It cannot inspect the affected message, determine why Outlook marked it, or prove that the production sender uses the expected authenticated identities. ![Example DMARC alignment evidence for a visible From domain, SPF domain, and DKIM signing domain](/images/editorial/outlook-unverified-sender-warning/outlook-unverified-sender-warning-alignment.webp "1200x533") *Source: Palisade.* ## How do I validate the setup? ### Check public DNS Query the exact SPF policy or DKIM selector generated for the sender. Compare the authoritative answer with at least one public resolver. For an independent record check, use Palisade's [DNS lookup tool](/tools/dns-lookup). ```bash dig +short TXT selector1._domainkey.yourdomain.com dig +short TXT yourdomain.com ``` Confirm the final owner name and complete record value. Public DNS does not prove the sender is signing mail, using the expected return path, or receiving a private Microsoft determination. ### Check the sender status Confirm the selected sender account reports the domain or records as verified. Record the selected domain, account, and verification time. This is vendor-layer evidence only. ### Inspect a delivered message Open the original source of a newly delivered test message. Compare the visible From domain, Return-Path when present, `DKIM-Signature` `d=` and `s=` values, and trusted `Authentication-Results` with the evidence collected before the change. Accept the repair only when the production path now produces the expected authentication evidence and an SPF or DKIM pass aligns with the visible From domain where DMARC relies on that mechanism. ### Review DMARC reports After aggregate reports accumulate, check whether the sending source passes SPF or DKIM and aligns with the visible From domain. Separate the repaired source from every other sender using that domain. DMARC reports show reported traffic over time, but they do not guarantee that Outlook will never show an indicator. ## Troubleshooting ### SPF passes but Outlook still shows the warning Compare `smtp.mailfrom` in the trusted `Authentication-Results` with the visible From domain. A pass for a provider-owned return-path domain may not align with the From domain. Configure a supported custom return path or use aligned DKIM, if the sending service supports it. ### DKIM passes but DMARC fails Compare `header.d=` with the visible From domain. A valid DKIM signature for a provider domain can pass DKIM while failing DMARC alignment. Configure the sender's authenticated domain or signing-domain option for the visible From domain. ### The sender reports verified, but the delivered message differs Inspect the message's relay path and selector. The application may be bypassing the configured sender profile, or a downstream gateway may be changing the message after signing. Test the same production route and determine which system signs after permitted modifications. ### The DKIM record does not resolve Check for a duplicated DNS suffix, a truncated TXT value, or a mismatch between the selector in the message and the selector published in DNS. Verify the fully qualified owner against the sender's generated instructions before changing the record. ### A new SPF record broke another sender Restore the prior known-good SPF policy, then merge the required mechanism into the single existing record. Publishing multiple SPF policy records for the same domain creates an ambiguous configuration that receivers can treat as a permanent error. ## Track the sending sources behind the warning After a repaired test message passes, the remaining operational gap is identifying other production sources that use the same visible From domain and later fail authentication or alignment. Palisade is agentic DMARC software that analyzes DMARC aggregate-report data, identifies sending sources and authentication or alignment issues, and creates prioritized remediation tickets. A human reviews the evidence and applies any DNS or DMARC policy change. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=existing_content_migration&utm_content=outlook-unverified-sender-warning) Palisade cannot remove Outlook's private indicator, change Microsoft's receiver decision, guarantee inbox placement, or prove every future message will authenticate. ## Sources and further reading - [Microsoft guidance on phishing and suspicious behavior in Outlook](https://support.microsoft.com/en-US/Outlook/mail/phishing-and-suspicious-behavior-in-outlook) - [RFC 9989: Domain-based Message Authentication, Reporting, and Conformance](https://www.rfc-editor.org/rfc/rfc9989.html) - [RFC 8601: Authentication-Results header field](https://www.rfc-editor.org/rfc/rfc8601.html) - [Palisade Domain Overview documentation](https://docs.palisade.email/page-breakdowns/domain-overview/) ## Frequently asked questions ### Does an Outlook unverified sender warning mean the message is phishing? No. Microsoft presents the warning as a caution signal when it cannot identify the sender through authentication evidence or when the authenticated identity differs from the displayed sender. Inspect the message and its trusted authentication results before deciding how to handle it. ### Can SPF pass while the visible sender remains unverified? Yes. SPF can pass for the envelope-sender domain shown in `smtp.mailfrom` while that domain does not align with the visible From domain. That SPF pass does not satisfy DMARC alignment for the displayed sender. ### Can DKIM pass while DMARC fails? Yes. DKIM can pass for the `d=` signing domain while that domain does not align with the visible From domain. DMARC requires an aligned SPF or DKIM pass under the [applicable alignment mode](/learning/glossary/dmarc-adkim-aspf). ### Will changing the Outlook Safe Senders list fix sender authentication? No. A recipient Safe Senders entry can affect that recipient's handling, but it does not repair the sender's SPF, DKIM, or DMARC configuration for other recipients. ### Does a passing DMARC record lookup remove Outlook's warning? No. A DMARC record lookup shows the currently published public DNS policy. It cannot prove which path sent a message, inspect Microsoft's private evaluation, or guarantee that Outlook will remove an indicator. ### What evidence should I give the sender administrator? Provide a redacted copy of the original message source, the visible From domain, Return-Path when available, trusted `Authentication-Results`, DKIM `d=` and selector, the sending application or tenant, and the time of delivery. Exclude message content, recipient data, credentials, tokens, and private keys. --- # What is a quid pro quo attack? Canonical: https://www.palisade.email/learning/what-is-a-quid-pro-quo-attack > A quid pro quo attack trades a fake favour (IT help, a gift, a job) for your credentials or access. Here is how it works and how to stop it. A quid pro quo attack is a [social engineering](/learning/threats) technique where an attacker offers a service or benefit (tech support, a gift card, a job) in exchange for information or access. The Latin phrase means "something for something," and that is the whole trick: the victim feels they are getting a fair trade while actually handing over credentials, letting malware in, or granting a foothold. Unlike [phishing](/learning/what-is-phishing) that leans on fear or urgency, quid pro quo leans on the appeal of a favour, which makes it easy to miss. ## Quick Takeaways - A quid pro quo attack exchanges a fake favour for sensitive information or system access. - The classic version is a fake IT-support call: "I'll fix your issue, just give me your login to proceed." - It is a form of social engineering, closely related to baiting, pretexting, and [impersonation](/learning/what-is-an-impersonation-attack-and-how-can-you-stop-it). - Because the exchange happens in real time, attackers can improvise, name-dropping your manager the moment you sound suspicious. - Common lures include free software, gift-card surveys, technical help, and too-good-to-be-true job offers. - Defences are behavioural: verify identity out-of-band, never share credentials, and give staff a no-blame way to report offers that feel off. ## How does a quid pro quo attack work? A quid pro quo attack works by pairing a request with an incentive so the request feels reasonable. The attacker leads with the benefit, then asks for the thing they actually want: - **Pick a plausible favour.** The attacker chooses something the target would welcome: help with a slow computer, a reward for a quick survey, early access to software, or a lucrative contract. - **Open with the offer.** They make contact by phone, email, chat, or social media and lead with the benefit, not the ask. This lowers the target's guard because the interaction looks like the attacker is *giving*, not taking. - **Attach the "small" condition.** To deliver the favour, they need something: your password "to log in and fix it," a code read off your screen, a file installed, or a form filled out on a spoofed page. - **Collect and pivot.** Once the target complies, the attacker harvests credentials, plants malware, or banks the access for later. Because it is a live conversation, they adapt, if you hesitate, they add pressure or borrow authority by dropping a real colleague's name. The exchange is entirely one-sided: the "favour" is either never delivered or is itself the payload. ## What are common examples of quid pro quo attacks? Quid pro quo attacks reuse a handful of reliable scripts: - **Fake IT support.** An attacker calls employees claiming to resolve a known issue (a password reset, a "security update") and asks for login credentials or a remote-access session to proceed. In a large organisation, some employee is usually genuinely waiting on IT, so the timing lands. - **Gift-card or survey lures.** An email promises a reward (a coffee voucher, an Amazon gift card) for completing a short "employee satisfaction survey." The survey link leads to a spoofed login page that harvests corporate credentials. - **Free software or "premium" access.** The offer is a free tool, license key, or upgrade; the download is trojanised, or activation requires disabling security controls. - **Job-offer traps.** Attackers pose as recruiters with an attractive role. In one well-documented case, a criminal group set up a fake cybersecurity company and advertised penetration-testing jobs, tricking applicants into deploying ransomware on live targets as part of their supposed "work." Each one trades on reciprocity: the instinct to give something back when we have been given something first. ## How is quid pro quo different from other social engineering? Quid pro quo overlaps with several tactics but is defined by the *exchange*: - **Baiting** dangles a tempting item (a "lost" USB drive, a free movie download) and waits for curiosity to take over. Quid pro quo is more interactive: the attacker is present and asks directly for something in return. - **Pretexting** invents a backstory to justify a request (posing as an auditor, a bank, a supplier). Quid pro quo often *uses* a pretext, but its defining feature is the promised benefit attached to the ask. - **[Phishing](/learning/what-is-phishing)** and [spear phishing](/learning/what-is-spear-phishing) usually push fear or urgency ("your account is locked"). Quid pro quo pulls with a reward instead, which can slip past staff trained only to spot threats. - **[Impersonation attacks](/learning/what-is-an-impersonation-attack-and-how-can-you-stop-it)** and [tailgating or piggybacking](/learning/what-is-piggybacking-in-cybersecurity) may be layered in. An attacker might impersonate a vendor to make the favour credible, then trade it for building or system access. It is one of the harder tactics for an untrained eye to spot precisely because it feels helpful rather than hostile. ## How do you prevent quid pro quo attacks? Because quid pro quo targets people rather than systems, the strongest controls are behavioural, backed by technical guardrails: - **Verify identity out-of-band.** If someone offers IT help or a reward, confirm through a known channel (your real help-desk number or a manager) not the contact details the offer arrived with. - **Make "no credentials, ever" a rule.** Legitimate IT and vendors do not need your password to help you. Treat any request for one as an attack, full stop. - **Be sceptical of unsolicited rewards.** Gift-card surveys, surprise bonuses, and free premium software from outside your normal procurement are classic bait. Check links with a [phishing link checker](/tools/phishing-link-checker) before entering anything. - **Train with realistic scenarios.** Include reward-based and phone-based pretexts in [security awareness](/learning/phishing-attack-protection) exercises, not just scary phishing emails, so staff recognise the "helpful stranger" pattern. - **Report without blame.** Give people a fast, judgement-free way to flag suspicious offers. Early reports let you warn everyone else before the campaign spreads. - **Reduce what a single credential unlocks.** Strong multi-factor authentication and least-privilege access limit the damage when someone is fooled. None of this is about smarter people. It is about giving ordinary busy staff a reflex to pause and verify before they trade. ## Common issues with spotting quid pro quo attacks ### Why do these attacks bypass phishing training? Most awareness training conditions staff to look for threats: locked accounts, angry executives, urgent invoices. Quid pro quo inverts that by offering a benefit, so it does not trip the "this feels threatening" reflex. Training has to explicitly cover reward-based lures. ### Isn't caller ID or the sender address enough to verify? No. Caller ID is trivially [spoofed](/learning/what-is-spoofing), and a friendly display name tells you nothing about the real sender. Out-of-band verification: contacting the person or department through a number or address you already trust. Is the only reliable check. ### We have MFA, so are we safe from this? MFA helps but is not a cure. Attackers on a live call can walk a victim through approving a push or reading back a one-time code as part of the "fix." MFA raises the bar; it does not remove the need to verify who you are actually talking to. ## Frequently asked questions ### Is a quid pro quo attack the same as phishing? Not exactly. Phishing is the broad category of deceptive messages that trick people into acting; quid pro quo is a specific social-engineering tactic built around a promised favour. A quid pro quo attack can be *delivered* by phishing, but its defining feature is the exchange. ### What is the most common quid pro quo attack? The fake IT-support call is the classic: an attacker offers to fix a problem and asks for a password or remote-access session to do it. It works because there is almost always someone in a large organisation genuinely waiting on tech help. ### Can email authentication stop quid pro quo attacks? Partly. [DMARC](/learning/what-is-dmarc), SPF, and DKIM stop attackers from spoofing your own domain, which cuts off one convincing delivery route. But quid pro quo also arrives by phone, chat, and social media, so authentication is one layer among several, not a complete answer. Palisade shuts down the email side of these attacks by enforcing DMARC so criminals cannot impersonate your domain to make an offer look internal, and it surfaces the gaps that let lookalike senders through. See where your domain stands with the [Email Security Score](/tools/email-security-score). ## Related reading - [What is piggybacking in cybersecurity?](/learning/what-is-piggybacking-in-cybersecurity) - [How social engineering impacts business](/learning/threats) - [What is a honeytrap scam and how do you spot one?](/learning/what-is-a-honeytrap-scam-and-how-do-you-spot-one) --- # Why is Google sending MTA-STS TLS reports to my domain? Canonical: https://www.palisade.email/learning/google-mta-sts-tls-reports > Google MTA-STS TLS reports explain SMTP TLS delivery results for your domain, the policy Google found, failures, and a safe validation workflow. Google sends MTA-STS TLS reports because your domain has published an SMTP TLS Reporting, or TLS-RPT, record that asks receivers to send aggregate feedback. The reports describe Google's attempts to deliver mail to your domain, including the policy it detected, session totals, and TLS failures. A report does not by itself mean mail was lost. Read the date range and failure details, then compare them with the live MTA-STS policy, MX records, certificates, and inbound SMTP service. ## Quick takeaways - Last checked: August 12, 2026 - Next review: September 12, 2026 - Content owner: Samuel Chenard - TLS-RPT is aggregate feedback about SMTP transport security. It is separate from SPF, DKIM, and DMARC authentication. - Google Workspace documents daily TLS reports with connection, policy, traffic, and failure information for a receiving domain. - Publishing a TLS-RPT record requests reports. Google does not document TLS-RPT as a universal mandate for Google Workspace domains. ## Who is affected This tracker applies to administrators of domains that receive mail and publish an SMTP TLS Reporting record at `_smtp._tls`. [RFC 8460](https://www.rfc-editor.org/rfc/rfc8460.html) defines the TLS-RPT mechanism and the aggregate JSON report format. Google's [MTA-STS and TLS reporting documentation](https://support.google.com/a/answer/9261504?hl=en) describes reports about connections from external mail servers to a domain. In practical terms, a Google-generated report concerns Google's delivery attempts to your receiving MX hosts. It does not report outbound mail sent by your users unless Google is acting as a receiving system for another domain's report. Google does not publish a numeric traffic threshold for receiving TLS reports. A domain can receive a report with successful sessions, failures, or both. Other participating senders can send their own reports to the destination in the TLS-RPT record. For the broader protocol context, see the [infrastructure learning hub](/learning/infrastructure). ![Report-to-action flow for Google TLS reports, from published TLS-RPT DNS through policy comparison and production validation](/images/editorial/google-mta-sts-tls-reports/google-mta-sts-tls-reports-report-flow.webp "1200x738") *Source: Palisade.* ## Current requirements ### TLS-RPT publication for aggregate feedback - Applies to: A receiving domain that wants participating senders to send SMTP TLS aggregate reports. - Effective: When the domain publishes a valid TLS-RPT TXT record. RFC 8460 does not define a Google-specific enforcement date. - Required evidence: A TXT record at `_smtp._tls.yourdomain.com` with a `v=TLSRPTv1` version tag and at least one `rua` report destination. - Consequence: Participating senders can send aggregate reports to the declared destination. Publishing the record does not prove that every sender supports TLS-RPT or that every delivery attempt will appear in a report. Illustrative only. Publish the destination your organization controls, not this example value. ```text _smtp._tls.yourdomain.com. IN TXT "v=TLSRPTv1; rua=mailto:tls-reports@yourdomain.com" ``` ### MTA-STS policy matching - Applies to: A domain that publishes an MTA-STS policy and has senders that apply it. - Effective: When the sender has retrieved a valid MTA-STS policy and the policy is in `enforce` mode. - Required evidence: The live `_mta-sts.yourdomain.com` TXT record, the HTTPS policy file, current MX answers, and a production connection test for each receiving MX host. - Consequence: [RFC 8461](https://www.rfc-editor.org/rfc/rfc8461.html) says a sender applying an enforce-mode policy must not deliver when it cannot establish an authenticated TLS connection to an MX host authorized by that policy. A TLS report can include the policy that the sender observed. That makes it useful evidence for comparison, but not proof that the same policy is still live when you read the report. ### Google Workspace report content - Applies to: Google Workspace administrators receiving reports about connections to their domain. - Effective: Google documents reports as daily. Google does not publish a numeric sender threshold for this reporting behavior. - Required evidence: The report's policy domain, reporting interval, summary counts, and failure details, compared with current receiving infrastructure. - Consequence: Google says its reports can provide information about detected MTA-STS policies, traffic statistics, failed connections, and undelivered messages. The report does not identify every possible sender or establish the cause of an individual recipient's non-delivery. ## Implementation and validation ### 1. Confirm that the report was requested Check DNS for the exact receiving domain named in the report. The TLS-RPT record is distinct from the MTA-STS policy record. A domain can request reports without publishing MTA-STS, because RFC 8460 can report on other applicable TLS policies. Use the [MTA-STS checker](/tools/mta-sts) for the public record and policy inputs. A public check cannot inspect Google's report stream, your inbound mail logs, future DNS state, or every sender's connection path. ### 2. Read the reporting interval and totals RFC 8460 reports aggregate outcomes for a date range. Start with the policy domain and the start and end timestamps. Then compare the successful and failed session counts before treating a report as an incident. A report that contains successful sessions only is expected feedback. A small isolated failure count can be an operational signal, but it does not establish a persistent fault. Compare several report periods before drawing that conclusion. ### 3. Match each failure to the current receiver path Review the report's failure details alongside the MX host that handled the connection. Then compare the report's policy description with the current MTA-STS policy, DNS answers, certificate name, certificate chain, and SMTP TLS negotiation from outside your network. The report format can identify the policy context and failure category. Mapping a category to one local root cause is an operational inference until your DNS, certificate, load balancer, and MTA evidence confirms it. > Do not remove an MX host from an MTA-STS policy or disable `enforce` mode as a first response. A rushed policy change can make a legitimate backup route unavailable to senders that honor MTA-STS. ### 4. Test every advertised MX host Test primary and backup MX hosts. Include hosts with lower MX preference because senders can reach them during a failover. Confirm that each authorized hostname resolves as expected, accepts SMTP connections, offers STARTTLS, and presents a certificate valid for the host name under the policy. An illustrative MTA-STS policy has this shape: ```text version: STSv1 mode: enforce mx: mx1.yourdomain.com mx: mx2.yourdomain.com max_age: 604800 ``` The policy file belongs at the HTTPS location specified by RFC 8461. Increment the policy ID in the `_mta-sts` TXT record when you publish a changed policy so senders can detect that they should retrieve it again. ### 5. Validate at four independent layers A working DNS record is only one layer of evidence. - DNS: Query the authoritative DNS provider and at least one public resolver for `_smtp._tls`, `_mta-sts`, and the MX records. - Vendor: Review the Google-generated report for the covered interval and policy details. Google's report reflects its own observed connections. - Message and transport: Use inbound MTA logs or a controlled external SMTP test for each production MX host. DNS does not prove a successful TLS session. - Ongoing DMARC evidence: Use [DMARC aggregate reports](/tools/dmarc) to inventory mail sent using your domain. Those reports do not replace receiver-side TLS evidence. If the reports show recurring failures, preserve the report, test output, relevant DNS answers, and a redacted certificate or MTA log excerpt for the infrastructure owner. Fix the component supported by that evidence, then wait for a subsequent daily report interval before declaring the issue resolved. ## Change log ### August 12, 2026 Rechecked Google's [MTA-STS and TLS reporting documentation](https://support.google.com/a/answer/9261504?hl=en), RFC 8460, and RFC 8461. Confirmed that Google documents daily TLS reports with policy, traffic, failed-connection, and undelivered-message information. Confirmed that RFC 8460 defines aggregate reporting through a published TLS-RPT destination and that RFC 8461 defines enforce-mode delivery behavior. No Google-published numeric threshold or universal TLS-RPT mandate was found. ### July 18, 2026 Published the initial tracker with the distinction between expected aggregate reports and persistent receiver-side failures. Recorded the need to compare report evidence with live DNS, MTA-STS policy, TLS certificates, and inbound SMTP service. ## Check the public MTA-STS configuration before changing it Run your receiving domain through the [MTA-STS checker](/tools/mta-sts) to inspect the public TLS-RPT record, MTA-STS DNS record, policy file, and advertised MX host patterns. Compare that result with the report's policy domain and failure details before changing a certificate or policy. Palisade is DMARC software. It can analyze DMARC aggregate-report data, identify sending sources and authentication or alignment issues, and propose a next policy step for human review. It does not repair an inbound TLS failure, control Google's delivery decision, or make a public check continuous proof of SMTP transport behavior. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=email_authentication&utm_content=google-mta-sts-tls-reports) ## Sources and further reading - [Google Workspace MTA-STS and TLS reporting documentation](https://support.google.com/a/answer/9261504?hl=en) - [RFC 8460: SMTP TLS Reporting](https://www.rfc-editor.org/rfc/rfc8460.html) - [RFC 8461: SMTP MTA Strict Transport Security](https://www.rfc-editor.org/rfc/rfc8461.html) ## Frequently asked questions ### Why am I receiving Google MTA-STS TLS reports? You are receiving Google MTA-STS TLS reports because the receiving domain has a TLS-RPT record that requests aggregate SMTP TLS feedback. The report describes Google's attempts to connect to that domain during its reporting interval. ### Does a Google TLS report mean email was not delivered? No. A Google TLS report can contain successful sessions only. Review the failed-session count and failure details before treating it as evidence of lost mail. ### Do I need MTA-STS to receive TLS-RPT reports? No. TLS-RPT and MTA-STS use separate DNS records. RFC 8460 allows reporting for applicable SMTP TLS policies, while RFC 8461 defines MTA-STS policy discovery and enforcement behavior. ### Should I delete the TLS-RPT record to stop the reports? Only if you no longer want aggregate transport feedback. Removing the record stops an evidence source, but it does not repair an MX, certificate, DNS, or SMTP TLS problem that a report may have identified. ### Can an MTA-STS checker prove Google will deliver mail? No. An MTA-STS checker can inspect public DNS and the available policy file. It cannot prove Google's private delivery decision, a future connection outcome, or the behavior of every sender. --- # Can a domain have multiple DMARC records? Canonical: https://www.palisade.email/learning/multiple-dmarc-records > Can a domain have multiple DMARC records? No. RFC 9989 discards them all. Learn how to merge and validate one DMARC record, then verify DNS and mail flow. No. A domain must publish one DMARC policy record at a given DMARC owner name, such as `_dmarc.yourdomain.com`. Under [RFC 9989 DMARC policy discovery](https://www.rfc-editor.org/rfc/rfc9989.html), if multiple DMARC policy records are returned for one target, the receiver discards all of them. Merge the intended tags into one record, remove only duplicate DMARC records, then validate the DNS result and real mail flow. ## Quick takeaways - One DMARC owner name must return one DMARC policy record. - Multiple complete DMARC records do not combine into a stricter or newer policy. - RFC 9989 says receivers discard all returned DMARC policy records when more than one is found. - One DNS TXT record can contain several quoted strings without becoming multiple DMARC records. - A subdomain can publish its own single DMARC record at its own `_dmarc` owner name. - DNS validation confirms the published record, but delivered-message and aggregate-report evidence confirm how production mail behaves. ## Who is affected? This rule affects any organization that sends mail using a domain, especially where more than one administrator, DNS provider, email platform, or MSP can edit the DNS zone. Duplicate DMARC records often appear during a vendor migration or when a reporting service asks an administrator to add an example record without checking what is already published. The relevant identity is the DMARC owner name for the domain in the visible `From:` header. For `From: billing@yourdomain.com`, the initial lookup target is `_dmarc.yourdomain.com`. It is not automatically the organizational domain, a sending service's domain, or the domain in an SMTP envelope address. A subdomain is separate. For example, `_dmarc.news.yourdomain.com` can contain one DMARC policy record while `_dmarc.yourdomain.com` contains another. That is valid because they are different owner names. The problem is two complete policy records at the same owner name. For the broader policy and alignment model, see Palisade's [DMARC learning hub](/learning/dmarc). ## What are the requirements? RFC 9989 is the controlling DMARC standard. It is a final RFC, not a draft, and its policy-discovery rules apply whenever a receiver looks up a DMARC policy record. ### Publish one DMARC policy record at the DMARC owner name RFC 9989 defines a DMARC policy record as a DNS TXT record published below the `_dmarc` label. A valid record begins with the version tag `v=DMARC1`. ```text _dmarc.yourdomain.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com" ``` The example is illustrative only. Use the policy and reporting destination authorized for your domain. ![One DMARC TXT record at _dmarc.yourdomain.com contains the version, policy, and aggregate-reporting tags](/images/editorial/multiple-dmarc-records/multiple-dmarc-records-record-shape.webp "1200x400") *Source: Palisade.* The policy tag, reporting tags, alignment modes, and optional subdomain policy belong in that single policy record. Do not publish a second record just to add `rua`, change `p`, or set an alignment preference. ### Receivers discard multiple returned policy records [RFC 9989 section 4.7](https://www.rfc-editor.org/rfc/rfc9989.html#section-4.7) specifies the multiple-record result: if more than one DMARC Policy Record is returned for a single target, all returned records are discarded. That has a practical consequence. A receiver does not merge tags from both records. It does not select the strictest policy, the record with the latest DNS edit, or the first answer shown by a DNS dashboard. The intended DMARC policy is unavailable to that discovery attempt. For example, these are two separate policy records and must not coexist at `_dmarc.yourdomain.com`: ```text "v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com" "v=DMARC1; p=quarantine; adkim=s" ``` The safe repair is to decide which values are intended, then combine those values into one valid record. ### Split TXT character strings are not necessarily duplicate records A DNS interface or resolver can show a long TXT value as multiple quoted character strings. That display alone does not prove that the domain has multiple DMARC policy records. Count complete returned resource records that begin with `v=DMARC1`. If a resolver presents several quoted pieces as one TXT resource record, those pieces can be parts of the same published value. Before deleting anything, inspect the DNS record boundaries in the zone editor and compare the answer from more than one resolver. > Do not delete unrelated TXT records at `_dmarc.yourdomain.com` until you have confirmed they are complete DMARC policy records. DNS zones can contain other verification or service records. ## When does the requirement take effect? The single-record rule has no mailbox-provider rollout date. It applies each time a receiver performs DMARC policy discovery under RFC 9989. DNS changes have their own timing. A corrected authoritative zone can coexist temporarily with cached answers at public resolvers until the prior record's TTL expires. During that period, one resolver may show the repaired record while another still returns the old duplicate set. RFC 9989 is the current published DMARC RFC cited for this rule. The operational date that matters after a change is the expiration of cached DNS data, not a new provider enforcement date. ## How do I implement the requirement? ### 1. Identify the exact DMARC owner name Start with the domain in the visible `From:` address for the affected mail. Prefix it with `_dmarc`. For a message from `alerts@yourdomain.com`, inspect `_dmarc.yourdomain.com`. For mail from `alerts.news.yourdomain.com`, inspect `_dmarc.news.yourdomain.com` first. Record the current TXT answers before editing the DNS zone. This gives the domain owner or MSP a rollback reference if an authorized reporting address or policy tag is removed by mistake. ### 2. Separate complete records from split TXT strings Inspect each returned TXT resource record. Identify every record whose value begins with `v=DMARC1`. If there are two or more complete DMARC values at the same owner name, treat that as a duplicate-record condition. If a provider interface wraps one long value into quoted chunks, verify whether those chunks belong to a single DNS resource record before changing the zone. ### 3. Decide the intended tags before editing Confirm the intended DMARC policy, aggregate-report destination, any authorized failure-report destination, subdomain policy, and alignment modes with the domain owner. Do not overwrite an existing record with a vendor example. A vendor example may omit a reporting destination, a subdomain policy, or an alignment setting that the domain already relies on. Build one record from the settings the owner has approved. ### 4. Merge the intended tags into one record Publish one TXT record beginning with `v=DMARC1`, with each intended tag appearing once. ```text v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@yourdomain.com; adkim=s; aspf=s ``` This is illustrative only. The domain's real reporting destination and policy must be approved by the domain owner. Remove only the extra complete DMARC policy records at that owner name. Keep unrelated TXT records unless you have confirmed that they are duplicate DMARC policy records. ### 5. Allow cached DNS answers to expire Check the authoritative DNS zone after saving the change. Then query public resolvers after the prior TTL has had time to expire. If a public resolver still returns duplicates after that interval, compare its answer with the authoritative zone and check whether another DNS provider, delegated zone, or migration configuration is still publishing the old data. ## How do I validate compliance? Validate the repair in separate layers. First, check DNS. Query the authoritative DNS server and at least one public resolver for the exact `_dmarc` owner name. Confirm that each answer contains one complete DMARC policy record beginning with `v=DMARC1`. Palisade's [DMARC checker](/tools/dmarc) can inspect the public DMARC record for the domain. Second, validate the vendor or DNS-management layer. Confirm that the zone editor shows the intended single record and that every authorized reporting destination remains in the final value. A green DNS-management status does not prove that a receiving mailbox provider used the record. Third, validate a real delivered message from the production sending path. Inspect its authentication results to confirm that the source is signing or authorizing mail as expected. A valid public DMARC record does not prove that SPF or DKIM alignment passes for every sender. Fourth, review DMARC aggregate reports after data accumulates. Aggregate-report data can show the sending sources and authentication outcomes receivers reported for the domain. This is where an apparently correct record can be compared with real production traffic. For related sender-key maintenance, see [how to manage multiple DKIM records](/learning/how-can-you-effectively-manage-multiple-dkim-records). For the policy outcome once the duplicate is fixed, see [how a DMARC record protects a domain](/learning/how-does-a-dmarc-record-protect-my-domain-and-improve-email-delivery). ## Track the senders behind the repaired record A public record check can confirm that one DMARC policy record is published. It cannot show which production sources still fail SPF or DKIM alignment after the repair. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=email_authentication&utm_content=multiple-dmarc-records) to analyze DMARC aggregate-report data, identify sending sources and alignment issues, and create prioritized remediation tickets. Palisade proposes the next policy step from the evidence, while a human reviews the evidence and applies DNS changes. It does not autonomously change your DMARC policy, repair every sender, or guarantee future message authentication or inbox placement. ## Sources and further reading - [RFC 9989: Domain-based Message Authentication, Reporting, and Conformance](https://www.rfc-editor.org/rfc/rfc9989.html) - [RFC 9989 section 4.7: DMARC Policy Record](https://www.rfc-editor.org/rfc/rfc9989.html#section-4.7) ## Frequently asked questions ### Can a domain have multiple DMARC records? No. A domain can have only one DMARC policy record at a given DMARC owner name. RFC 9989 says receivers discard all returned DMARC policy records when multiple records are returned for one target. ### Will receivers use the strictest of two DMARC records? No. RFC 9989 does not instruct receivers to choose the strictest, newest, or first record. Multiple returned DMARC policy records are discarded. ### Can I publish one DMARC record for policy and another for reports? No. Put the DMARC policy and reporting tags in one record at the same `_dmarc` owner name. Adding a second complete record makes policy discovery invalid for that target. ### Are two quoted TXT strings always two DMARC records? No. A single DNS TXT resource record can be displayed as multiple quoted character strings. Inspect the DNS resource-record boundaries and count complete values that begin with `v=DMARC1`. ### Can a subdomain have its own DMARC record? Yes. A subdomain can publish one DMARC policy record at its own owner name, such as `_dmarc.news.yourdomain.com`. That is separate from the parent-domain record at `_dmarc.yourdomain.com`. ### Does removing a duplicate DMARC record make every message pass? No. Removing duplicates restores valid DMARC policy discovery. Each message still needs aligned SPF or DKIM authentication to pass DMARC. --- # Why does a DKIM checker say no record found? Canonical: https://www.palisade.email/learning/no-dkim-record-found > DKIM checker says no record found? Verify the selector and signing domain, inspect the exact DNS query, fix the public record, and retest mail. A DKIM checker says "no record found" when public DNS does not return an applicable DKIM public key for the selector and signing domain it checked. The safe next step is to take the `s=` selector and `d=` signing domain from a real `DKIM-Signature` header, query the exact DNS owner name, and then separate a missing public key from an unsigned message or a stale DNS answer. ## Quick takeaways - A DKIM public-key lookup needs both the selector and the signing domain. - The DNS owner name has the form `selector._domainkey.signing-domain`. - The visible From address does not always match the `d=` domain in a DKIM signature. - A no-record DNS result does not prove that the sending application failed to sign a message. - A returned public key does not prove that the sender has the matching private key. - Retest DNS and a newly delivered message through the same production path. ## What this tool checks The [Palisade DKIM checker](/tools/dkim) inspects publicly visible DKIM records for a submitted domain. Use it as a starting point to inspect the DNS side of DKIM, then match its findings to the exact selector used by a delivered message. [RFC 6376 defines DKIM key retrieval](https://www.rfc-editor.org/rfc/rfc6376.html). A verifier builds the key-query name from the `s=` selector and `d=` signing domain in the message's `DKIM-Signature` header: ```text selector._domainkey.signing-domain ``` For example, a message signed with `s=selector1` and `d=yourdomain.com` leads to this DNS query: ```text selector1._domainkey.yourdomain.com ``` The checker can inspect public DNS. It cannot see a private key, confirm that an application selected the expected key, prove a real message was signed, monitor later DNS changes, or reveal why one receiver made a private delivery decision. A public lookup also cannot guarantee inbox placement. ![DKIM public-key lookup structure showing the selector, _domainkey label, and signing domain](/images/editorial/no-dkim-record-found/no-dkim-record-found-records.webp "1200x533") *Source: Palisade.* ## How to run the check ### 1. Get the selector and signing domain from a delivered message Open the raw source of a recently delivered message from the affected application. Find the `DKIM-Signature` header and record its `d=` and `s=` values. Do not substitute the visible From domain unless it matches `d=`. A sender can sign with a related domain or subdomain. If the message has no `DKIM-Signature` header, there is no selector lookup to validate from that message. Move to the sending service's current domain-authentication settings and obtain the record values generated for that exact sending domain and mail stream. ### 2. Run the exact public DNS lookup Enter the signing domain into the [Palisade DKIM checker](/tools/dkim). Treat the result as domain-level public DNS evidence. If you have a selector from a real message, query the full owner name directly as well. ```bash dig +short TXT selector1._domainkey.yourdomain.com ``` A DKIM key record commonly uses a TXT record, though a provider may publish a CNAME that leads to its key material. Follow the current record instructions generated for your own account. Do not publish or copy another tenant's selector, CNAME target, or key value. ### 3. Record the evidence before changing DNS Keep the values below with the test timestamp. This prevents a domain scan, a message header, and a later DNS change from being treated as the same evidence. ```text Illustrative redacted no-record result Selector from message: selector1 Signing domain from message: yourdomain.com Exact owner queried: selector1._domainkey.yourdomain.com Returned DNS status: no TXT answer returned Record type and value: none returned Message DKIM d=: yourdomain.com Message DKIM s=: selector1 ``` This example means only that the queried public name did not return a TXT answer at that time. It does not establish why. - **No public key:** the exact query is correct, but no applicable DKIM key record is published. Compare the DNS owner name and value with the current values generated by the sending service. - **Wrong selector:** the message or provider configuration names a different `s=` value. Query the selector from the real message, not a selector from an older setup. - **Stale DNS response:** the DNS zone may already be corrected while a resolver still returns an older answer. Query the authoritative DNS service and more than one public resolver before changing the record again. - **Message was never signed:** no `DKIM-Signature` header exists. Check the sender's configuration and sending path before treating DNS as the cause. ### 4. Compare the checker result with message evidence DKIM selectors are chosen by domain owners and sending services. Public DNS does not provide a complete directory of every selector a domain may use. A domain-level scan is useful when you have only a domain. When you are diagnosing production mail, the `d=` and `s=` values from the delivered message are the more specific evidence. The [email authentication learning hub](/learning) explains how DKIM, SPF, and DMARC use related but separate evidence. ## How to interpret the results ### No record found for the expected selector This result means the lookup did not return an applicable public key record at the name built from the supplied selector and signing domain. [RFC 6376 section 6.1.2 describes the verifier's key retrieval process](https://www.rfc-editor.org/rfc/rfc6376.html#section-6.1.2). Without an applicable key record, the verifier cannot validate the signature with that key. First compare the queried owner name with the `s=` and `d=` values in the message. Then compare it with the provider-generated DNS instructions for the same account and sending domain. A no-record result does not identify which of those values is wrong. ### A public key record is returned A usable public key record means public DNS can answer for that selector and signing domain. It does not prove the affected application has the matching private key or is currently signing mail with that selector. Next, send a new message through the same application, account, sender address, and recipient path. Inspect the receiver-added authentication result. [RFC 8601 defines the `Authentication-Results` header field](https://www.rfc-editor.org/rfc/rfc8601.html), which records a receiving system's authentication assessment. ### The message has no DKIM-Signature header This is a sender-side configuration or mail-path question, not proof that the DNS key is absent. Check the sending service's authentication and signing status for the exact application or stream that produced the message. Do not replace an existing DKIM record based only on an unsigned message. Another legitimate sender may still use that selector. ### The message uses a different selector than the one checked Query the selector in the message. A domain can have several DKIM records during key rotation, a provider migration, or when multiple platforms send mail. If the next problem is a missing DMARC policy, use the related [no DMARC record found guide](/resources-post/how-to-fix-no-dmarc-record-found-in-2023). A bounce that reports no MX record is a different DNS failure and needs the workflow in [what no MX record found means in a bounce](/learning/no-mx-record-found-bounce). ## How to act on the result For an exact no-record result, use this order: - Confirm the `d=` and `s=` values in a newly delivered message. - Build the exact owner name as `selector._domainkey.signing-domain`. - Compare that owner name, record type, and value with the current values generated by the sending service. - Check that the record exists in the authoritative zone for the signing domain. - Query at least one public resolver after the authoritative answer is correct. - Send a new message through the same production path. > Do not copy a DKIM selector, CNAME target, or public key from another account. Those values belong to a specific sender configuration and can break authentication when reused. If the public record exists but the message is unsigned, fix or escalate the sender configuration. If the message is signed and public DNS returns a key but DKIM still fails, preserve the raw message and the receiver's authentication result. The diagnosis has moved beyond a missing-record check. ## How to retest Run the same exact DNS query after the authoritative answer is corrected: ```bash dig +short TXT selector1._domainkey.yourdomain.com ``` Then validate four separate layers: - **DNS:** the exact owner name returns the intended record from authoritative DNS and a public resolver. - **Vendor:** the sending service reports the relevant domain configuration as verified, where it provides that status. - **Message:** a new delivered message contains the intended `d=` and `s=` values, and the receiver reports its DKIM result. - **DMARC:** once aggregate reports accumulate, review whether the authenticated DKIM domain aligns with the visible From domain. A green provider status is configuration evidence. It does not replace a delivered-message check or prove the production sender path. ## Track the sending sources behind the result A corrected record confirms that one public DKIM lookup can succeed. It does not identify every service sending as the domain, reveal which sources still fail DKIM or DMARC alignment, or decide when the DMARC policy is ready to advance. Palisade is agentic DMARC software that analyzes DMARC aggregate-report data, identifies sending sources and authentication or alignment issues, and creates prioritized remediation tickets. It proposes a next policy step from the evidence, while a human reviews the evidence and applies any DNS or DMARC policy change. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=email_authentication&utm_content=no-dkim-record-found) Palisade does not change the DMARC policy for you, repair every sender automatically, prove private-key signing from a DNS lookup, or guarantee delivery. ## Sources and further reading - [RFC 6376: DomainKeys Identified Mail Signatures](https://www.rfc-editor.org/rfc/rfc6376.html) - [RFC 6376 section 6.1.2: DKIM key retrieval](https://www.rfc-editor.org/rfc/rfc6376.html#section-6.1.2) - [RFC 8601: Authentication-Results header field](https://www.rfc-editor.org/rfc/rfc8601.html) - [Palisade DKIM checker](/tools/dkim) - [RFC 9989: Domain-based Message Authentication, Reporting, and Conformance](https://www.rfc-editor.org/rfc/rfc9989.html) ## Frequently asked questions ### Does "no record found" mean DKIM is disabled? No. It means the checked public DNS name did not return an applicable DKIM public key. The cause may be a wrong selector, wrong signing domain, unpublished record, stale DNS response, or a lookup that does not match the sender's current configuration. ### Can I use the From domain instead of the DKIM signing domain? Only if it matches the `d=` value in the message's `DKIM-Signature` header. DKIM lookup uses the signing domain and selector, while the visible From domain is used later for DMARC alignment evaluation. ### Does a DKIM TXT record prove that messages are signed? No. The public record lets a receiver retrieve a key for a selector. A new delivered message must show the expected `DKIM-Signature` header and receiver result before you can confirm the production path is signing. ### Why does one DKIM selector work while another says no record found? Each selector identifies a separate DKIM key record. Different sending services or key-rotation periods can use different selectors, so the selector in the actual message is the one that matters for the diagnosis. ### Should I delete an old DKIM record after fixing a new one? Not immediately. Old messages can remain in transit with the earlier signature, and another active sender may use that selector. Confirm the current sending configuration and follow the provider's rotation guidance before removing an old record. --- # What is piggybacking in cybersecurity? Canonical: https://www.palisade.email/learning/what-is-piggybacking-in-cybersecurity > Piggybacking in cybersecurity is when an authorized person knowingly lets an unauthorized one into a restricted area. How it differs from tailgating. Piggybacking in cybersecurity is a physical [social engineering](/learning/phishing-attack-protection) attack in which an unauthorized person gains entry to a restricted area because an authorized person *knowingly* lets them in, usually out of courtesy or under a believable pretext. The defining feature is consent: the employee is aware of the second person and grants access anyway, holding a door, waving them past a badge reader, or accepting a "just this once" excuse. That consent is what separates piggybacking from tailgating, and it makes it a human-trust problem rather than a purely technical one. No password is cracked and no system is breached; the attacker simply exploits politeness to walk through a door that a badge was supposed to protect. ## Quick Takeaways - Piggybacking is a physical social engineering attack where an authorized person knowingly grants access to someone who shouldn't have it. - The key difference from tailgating is consent: piggybacking involves the insider's awareness and permission; tailgating happens without their knowledge. - Common pretexts include posing as a delivery driver, a new hire, a contractor, or someone whose hands are full and needs the door held. - Once inside, an attacker can steal devices, plug in rogue hardware, read unlocked screens, or set up later [email-based attacks](/learning/what-is-spear-phishing). - The term also has a networking sense, piggybacking on an unsecured Wi-Fi connection or an authenticated session. - Defenses are layered: access-control vestibules, anti-passback badges, visitor escort policies, and consistent security-awareness training. ## What is piggybacking in cybersecurity? Piggybacking is a way of defeating physical access control by borrowing someone else's authorization. Secure buildings rely on badge readers, PIN pads, and locked doors to ensure only approved people enter sensitive spaces: server rooms, offices, data centres. Piggybacking sidesteps all of it by targeting the person, not the lock. A typical attempt is quiet and unremarkable. Someone carrying boxes asks an employee to hold the door. A stranger in a hi-vis vest says they're "here to fix the AC" and an employee badges them in. A friendly face claims to be a new starter who hasn't got their badge yet. In each case the authorized person makes a conscious choice to let the other person through. That choice is exactly what the attacker engineered. It is the physical-world cousin of the trust manipulation behind [phishing](/learning/what-is-phishing) and [impersonation attacks](/learning/what-is-an-impersonation-attack-and-how-can-you-stop-it). ## What is the difference between piggybacking and tailgating? Piggybacking and tailgating both end with an unauthorized person inside a restricted area, and the words are often used interchangeably, but the mechanism differs on one point: **awareness and consent.** - **Piggybacking** is *consensual*. The authorized person knows the other individual is there and deliberately grants access: holding the door, badging them in, or accepting a pretext. It exploits trust and courtesy. - **Tailgating** is *non-consensual*. The unauthorized person slips in unnoticed, closely following someone through a door before it closes. It exploits inattention and the anonymity of a crowd. A useful test: if the insider *chose* to let them in, it's piggybacking; if the insider had *no idea*, it's tailgating. The distinction matters for defense, because piggybacking is corrected through training and culture ("verify before you grant access"), while tailgating is corrected largely through physical controls that make unnoticed entry impossible. ## What can an attacker do after piggybacking in? Physical access is a powerful foothold, which is why the technique is worth taking seriously even though it sounds low-tech. Once inside, an attacker can: - **Steal hardware**: laptops, drives, or documents left on desks. - **Plant rogue devices**: a keystroke logger, a malicious USB drop, or a small network implant on an open port. - **Read what's on screen**: unlocked workstations, sticky-note passwords, whiteboards with sensitive plans. - **Set up a follow-on attack**, reconnaissance that feeds a later business email compromise or a convincing [spear-phishing](/learning/what-is-spear-phishing) message that references real internal details. The last point is the bridge between physical and digital risk: physical intrusion often exists to make a later email or credential attack more believable. ## Is piggybacking always physical? Mostly, but not entirely. The classic meaning is physical entry, and that's how the term is used in most security-awareness contexts. There is also an electronic sense worth knowing: - **Network piggybacking**: using someone's internet connection, typically an unsecured or weakly secured Wi-Fi network, without authorization. - **Session piggybacking**: riding on an already-authenticated session (for example, a workstation a user left logged in) to act with their privileges. The common thread across all three is the same: the attacker never obtains their own legitimate access. They borrow access that belongs to someone or something already trusted: a person, a network, or a live session. ## How do you prevent piggybacking? Because piggybacking targets people, no single gadget stops it. Layer physical controls with a culture that makes "verify first" the norm: - **Access-control vestibules (mantraps) and turnstiles** allow only one person through per authentication, removing the option to hold a door. - **Anti-passback badge rules** stop a credential from being used to enter again before it has been used to exit, flagging shared or cloned badges. - **Visible visitor management** (sign-in, badges, and a required employee escort) so an unbadged stranger is obviously out of place. - **A blame-free challenge culture.** Train staff that it is expected and encouraged to politely ask an unfamiliar person for a badge, even when it feels awkward. Attackers rely on people not wanting to seem rude. - **Cameras at entry points** deter attempts and provide evidence when something goes wrong. - **Regular security-awareness training** that covers physical tactics, not just email threats, so employees recognise the pretext when they hear it. Piggybacking is a reminder that security is only as strong as its weakest human moment, and the same trust it exploits at the door is what attackers exploit in your inbox. Palisade closes the email side of that gap: it automates [DMARC](/learning/what-is-dmarc), SPF, and DKIM so that even an attacker who gets a foot in the door can't also spoof your domain to launch internal-looking phishing. Check where your domain stands with the free [Email Security Score](/tools/email-security-score). ## Frequently asked questions ### Is piggybacking illegal? Gaining access to a restricted area you're not authorized to enter is generally trespassing, and any theft or tampering that follows compounds it. Authorized penetration testers do it legally under a signed scope-of-work agreement; anyone else is committing a physical breach. ### Is piggybacking the same as social engineering? It's a *type* of social engineering, the physical, in-person variety. Like [phishing](/learning/what-is-phishing) and pretexting, it manipulates human trust rather than breaking a technical control, just at a doorway instead of over email. ### Can technology alone stop piggybacking? No. Mantraps, turnstiles, and anti-passback badges make it much harder, but a determined attacker still relies on a helpful employee. Physical controls plus a challenge-friendly culture and ongoing training are what actually reduce the risk. ### How is piggybacking different from a lookalike-domain attack? Piggybacking is a physical-entry technique; a lookalike-domain attack is purely digital, using a [near-identical domain](/learning/how-can-i-take-down-lookalike-domains) to impersonate a brand over email. Both abuse trust, but one happens at a door and the other in an inbox. ## Related reading - [What are the most common social engineering attacks?](/learning/phishing-attack-protection) - [What is spear phishing?](/learning/what-is-spear-phishing) - [How can I take down lookalike domains?](/learning/how-can-i-take-down-lookalike-domains) --- # Is Have I Been Pwned safe to use? Canonical: https://www.palisade.email/learning/is-have-i-been-pwned-safe-to-use > Have I Been Pwned is safe to use: it never logs your searches, and the password checker uses k-anonymity so your password never leaves your device. Yes, Have I Been Pwned (HIBP) is safe to use. Checking an email address only searches an index of already-public breach data. It does not add you to any list, and [the site's FAQ states that "nothing is explicitly logged by the website"](https://haveibeenpwned.com/FAQs). The password checker goes further: it uses a privacy technique called k-anonymity so your actual password never leaves your browser. The service was created by security researcher Troy Hunt in December 2013 after the Adobe breach exposed 153 million accounts, and it has become the reference tool the security industry uses to answer one question: has this address or password already turned up in a known data breach? ## Quick Takeaways - Have I Been Pwned is a free service that checks an email address or password against billions of accounts exposed in known data breaches. - Searching your email does not expose you further. The data is already public, and the site says it does not log searches. - The password checker never sends your password: it hashes it locally and transmits only the first five characters of that hash (k-anonymity). - All lookups run over an encrypted HTTPS connection, so nobody watching the network sees what you searched for. - Sensitive breaches and full domain-wide results are hidden until you verify you own the address or domain. - A hit means your credentials are circulating; the fix is to change the password, enable MFA, and watch for [phishing](/learning/what-is-phishing) that reuses the leaked data. ## What is Have I Been Pwned? Have I Been Pwned is a search engine for stolen data. When a company suffers a breach and the stolen records leak, Hunt collects the exposed email addresses (and sometimes other fields) and loads them into a searchable index. You type in your address, and HIBP tells you which breaches it appeared in and what data each one exposed: passwords, phone numbers, dates of birth, and so on. The important thing to understand is that HIBP is a *mirror* of data that is already loose on the internet. It does not hack anyone or scrape private systems. Everything in the index came from a breach that already happened, and the raw data is typically already being traded on criminal forums and the dark web before HIBP ever indexes it. Looking yourself up is strictly a read: it tells you what attackers may already know. ## Is it safe to enter your email address? Yes. Entering your email to run a breach check is safe for three concrete reasons: - **You are not revealing anything new.** If your address is in the index, it is because a breach already exposed it. Searching does not leak it to anyone; the data escaped long before you looked. - **Searches are not stored.** Per the site's FAQ, ordinary searches are not logged, and every lookup travels over an encrypted connection, so an eavesdropper on the network cannot see what you typed. - **The notify feature is opt-in and minimal.** If you subscribe to breach alerts, the service stores only your email address, the subscription date, and a verification token, not a profile of you. There is one sensible caution: only use the real site at `haveibeenpwned.com`. Attackers set up lookalike "breach checker" pages to harvest addresses and push scareware, which is the same trick behind many [fake-email scams](/learning/email-address-spoofing-prevention). Type the domain yourself rather than clicking a link from an email. ## How does the Pwned Passwords check keep your password private? This is the part people worry about most, and it is the part HIBP engineered most carefully. When you check a password, the tool **never sends the password itself** and never sends the full hash of it. Instead it uses a model called *k-anonymity*, built for HIBP by Junade Ali in 2018 and now used by password managers and browser breach checkers alike. The flow works like this: - Your browser hashes the password locally with SHA-1. - It sends only the **first five characters** of that hash to the API, nothing more. - The service returns every leaked-hash suffix that starts with those five characters (often hundreds of them). - Your browser compares the rest of your hash against that list *on your device* to see whether it matches. Because the server only ever sees a five-character prefix shared by thousands of different passwords, it cannot tell which password (or even which of the returned hashes) you were checking. The response is padded so its size doesn't give the answer away either. [Cloudflare, which powers the range API, documented the design in detail](https://blog.cloudflare.com/validating-leaked-passwords-with-k-anonymity/). It is the same privacy-preserving approach that lets [IT teams check for credential exposure](/learning/threats) without ever transmitting a live password. ## How does Have I Been Pwned get its breach data? HIBP loads data from breaches that have already been made public or shared with Hunt by researchers and, in some cases, the breached organisations themselves. Each breach entry lists the date, the number of accounts, and exactly which data classes were exposed, so you can judge the real risk rather than guess. Two categories get extra handling for privacy: - **Sensitive breaches** (from sites where mere membership is damaging) are not publicly searchable. You can only see them after signing in and verifying that you own the address. - **Domain-wide search**, which lists every breached address under a domain you control, requires you to prove you own that domain first. This is the feature MSPs use to check a whole client tenant at once, and it is why simply owning a domain isn't enough to peek at someone else's. ## What should you do if your email shows up in a breach? A hit is common and not a cause for panic, but it does call for action: - **Change the password on the breached site**, and change it anywhere you reused it. Reuse is what turns one breach into an account-takeover spree. - **Turn on multi-factor authentication** so a leaked password alone can't unlock the account. - **Expect targeted phishing.** Leaked details make convincing lures, so stay alert for messages that reference real data about you, a hallmark of [spear phishing](/learning/what-is-spear-phishing) and [email spoofing](/learning/what-is-email-spoofing-and-how-can-you-prevent-it). - **For a business domain**, treat a breach as a signal to audit exposure. When employee addresses leak, attackers try to impersonate your domain next. That last point is where Palisade fits. HIBP tells you *which* addresses have been exposed; Palisade automates [DMARC](/learning/what-is-dmarc) enforcement so those exposed addresses can't be trivially spoofed to attack your staff and customers. Run your domain through the free [Email Security Score](/tools/email-security-score) to see whether an attacker could impersonate you today. The natural next step after a breach check tells you the credentials are already out there. ## Frequently asked questions ### Is Have I Been Pwned free? Yes. Checking an email address or password is free for anyone, and breach notifications are free to subscribe to. There is a paid API tier for automated, high-volume lookups, but the manual web search most people use costs nothing. ### Can Have I Been Pwned steal my password? No. The password checker is designed so the password never reaches the server, only the first five characters of its SHA-1 hash are sent, and the match happens in your browser. Even a fully compromised server would only see a hash prefix shared by thousands of unrelated passwords. ### Does searching add me to a spam or marketing list? No. A search is a one-off lookup that isn't logged, and you are only ever emailed if you explicitly subscribe to breach notifications, which stores just your address and a verification token. ### What does "pwned" actually mean? "Pwned" is internet slang for "owned", compromised or taken over. In HIBP's context it means your account details appeared in a known data breach, so a criminal may already hold them. ## Related reading - [How can MSPs secure clients after a 10-billion-password breach?](/learning/msp) - How does dark web activity threaten organizations? - [How can IT teams prevent credential theft?](/learning/threats) --- # What is a honeytrap scam and how do you spot one? Canonical: https://www.palisade.email/learning/what-is-a-honeytrap-scam-and-how-do-you-spot-one > A honeytrap scam uses a fake romantic or friendly connection to manipulate a target into sending money or leaking data. Learn how to spot one. A honeytrap scam is a social-engineering attack that uses a fake romantic, sexual, or personal connection to manipulate a target into handing over money, secrets, or access. The attacker builds an emotional bond first (through a dating app, a social message, or a warm work email) then leverages that trust to extract what they actually came for. You spot one by watching for a relationship that moves fast, stays online, and eventually turns into a request for money, private information, or a favor that bends the rules. ## Quick Takeaways - A honeytrap uses manufactured attraction or affection as the lever, not a technical exploit. - The bond comes first; the ask (money, credentials, documents, or access) always comes later. - Honeytraps target individuals for fraud and employees for corporate or state espionage. - A honeytrap is not a [honeypot](/learning/threats): a honeypot is a defensive decoy system, while a honeytrap is an offensive people-focused con. - Classic tells are refusing to video call, escalating intimacy quickly, and inventing an emergency that only money can solve. - The defense is procedural, not romantic: verify identity out of band and never let a personal relationship override a security rule. ## What is a honeytrap scam? A honeytrap (or "honey trap") is a con built on a fabricated relationship. The scammer poses as an attractive, interesting, or sympathetic person: a match on a dating app, a friendly stranger on social media, sometimes a new colleague or recruiter, and invests real effort in making you feel connected. That connection is the whole tool. Once you trust the persona, the attacker uses your emotions to bypass the caution you would normally apply to a request for money, a login, or a sensitive file. The term comes from espionage, where operatives used romantic or sexual entanglement to compromise a target and pry loose classified information. The mechanics have since spread into everyday fraud: romance scams that drain a victim's savings, sextortion built on intimate images shared in confidence, and business-focused operations that turn a flattering connection into a foothold inside a company. Underneath the different costumes, it is one of the oldest forms of [social engineering](/learning/phishing-attack-protection), manipulating a person rather than breaking a system. ## Honeytrap vs honeypot: what's the difference? These two terms get mixed up constantly, and the difference matters. A **honeypot** is a defensive tool. Security teams deploy a deliberately vulnerable-looking system or account as a decoy to attract attackers, study their methods, and detect intrusions early. It is something *you* set up to protect a network, as covered in [how honeypots safeguard your network](/learning/threats). A **honeytrap** is an offensive tactic aimed at a person. There is no decoy server. The lure is a fake human relationship, and the target is your judgment. One is a trap you set for attackers; the other is a trap an attacker sets for you. If a "system" is involved it's a honeypot; if a *feeling* is involved it's a honeytrap. ## How does a honeytrap scam work? Most honeytraps follow a recognizable arc, whether the payload is money or data. 1. **Selection.** The attacker picks a target: sometimes at random through mass dating-app and social outreach, sometimes deliberately, such as an employee with access to finance systems or intellectual property. 2. **Contact and grooming.** They open with a warm, personalized approach and build rapport over days or weeks. The pace of intimacy is often unnaturally fast, because emotional momentum is what disables scrutiny. 3. **Trust and isolation.** They become a confidant, frequently discouraging you from involving friends, family, or coworkers who might raise doubts. 4. **The ask.** Only now does the real objective appear: a wired payment for an "emergency," a crypto "investment" opportunity, an intimate photo, a work document, or your login "just to help with something." 5. **Escalation or extortion.** If you comply, the requests grow. If you shared something compromising, it may be turned into blackmail. In a workplace setting the same script can seed a [business email compromise](/learning/what-is-the-complete-guide-to-business-email-compromise-bec-attacks-in-2025) or hand an attacker the credentials behind a [spear-phishing](/learning/what-is-spear-phishing) campaign. The relationship is the delivery mechanism; the breach is the destination. ## How do you spot a honeytrap? No single sign is proof, but honeytraps cluster around the same behaviors. Watch for the pattern, not just one flag. - **The relationship stays stubbornly online.** They always have a reason not to meet or video call: traveling, working offshore, a broken camera. A face they won't show is the strongest tell. - **Intimacy escalates fast.** Declarations of love or deep trust within days, from someone you've never met in person, are a manipulation tactic, not romance. - **Their story doesn't survive a search.** A reverse-image lookup of their photos surfaces someone else, or their profile is thin, brand new, and light on verifiable detail. Attackers reuse stolen images, much like [impersonation attacks](/learning/what-is-an-impersonation-attack-and-how-can-you-stop-it) reuse trusted names. - **Everything bends toward a request.** Sooner or later the conversation steers to money, cryptocurrency, gift cards, intimate images, or access to something at work. - **Urgency and secrecy arrive together.** A sudden crisis that only you can fix, paired with pressure to keep it between the two of you, is the closing move. For a wider checklist on separating genuine contacts from crafted ones, see [how to spot fake emails and scams](/learning/email-address-spoofing-prevention). ## How do you protect yourself and your organization? Because a honeytrap attacks trust rather than technology, the defenses are mostly procedural and human. - **Verify identity out of band.** Insist on a live video call and confirm claims independently before money or information changes hands. A persona that can't withstand verification isn't real. - **Keep money decisions off the emotional track.** Never send funds, crypto, or gift cards to someone you haven't met in person, no matter how compelling the emergency. - **Make security rules non-negotiable.** In a business, enforce that no relationship, however friendly, justifies bypassing payment approvals, sharing credentials, or emailing sensitive files. Rules that can be charmed away aren't controls. - **Train for the human angle.** Awareness of romance and relationship-based lures belongs in [security awareness training](/learning/threats) alongside phishing, because attackers increasingly blend the two. - **Limit and monitor access.** Least-privilege permissions mean a single compromised employee can't hand over the whole business, and monitoring catches unusual data movement early. ## Common issues with recognizing honeytraps ### The person seems completely real: how can I be sure? You confirm through channels they don't control. Reverse-search their photos, ask for a spontaneous live video call, and independently verify any organization or role they claim. Real people tolerate reasonable verification; a honeytrap persona will deflect, guilt-trip, or vanish when you ask. ### It started as a normal work conversation, not romance That's increasingly common. Modern honeytraps aimed at businesses may open as a flattering recruiter, a friendly new contact, or an admiring peer on a professional network, no overt romance required. The tell is the same: warmth first, then a request that quietly asks you to break a rule or move money. ### I already shared photos or information: what now? Stop all contact and don't pay any extortion demand, since paying invites more. Preserve the evidence, report it to the platform and to law enforcement, and if the exposure involves work systems, tell your security team immediately so they can reset credentials and watch for misuse. Speed and honesty limit the damage far more than silence. ## Frequently asked questions **Is a honeytrap the same as a romance scam?** A romance scam is the most common consumer form of a honeytrap, but the category is broader. Honeytraps also target employees for corporate espionage and individuals for sextortion, where the goal is data or leverage rather than a wired payment. **Can DMARC or email filters stop a honeytrap?** Not directly. Honeytraps usually unfold over dating apps, social media, and personal messages, and even the email-based ones are often written by a real human rather than a mass-spoofed template. Email authentication like [DMARC](/tools/dmarc) blocks impersonation of your domain, but human-verification habits are what stop the relationship-based con. **Why would an attacker target me if I'm not wealthy or important?** Many honeytraps are volume operations that cast wide and profit from whoever responds. Others want something other than your money (your workplace access, your company's data, or compromising material) which can make an ordinary employee a valuable target. **How is a honeytrap different from ordinary phishing?** [Phishing](/learning/what-is-phishing) is usually a quick, transactional trick, one message trying to grab a click or a credential. A honeytrap plays the long game, investing in a relationship over time so the eventual request feels natural rather than suspicious. Honeytraps exploit trust between people, and email is where many of them cross into your business: as a lure, a follow-up, or the start of an invoice-fraud attempt. Palisade can't referee your relationships, but it does close the domain-impersonation gap attackers lean on: it monitors your [SPF](/tools/spf), [DKIM](/tools/dkim), and [DMARC](/tools/dmarc) and guides you to enforcement so no one can send convincing mail *as your company*. Check where you stand with a free [Email Security Score](/tools/email-security-score) scan. ## Related reading - [Common social engineering attacks and how to protect against them](/learning/phishing-attack-protection) - [What is spear phishing?](/learning/what-is-spear-phishing) - [How does business email compromise (BEC) threaten your business?](/learning/what-is-the-complete-guide-to-business-email-compromise-bec-attacks-in-2025) --- # What is pharming and how do you prevent it? Canonical: https://www.palisade.email/learning/what-is-pharming-and-how-do-you-prevent-it > Pharming redirects you to fake websites by corrupting DNS or your hosts file to steal logins. Learn how pharming works and how to prevent it. Pharming is an attack that silently redirects you from a legitimate website to a fraudulent copy in order to steal your credentials or payment details. It works by corrupting the address-lookup step of browsing. Either the DNS system that turns a domain name into an IP address, or the local settings on your device, so that even typing the correct web address lands you on the attacker's server. You prevent it by hardening DNS, patching devices, checking for HTTPS, and stopping the phishing that usually plants the malware in the first place. ## Quick Takeaways - Pharming redirects a correct web address to a fake site by tampering with DNS resolution or a device's local settings. - The name blends "phishing" and "farming": it harvests victims at scale without needing them to click a bad link. - There are two forms, host-based pharming (malware alters your device) and DNS-based pharming (a DNS server or cache is poisoned). - Unlike phishing, pharming can catch you even when you type the URL yourself, which makes it harder to spot. - Defenses include DNSSEC, a trusted resolver, patched systems, a locked-down router, and always confirming the HTTPS padlock. - Because pharming malware often arrives by email, [SPF](/tools/spf), [DKIM](/tools/dkim), and [DMARC](/tools/dmarc) cut off a common infection route. ## What is pharming? Pharming is a redirection attack. When you visit a website, your device asks a DNS resolver to translate the human-readable domain (like `yourbank.com`) into the numeric IP address of the server that hosts it. Pharming corrupts that translation so the domain resolves to an IP address the attacker controls. Your browser loads a pixel-perfect fake of the real site, you enter your username and password, and the attacker captures them. The word is a mash-up of "phishing" and "farming." Where classic phishing lures one victim at a time with a convincing message, pharming quietly "farms" many victims by poisoning infrastructure they all rely on. Nothing in the address bar looks wrong (you typed the right domain, and the page looks right) which is exactly why pharming is dangerous. ## How does pharming work? Pharming attacks fall into two broad categories, defined by where the tampering happens. **Host-based pharming** targets your individual device. Malware (often delivered through a [phishing email](/learning/what-is-phishing) or a malicious download) edits your local `hosts` file or changes your configured DNS servers. The `hosts` file is checked before any external DNS lookup, so a single forged line silently reroutes a domain for that machine. A related tactic hijacks your router's DNS settings, which poisons lookups for every device on the network. See [how a DNS changer affects your internet](/learning/how-does-a-dns-changer-affect-your-internet) for how that router-level manipulation plays out. **DNS-based pharming** attacks the naming system itself rather than your device. In [DNS cache poisoning](/learning/dns-poisoning-redirects-prevention), an attacker feeds forged records into a resolver's cache so that everyone using that resolver is sent to the wrong IP address until the record expires. Attackers may also compromise the authoritative DNS server for a domain or hijack the domain's registrar account. Because the poison sits upstream, this form scales far beyond a single victim. Both routes end the same way: the address is correct, the destination is not. ## How is pharming different from phishing? Phishing and pharming share a goal (stealing credentials by impersonating a trusted site) but they differ in method. Phishing depends on you taking the bait: clicking a link, opening an attachment, or trusting a spoofed sender. Pharming removes that step. Once DNS or your device is compromised, you can navigate to the real address from a bookmark and still land on the fraudulent page. That silence is what makes pharming harder to catch. There is no suspicious link to hover over and no misspelled domain in the address bar. For a broader look at how impersonation attacks trick recipients, compare [phishing versus spoofing](/learning/phishing-vs-spoofing-whats-the-difference) and the wider family of [social-engineering attacks](/learning/phishing-attack-protection). In practice the two overlap: pharming malware is very often seeded by a phishing email, so the defenses reinforce each other. ## How do you prevent pharming as an individual? Most host-based pharming starts with malware, so the fundamentals matter most: - **Keep everything patched.** Update your operating system, browser, and security software so known vulnerabilities can't be used to plant redirection malware. - **Run reputable anti-malware** and let it scan downloads and email attachments before you open them. - **Check for HTTPS every time.** A pharming site has the right domain in the address bar but usually cannot present a valid TLS certificate for it. If the padlock is missing, or the browser warns that the certificate doesn't match, stop. That mismatch is one of the few reliable tells. - **Secure your router.** Change the default admin password, apply firmware updates, and disable remote administration. A hijacked router poisons DNS for your whole household or office. - **Use a trustworthy DNS resolver** (ideally one that validates DNSSEC) instead of whatever an untrusted network hands you. - **Be sceptical of email links.** Since the initial malware usually arrives by mail, learn to [spot fake emails](/learning/email-address-spoofing-prevention) and avoid the download that starts the chain. - **Enable multi-factor authentication.** If a pharming site does capture your password, a second factor stops it from being enough on its own. ## How do site owners and MSPs defend against pharming? If you run the domains your customers trust, the goal is to make your DNS hard to forge and your infection routes hard to use. - **Sign your zone with DNSSEC** so resolvers can cryptographically verify that DNS answers for your domain are genuine and reject poisoned records. - **Lock down registrar and DNS accounts** with strong, unique credentials, MFA, and registrar/registry locks to prevent domain hijacking. - **Serve HTTPS everywhere and enable HSTS** so browsers refuse to load your site over plain HTTP or with an invalid certificate, which blunts the fake-site step of pharming. - **Monitor your DNS records** for unexpected changes, and watch for [lookalike domains](/learning/how-can-i-take-down-lookalike-domains) that attackers register to support redirection campaigns. - **Stop email-borne malware at the door.** Publish [SPF](/tools/spf) and [DKIM](/tools/dkim), then enforce [DMARC](/tools/dmarc) so attackers can't send pharming malware *as your domain* to your own users and customers. ## Common issues with detecting and stopping pharming ### The website looks completely normal: how would I know? You often won't from the page alone, because pharming reuses the real design and the real domain name. The most dependable signal is the certificate: a genuine site presents valid HTTPS for its exact domain, while a pharming server usually cannot. Treat a certificate warning, a downgraded HTTP connection, or an unexpected login prompt as a reason to stop and verify. ### I cleaned the malware but I'm still being redirected Redirection can live in more than one place. Check the local `hosts` file, your device's DNS settings, *and* your router's DNS configuration, attackers frequently change several at once. If a resolver's cache was poisoned, the bad record can also persist until it expires, so flushing your DNS cache and switching to a validating resolver helps. ### Only one device is affected, not the whole network That pattern points to host-based pharming (malware or a modified `hosts` file on that single machine) rather than a poisoned upstream resolver. Isolate the device, run a full anti-malware scan, and reset any credentials entered while it was compromised. ## Frequently asked questions **Is pharming a type of phishing?** They are cousins, not the same thing. Both impersonate trusted sites to steal data, but phishing relies on tricking you into clicking, while pharming redirects you automatically by corrupting DNS or your device. Pharming is often *delivered* by a phishing email, which is why the two are discussed together. **Can HTTPS alone stop pharming?** It's one of your strongest checks but not a complete fix. A correctly configured HTTPS site with HSTS makes it very hard for a fake server to impersonate the real domain, because it can't present a valid certificate. Still pair it with patched devices, a trusted resolver, and DNSSEC. **Does DMARC stop pharming?** Not directly: DMARC governs email, not DNS resolution or web traffic. But because pharming malware usually arrives in email, enforcing DMARC (alongside SPF and DKIM) removes a major delivery channel attackers use to plant it in the first place. **What should I do if I think I've been pharmed?** Disconnect the device, scan it for malware, inspect the `hosts` file and DNS settings on both the device and the router, and reset any passwords you may have entered on the fake site, from a known-clean device. Pharming thrives on trust in a domain, and email is one of the main ways the malware behind it spreads. Palisade automates that side of the defense: it monitors your SPF, DKIM, and [DMARC](/tools/dmarc) records, shows you who is sending mail using your domain, and walks you to enforcement so attackers can't use your name to deliver the next attack. Start with a free scan from the [Email Security Score](/tools/email-security-score) tool. ## Related reading - [What is phishing?](/learning/what-is-phishing) - [DNS poisoning: how redirects happen and how to prevent them](/learning/dns-poisoning-redirects-prevention) - [Common social engineering attacks and how to protect against them](/learning/phishing-attack-protection) --- # Active vs passive monitoring: what's the difference? Canonical: https://www.palisade.email/learning/active-vs-passive-monitoring-whats-the-difference > Active vs passive monitoring: active sends synthetic test traffic; passive watches real traffic already flowing. Learn the difference and when to use each. **Active monitoring generates its own synthetic traffic (probes, test requests, synthetic transactions) and measures the response, so it can detect a problem before any real user hits it. Passive monitoring observes the real traffic already flowing through a system and reports what actually happened, so it reflects genuine user and attacker behaviour.** They answer different questions: active asks "is this working right now?", passive asks "what really occurred?" Mature security and reliability teams run both. ## Quick Takeaways - Active monitoring injects test traffic (pings, synthetic logins, scripted transactions) and measures the result. It is proactive and catches issues before users do. - Passive monitoring watches real traffic and logs without adding any of its own. It is observational and reflects actual production behaviour. - Active monitoring gives fast, predictable alerts but only tests the paths you scripted; it can miss problems you did not think to probe. - Passive monitoring sees everything real users and senders do, but it is reactive. It can only tell you about a problem after traffic has already exercised it. - In email security, [DMARC](/tools/dmarc) aggregate reports are a form of passive monitoring: they tell you what receivers actually saw, after the fact. - The two are complementary, not competing, active for early warning, passive for ground truth and forensics. | | Active monitoring | Passive monitoring | |---|---|---| | **How it works** | Sends synthetic test traffic and measures the response | Observes real traffic already flowing | | **Adds traffic?** | Yes, it generates probes | No, it only listens | | **Timing** | Proactive: can catch issues before users | Reactive: reports what already happened | | **Coverage** | Only the paths you script | Everything real traffic touches | | **Best for** | Uptime checks, SLA verification, early alerts | Forensics, real-user data, anomaly detection | | **Blind spot** | Problems on paths you did not test | Nothing to see until traffic occurs | ## What is active monitoring? Active monitoring is a technique where the monitoring system deliberately generates traffic against a target and evaluates the response. Instead of waiting for a user or another server to interact with your service, the monitor plays the role of that user on a schedule. A simple example is an uptime check that requests your homepage every 60 seconds and alerts if the status code is not 200 or the response is slow. A more advanced example is a synthetic transaction that scripts an entire login-and-checkout flow and confirms each step still works. Because active monitoring controls exactly what it sends and when, its results are predictable and easy to alert on. You know the expected response, so any deviation is a clear signal. This is why active checks underpin most service-level agreements: they measure availability and latency from a fixed vantage point at a fixed cadence. The trade-off is coverage, an active monitor only ever tests the paths you thought to script. If a bug only appears on a page nobody probes, active monitoring stays silent. ## What is passive monitoring? Passive monitoring observes traffic that is already happening and records it, adding nothing of its own. A network tap, a packet capture, application access logs, and DMARC aggregate reports are all passive: they sit in the flow and report what genuinely passed through. Passive monitoring is the closest thing you get to ground truth, because it measures real users, real senders, and real attackers rather than a scripted stand-in. That fidelity is its strength and its limit. Passive monitoring sees the actual mix of clients, geographies, and edge cases that no synthetic script would fully reproduce, invaluable for [detecting anomalies](/learning/threats) and for forensics after an incident. But it is inherently reactive: there is nothing to observe until traffic occurs, so a passive-only setup can miss a component that has simply gone quiet. If a service stops receiving requests because an upstream failed, passive monitoring may show silence rather than an obvious error. ## Active vs passive monitoring: what's the actual difference? The core difference is the source of the traffic being measured. Active monitoring creates its own; passive monitoring watches someone else's. Three practical consequences follow. **Proactive vs reactive.** Active monitoring can catch a broken endpoint at 3 a.m. before a single customer notices, because the monitor itself is the customer. Passive monitoring only reveals the problem once real traffic hits the broken path, which might be minutes or hours later. **Scripted coverage vs total coverage.** Active checks see only what you told them to test. Passive checks see everything that actually happens, including the weird real-world requests you would never have scripted. Neither is "more complete" in the abstract. They are complete along different axes. **Predictable signal vs real signal.** Because active monitoring controls the input, its output is clean and easy to threshold. Passive monitoring carries all the noise of production, which makes it richer for investigation but harder to turn into a simple up/down alert without good baselining. This is exactly why the two are usually deployed together. Active monitoring is your smoke alarm; passive monitoring is the security camera that tells you what really happened. ## When should you use active or passive monitoring? Choose based on the question you need answered. - **Use active monitoring** for availability and performance guarantees: is the service up, is login working, is the API responding within its target latency from each region? It is the right tool for SLA reporting and for early-warning alerts that must fire before users are affected. - **Use passive monitoring** when you need to understand real behaviour: which senders are using your domain, what an [intrusion prevention system](/learning/threats) is actually seeing, how genuine users experience the site, or what a device did in the minutes before an alert. It is also the basis for most detection and [incident response](/learning/how-quickly-should-your-security-team-respond-to-incidents-mttr-explained) work. - **Use both** for anything that matters. A [managed detection and response](/learning/threats) practice leans on passive telemetry for detection and active probes for health, and the combination is what closes the gaps either one leaves alone. ## How does this apply to email security? Email authentication is a clean illustration of the two styles working together. When you validate your own records: running an [SPF](/tools/spf) or [DKIM](/tools/dkim) check, or scoring your domain before you send. You are doing active monitoring: you generate a query, and you measure the answer against what it should be. That catches a misconfigured record immediately, on your schedule, without waiting for mail to fail. [DMARC](/tools/dmarc) reporting, by contrast, is passive. Receivers like Gmail and Microsoft send back aggregate reports describing what they actually saw: which IPs sent mail claiming to be your domain, and whether that mail passed authentication and [alignment](/learning/why-do-phishing-emails-pass-spf-and-dkim). No synthetic probe can tell you that a lookalike server in another country is spoofing your domain, only passive observation of real receiver data reveals it. That is why authentication is not "set and forget": the active check proves your setup is correct today, and the passive stream tells you what the rest of the internet is doing with your domain over time. Palisade sits on both sides of that line. It runs the active checks that confirm your SPF, DKIM, and DMARC records are valid, and it continuously parses the passive DMARC report stream so spoofing and misconfiguration surface as plain-language alerts instead of raw XML. If you want a quick active baseline right now, the [Email Security Score](/tools/email-security-score) tool probes the records mailbox providers actually evaluate and shows where they fall short. ## Common mistakes with monitoring A few patterns cause teams to trust their monitoring more than they should. **Relying on active monitoring alone.** If every check is synthetic, you only ever learn about the paths you scripted. Real users and real attackers routinely exercise routes your test plan never imagined. Pair active checks with passive telemetry so production reality has a voice. **Relying on passive monitoring alone.** Passive-only setups go quiet exactly when something upstream dies, because silence and health look similar. An active heartbeat distinguishes "everything is fine" from "nothing is reaching us." **Treating a passing active check as full coverage.** A green uptime check means the homepage responded: not that checkout, search, or email delivery work. Scope your synthetic transactions to the flows that actually earn revenue or protect users. **Ignoring passive data because it is noisy.** DMARC reports, access logs, and packet captures are dense and unglamorous, but they hold the ground truth for detection and forensics. Parse and baseline them rather than letting them pile up unread. ## Frequently asked questions ### Is active or passive monitoring better? Neither is better in isolation, they answer different questions. Active monitoring is proactive and predictable, ideal for uptime and SLA alerts; passive monitoring is observational and truthful, ideal for real-user data and forensics. Production systems that matter use both. ### Does passive monitoring slow down my system? No. Passive monitoring only observes traffic that is already flowing (through a tap, a log, or a report feed) so it adds no load to the monitored path. Active monitoring adds a small, controlled amount of synthetic traffic by design. ### Is DMARC reporting active or passive monitoring? DMARC aggregate reporting is passive: receiving mail servers report what they actually observed about mail using your domain, after the fact. Running a live SPF, DKIM, or DMARC record check is active, because you generate the query yourself. ### Can I use only synthetic monitoring for security? Not safely. Synthetic (active) checks confirm known-good paths work, but attackers rarely follow scripted paths. Detection and incident response depend on passive telemetry that captures what real traffic, including malicious traffic, actually did. ## Related reading - [How does an intrusion prevention system protect my network?](/learning/threats) - [How does managed detection and response protect your organization?](/learning/threats) - [How quickly should your security team respond to incidents? MTTR explained](/learning/how-quickly-should-your-security-team-respond-to-incidents-mttr-explained) --- # Why am I getting fake law enforcement emails? Canonical: https://www.palisade.email/learning/why-am-i-getting-fake-law-enforcement-emails > Fake police and Interpol emails are phishing built on fear and urgency. How to recognise one, what never to click, and how to stop them reaching staff. A fake law enforcement email is a phishing message that impersonates a police or investigative agency to pressure you into opening a malicious attachment or link. If you received one claiming your company is under investigation, it is almost certainly a scam. Real agencies do not open investigations by emailing an unsolicited "evidence" file and asking you to review it. A July 2026 campaign is doing exactly this at scale, impersonating Interpol to deliver ransomware to small businesses. ## Quick Takeaways - Genuine law enforcement agencies do not send unsolicited emails with "evidence" files or links to cloud-hosted archives you must open. - A campaign detailed by Bitdefender's Antispam Lab in July 2026 impersonates Interpol's "Cybercrime Investigation Unit" to spread ransomware. - The lure directs victims to a Proton Drive-hosted archive that hides an executable disguised as a video file; opening it installs ransomware. - Targets are small businesses across the US, Europe, Asia, and the Middle East, in sectors from legal and media to pharmaceuticals and agriculture. - These emails work by fear and authority, not by breaking your defenses. The malicious payload only runs after you open it. - [DMARC](/tools/dmarc) stops attackers from spoofing *your* domain, but cannot stop a scam sent from a domain the attacker controls, user awareness closes that gap. ## What is the fake Interpol email campaign? In early July 2026, [Bitdefender's Antispam Lab reported](https://www.bitdefender.com/en-us/blog/hotforsecurity/fake-interpol-emails-serve-ransomware) a phishing campaign that impersonates law enforcement to distribute ransomware. The emails claim to come from a "Cybercrime Investigation Unit" at Interpol and tell the recipient their company is tied to suspicious activity under investigation. The message pressures the reader to review the supposed evidence. Instead of an attachment that would be easy to scan, the email points to a file hosted on Proton Drive, a legitimate cloud service the attackers abuse to sidestep link-reputation checks. The downloaded archive appears to hold a video documenting the "investigation," but the file inside is an executable disguised as a video. Running it installs ransomware on the victim's machine. According to Bitdefender, the campaign has hit small businesses across the United States, Europe, Asia, and the Middle East, spanning sectors including legal services, media, technology, pharmaceuticals, food, and agriculture. Notably, there is no fixed ransom note: victims are told to make contact through a Tox chat channel, and the attackers negotiate a ransom sized to the organization once someone reaches out. ## Why am I getting these emails? You are getting them because your address landed on a target list, not because anything is actually wrong with your company. This is a mass [phishing](/learning/what-is-phishing) campaign. Attackers send the same authority-themed lure to thousands of small businesses and wait for a fraction to panic and open the file. The impersonation of a law enforcement body is deliberate. A message that appears to come from Interpol or "the police" triggers fear and urgency, which is precisely what social-engineering attacks rely on to short-circuit careful judgment. It is the same psychology behind [business email compromise](/learning/what-is-the-complete-guide-to-business-email-compromise-bec-attacks-in-2025) and other [impersonation attacks](/learning/what-is-an-impersonation-attack-and-how-can-you-stop-it): borrow a trusted authority, add a deadline or a threat, and many recipients act before they verify. Small businesses are chosen on purpose. They handle sensitive data and money but rarely have a dedicated security team to sanity-check an alarming email, which makes them a higher-yield target than large enterprises with mature filtering and incident response. ## How can you tell a law enforcement email is fake? Treat any unsolicited "investigation" or "evidence" email as a scam until proven otherwise. Concrete red flags in this campaign and others like it: - **It asks you to open a file or link to see "evidence."** Real investigators do not distribute case evidence to a suspect by email. A link to a cloud-hosted archive (Proton Drive, a file locker, a shared drive) is a strong tell. - **It uses authority plus urgency.** References to a named unit ("Cybercrime Investigation Unit"), a case number, or a threat of legal consequences are designed to make you act fast. - **The attachment is not what it claims.** An archive that "contains a video" but unpacks to an `.exe`, `.scr`, or other executable is malware. Genuine video files do not need to be run. - **The contact channel is off.** Being told to negotiate or respond through an anonymous chat tool such as Tox is not how any legitimate agency operates. - **The sending domain does not match the agency.** Check the actual From address and domain, not just the display name. If it fails authentication or comes from a lookalike domain, distrust it. Our guide on [spotting fake emails](/learning/email-address-spoofing-prevention) walks through how to read headers. When in doubt, do not reply and do not open anything. Contact the agency through its official website, never through the details in the email. ## Can DMARC and email authentication stop these emails? Partly, and it is important to be precise about what authentication does and does not do. [DMARC](/tools/dmarc), together with SPF and DKIM, stops attackers from sending mail that appears to come *from a domain you own and protect*. If the criminals tried to impersonate your own company's domain to reach your staff, an enforced DMARC policy (`p=quarantine` or `p=reject`) would tell receiving servers to refuse or sideline those messages. What authentication cannot do is block a message the attacker sends from a domain *they* control or from a lookalike domain they registered. Impersonating "Interpol" does not require spoofing your domain. The attacker just needs a plausible-looking sender and a scary subject line. That is why authentication is necessary but not sufficient: it protects your brand from being the vehicle, while user awareness and endpoint controls catch what arrives from elsewhere. Two things still help materially. First, get your own domain to DMARC enforcement so attackers cannot turn *your* brand into the next lure, a real risk given the same criminals impersonate trusted organizations. Second, monitor for [lookalike domains](/learning/how-can-i-take-down-lookalike-domains) that mimic your company, since [email spoofing and cousin-domain](/learning/what-is-email-spoofing-and-how-can-you-prevent-it) tricks are how impersonation campaigns often reach a target's customers. ## What should you do if you receive or opened one? If you only received the email: do not open the attachment or click the link, report it to your IT or security contact, and delete it. Reporting matters, one flagged sample warns everyone else on your team. If someone already opened the file: treat it as a live incident. Disconnect the affected machine from the network to limit ransomware spread, preserve the message and file for investigation, reset credentials that may have been exposed, and engage your incident-response process or provider. Do not pay or negotiate through the attacker's chat channel; contact real law enforcement through official channels instead. For MSPs and IT teams, Palisade automates the email-authentication layer (getting client domains to DMARC enforcement and keeping them there) so your own brand cannot be weaponized in campaigns like this while you focus attention on the user-training and endpoint defenses that stop what authentication cannot. A free [Email Security Score](/tools/email-security-score) shows which client domains are still spoofable today. For a provider-specific implementation of these authentication checks, see [Why am I getting fake payment confirmation emails?](/learning/why-am-i-getting-fake-payment-confirmation-emails). ## Frequently asked questions **Is Interpol actually emailing me?** No. Interpol and national police forces do not open investigations by emailing a company an unsolicited evidence file and asking it to review the contents. Any such email is a scam. **Why does the link go to Proton Drive or another real service?** Attackers host the payload on a legitimate cloud service so the link passes basic reputation checks. The service being real does not make the file safe. **The attachment looks like a video: is it safe to open?** No. In this campaign the "video" is an executable in disguise. Opening it installs ransomware. Legitimate videos never need to be run as a program. **Will my spam filter always catch these?** Not reliably. The lures are sent from domains the attacker controls and abuse trusted file-hosting, so they can slip past filters. Human skepticism is the backstop. **Does having DMARC mean I am protected from this?** DMARC stops attackers from spoofing your own domain, which protects your brand and customers. It does not stop a scam email sent to you from a domain the attacker owns. That takes awareness and endpoint controls. ## Related reading - [How can you spot fake emails and protect yourself from scams?](/learning/email-address-spoofing-prevention) - [What is an impersonation attack and how can you stop it?](/learning/what-is-an-impersonation-attack-and-how-can-you-stop-it) - [How does business email compromise (BEC) threaten your business?](/learning/what-is-the-complete-guide-to-business-email-compromise-bec-attacks-in-2025) --- # Why is Microsoft 365 rejecting my email with a 550 5.7.x error? Canonical: https://www.palisade.email/learning/fix-microsoft-365-550-5-7-x-access-denied > Microsoft 365 returns 550 5.7.x when your mail fails a policy or authentication check. Fix SPF, DKIM, and DMARC alignment to clear the access-denied bounce. Microsoft 365 rejects your email with a `550 5.7.x` error when the message trips a policy, authentication, reputation, recipient, or forwarding rule. The exact digits and diagnostic text tell you which branch fired: `5.7.23` is an SPF failure, `5.7.509` is a DMARC-reject failure, `5.7.511` is a banned-sender condition, and `5.7.520` blocks external forwarding. `5.7.515` is a separate Outlook.com consumer high-volume authentication rule. Match the full NDR before changing DNS or policy. ## Quick Takeaways - `550 5.7.x` is Microsoft's "access denied" family. The message reached the server but was refused on policy or authentication grounds, per [Microsoft's NDR reference](https://learn.microsoft.com/en-us/troubleshoot/exchange/email-delivery/ndr/non-delivery-reports-in-exchange-online). - `550 5.7.23` means your sending IP is not authorized by your SPF record; `550 5.7.509` means your From domain failed DMARC and you publish `p=reject`. - `550 5.7.515 Access denied, sending domain does not meet the required authentication level` is an Outlook.com consumer rule with its own [exact-code diagnosis and repair guide](/resources-post/how-to-fix-microsoft-550-5-7-515-access-denied-error). - `550 5.7.511 Access denied, banned sender` means your sending IP is banned, request removal by emailing `delist@microsoft.com` with the full NDR. - Alignment is the detail most admins miss: a passing SPF or DKIM check only satisfies DMARC when its domain matches your From domain. - Read the "Diagnostics for administrators" block in the bounce first. It contains the literal error string that decides your next move. ## Which 550 5.7.x code did you get, and what does it mean? Every `5.7.x` variant is a different rejection reason, so match your bounce to the row below before you change any DNS. Pull the full string from the **Diagnostics for administrators** section of the non-delivery report (NDR), not just the three digits, because the wording is what pins down the cause. | Bounce / signal | What it means | First action | |---|---|---| | `550 5.7.1 Delivery not authorized` | General access-denied: a recipient restriction, transport rule, or "Client host blocked using Blocklist 1" is refusing your mail. | Read the diagnostics text; if it names a blocklist, request delisting, otherwise ask the recipient's admin to allow you. | | `550 5.7.23 ... Sender Policy Framework violation` | The recipient validated SPF and your sending IP is not authorized by your SPF record (or SPF is missing or broken). | Add every sending service to one SPF record and re-check it. | | `550 5.7.26 Unauthenticated email ... DMARC policy` | Google/Gmail's rejection when your mail is unauthenticated and your domain publishes DMARC quarantine or reject (Microsoft's equivalent is `5.7.509`). | Authenticate with SPF and DKIM and align both to your From domain. | | `550 5.7.509 ... does not pass DMARC verification` | Microsoft's DMARC-reject bounce: your `5322.From` domain failed DMARC and your policy is `p=reject`. | Fix the failing or unaligned SPF/DKIM so DMARC passes for your From domain. | | `550 5.7.511 Access denied, banned sender` | The IP you send from is banned on Microsoft's side. | Email `delist@microsoft.com` with the full NDR and IP, then fix the reputation cause. | | `550 5.7.515 ... does not meet the required authentication level` | High-volume mail (5,000+/day) to Outlook.com/Hotmail/Live that does not meet Microsoft's SPF, DKIM, and DMARC requirements. | Use the [exact 550 5.7.515 guide](/resources-post/how-to-fix-microsoft-550-5-7-515-access-denied-error); SPF and DKIM must both pass, while DMARC needs at least one aligned pass. | | `550 5.7.520 ... does not allow external forwarding` | Your tenant's outbound anti-spam policy is blocking automatic external forwarding. | Stop the auto-forward, or have an admin enable forwarding in the outbound spam policy. | ![Triage flowchart for diagnosing which Microsoft 365 550 5.7.x bounce code you received and its fix](/images/figures/fix-microsoft-365-550-5-7-x-access-denied-triage.webp "1200x980") ## What does 550 5.7.1 mean on Microsoft 365? `550 5.7.1` is Microsoft's broadest "access denied" verdict: the receiving system accepted the connection but a policy stopped delivery. Per [Microsoft's guidance for error 5.7.1](https://learn.microsoft.com/en-us/troubleshoot/exchange/email-delivery/ndr/fix-error-code-550-5-7-1-in-exchange-online) (which also covers everything from `5.7.0` to `5.7.999`) it "typically indicates a security setting in your organization or the recipient's organization is preventing your message from reaching the recipient." In practice it lands in one of a few buckets: - **A recipient or group restriction.** The mailbox or distribution group only accepts mail from authenticated or internal senders, so an external message is refused. Only the recipient's admin can loosen that. - **A transport (mail flow) rule.** A rule on either side matched your message and rejected it. - **Your IP is on Microsoft's blocklist.** The diagnostics read `Client host [x.x.x.x] blocked using Blocklist 1; To request removal from this list please forward this message to delist@microsoft.com`. That is a reputation problem, not a rule problem, so start with a [public blocklist check on the domain](/tools/domain-reputation) and see the delisting steps below. - **A broken SPF or MX record** on your domain, which Microsoft explicitly lists as a cause on the 5.7.1 page. Because the trigger varies, the diagnostics text is the deciding clue. A blocklist line means fix reputation; a `RESOLVER.RST.AuthRequired` line means the recipient requires authentication you cannot provide as an outsider. ## Why does Microsoft return 5.7.23 or 5.7.509 for authentication failures? Because Microsoft maps each authentication protocol to its own code, and knowing which one fired tells you exactly which record to fix. `5.7.23` and `5.7.509` are the two you will meet most. `550 5.7.23 The message was rejected because of Sender Policy Framework violation` means the recipient checked SPF and your sending server was not on your domain's authorized list. Microsoft's [NDR reference](https://learn.microsoft.com/en-us/troubleshoot/exchange/email-delivery/ndr/non-delivery-reports-in-exchange-online) describes it as "the destination email system uses SPF to validate inbound mail, and an issue affects your SPF configuration." The usual cause is a new sending service (a CRM, ticketing tool, or marketing platform) that you never added to your SPF TXT record. `550 5.7.509 Access denied, sending domain does not pass DMARC verification and has a DMARC policy of reject` is a DMARC rejection. Your `5322.From` domain failed DMARC and, because your own published policy is [`p=reject`](/learning/glossary/dmarc-p-reject), Microsoft honors that instruction and refuses the message. It is your policy doing exactly what you told it to. The problem is that a legitimate stream is not authenticating. This is the Microsoft counterpart to the code Gmail returns (`550 5.7.26`), and the same failure mode we cover for [Gmail's 550 rejections](/learning/smtp-error-codes/550-5-7-26). The order of operations is the same for both: confirm which protocol is failing, fix the record, then confirm the passing domain aligns with your From domain. If you are new to how the three protocols interlock, our overview of [email authentication](/learning/what-is-email-authentication-and-why-does-it-matter) sets the foundation before you touch DNS. ## How do you fix a 550 5.7.x authentication rejection? Work through the three protocols in order, then verify alignment. This sequence resolves the large majority of `5.7.23` and `5.7.509` bounces. For `5.7.515`, use the [exact Outlook.com high-volume procedure](/resources-post/how-to-fix-microsoft-550-5-7-515-access-denied-error), which separately requires both SPF and DKIM to pass. 1. **Publish a complete SPF record.** Put every service that sends as your domain into a single SPF TXT record. One record only, since Microsoft rejects domains with multiple SPF records. Confirm it resolves and stays under the 10-lookup limit with Palisade's [SPF checker](/tools/spf). If you send through Google Workspace as well, our [Google Workspace SPF guide](/learning/how-do-i-set-up-spf-for-google-workspace) shows how to merge senders into one record. 2. **Enable DKIM signing.** Turn on DKIM in each sending platform and publish the public key it gives you. Validate the signature with the [DKIM checker](/tools/dkim). DKIM is the more resilient of the two because, unlike SPF, it survives most forwarding. 3. **Publish a DMARC policy.** Add a record at `_dmarc.yourdomain.com`, starting at `v=DMARC1; p=none; rua=mailto:reports@yourdomain.com` so you can [watch reports before enforcing](/learning/glossary/dmarc-p-none). Check syntax with the [DMARC checker](/tools/dmarc). 4. **Confirm alignment.** Make sure the domain that passes SPF or DKIM matches your visible From domain. This is where "everything is configured but Microsoft still bounces me" almost always resolves. See the next section. 5. **Re-send and read the headers.** Send a test to an Outlook.com or Microsoft 365 recipient, open the message source, and confirm `spf=pass`, `dkim=pass`, and `dmarc=pass` for your own domain. Use the [DNS lookup tool](/tools/dns-lookup) to confirm each record is actually published and propagated, and the [MX record checker](/tools/mx) to rule out a routing problem masquerading as a policy one. ## When should you use the exact 550 5.7.515 guide? Use the exact guide when the NDR says `550 5.7.515 Access denied, sending domain [domain] does not meet the required authentication level` and the recipient is on Outlook.com, Hotmail, Live.com, MSN, or another Microsoft consumer service. This is not a generic Microsoft 365 tenant error. Microsoft requires SPF and DKIM to both pass, a valid DMARC policy (`p=none`, `p=quarantine`, or `p=reject`) to exist, and DMARC to pass because SPF or DKIM aligns with the visible `5322.From` domain. The [550 5.7.515 guide](/resources-post/how-to-fix-microsoft-550-5-7-515-access-denied-error) contains the message-header evidence template, alignment examples, and same-stream retest procedure; keep this page for classifying other `5.7.x` codes. ## Why does alignment decide whether your fix works? Alignment is the rule that a passing SPF or DKIM check must belong to the *same* domain that appears in your From header. Without it, a spammer could pass SPF for a throwaway domain while forging your name, technically authenticated, completely fraudulent, so DMARC refuses to count an unaligned pass. Two failure modes cause almost every "authenticated but still rejected" case: - **SPF authenticates the wrong domain.** SPF validates the hidden Return-Path, which many platforms set to *their* domain, not yours. SPF passes for the platform but does not align with your From domain, so DMARC sees no aligned pass. - **DKIM signs with a mismatched domain.** If the `d=` tag in the signature is your provider's domain rather than yours, the signature is valid but unaligned, the exact trap covered in [why your DKIM signature fails alignment](/learning/why-does-my-dkim-signature-fail-alignment). The durable fix is to authenticate on a subdomain you control, which keeps SPF and DKIM aligned under DMARC's default relaxed matching. A DMARC pass can clear `5.7.509`; `5.7.515` additionally requires separate SPF and DKIM passes, so follow the exact-code test rather than assuming the two errors clear together. ## Common issues with Microsoft 365 550 5.7.x rejections ### The bounce says my IP is banned (5.7.511 or a blocklist line) `550 5.7.511 Access denied, banned sender` (and the `Blocklist 1` variant of `5.7.1`) mean Microsoft has banned your sending IP, usually after spam complaints or a compromised account. Authentication alone will not clear it. Email `delist@microsoft.com` with the full NDR and IP address to request removal, as [Microsoft's NDR reference](https://learn.microsoft.com/en-us/troubleshoot/exchange/email-delivery/ndr/non-delivery-reports-in-exchange-online) directs. Then fix the underlying cause, because a delisting will not hold if the behavior repeats. Enrolling the IP in Microsoft's [Smart Network Data Services](https://sendersupport.olc.protection.outlook.com/snds/index) shows you the complaint and trap data driving the reputation, and our guide to [checking and improving domain reputation](/learning/how-can-you-check-and-improve-your-email-domain-reputation) covers the recovery work. ### Only mail through one service bounces If your main platform delivers but one stream throws `5.7.23`, that service is missing from your SPF record or is not DKIM-signing as your domain. Your DMARC aggregate reports name every source sending as you. Read them, then add the legitimate senders. This is the single most common reason a fix "works" for most mail but leaves one system bouncing. ### 550 5.7.520 blocks a forwarded message `550 5.7.520 Access denied, Your organization does not allow external forwarding` is not an authentication problem at all. Microsoft's outbound anti-spam policy blocks automatic external forwarding by default as an exfiltration safeguard. Either stop the auto-forward rule, or have an admin enable external forwarding in the outbound spam policy, knowing that turning it on organization-wide weakens a real security control. Prefer a scoped policy over a blanket allow. ### Everything authenticates but delivery is still slow Passing authentication clears the *block*, not your *reputation*. If Microsoft throttled you during the outage or your complaint rate climbed, expect deferrals to ease over days of clean sending rather than instantly. If mail is queuing rather than bouncing outright, our guide to [why email gets queued](/learning/why-is-my-email-queued-and-how-do-i-fix-it) explains the difference. For a provider-specific implementation of these authentication checks, see [How do you enable DMARC for Microsoft 365?](/learning/how-do-you-enable-dmarc-for-microsoft-365). ## Frequently asked questions ### Is 550 5.7.x a permanent or temporary failure? The `5` prefix marks a permanent failure, so the message will not retry on its own. You must fix the cause and resend. Temporary deferrals use a `4.x.x` prefix. A `550` bounce means the receiver made a final decision to refuse this message. ### Does 5.7.509 mean my DMARC is wrong? No: it usually means your DMARC is working correctly and catching a stream that fails to authenticate. Your `p=reject` policy told receivers to refuse unauthenticated mail, and Microsoft obeyed. The fix is to make the legitimate stream pass and align, not to weaken the policy. ### Do these rules apply to me if I send under 5,000 messages a day? The `5.7.515` high-volume enforcement targets bulk senders to Microsoft consumer services, but unauthenticated mail can be junked or refused at any volume. If your NDR contains that exact code, use the [550 5.7.515 guide](/resources-post/how-to-fix-microsoft-550-5-7-515-access-denied-error); otherwise classify the diagnostic text in the table above. ### How do I read the authentication result on a Microsoft bounce? Open the original message source and find the `Authentication-Results` header. It lists `spf=`, `dkim=`, and `dmarc=` with a pass or fail and the domain each applied to. If DMARC shows `fail`, compare the SPF and DKIM domains against your From domain to spot the misalignment. Palisade automates this whole loop for every domain you manage: it publishes correct SPF, DKIM, and DMARC records, reads your DMARC reports to surface unaligned or unauthorized senders before they cause a bounce, and warns you when a change would break delivery to Microsoft 365 or Outlook.com. Run your domain through the free [Email Security Score](/tools/email-security-score) tool to see exactly where you stand against Microsoft's requirements. ## Related reading - [Why is Gmail rejecting my emails with a 550 error?](/learning/smtp-error-codes/550-5-7-26) - [Why is Yahoo blocking my emails as unauthenticated?](/learning/why-is-yahoo-blocking-my-emails-as-unauthenticated) - [Why is my email queued and how do I fix it?](/learning/why-is-my-email-queued-and-how-do-i-fix-it) --- # What does SMTP error 421 mean and how do I fix it? Canonical: https://www.palisade.email/learning/what-does-smtp-error-421-mean-and-how-to-fix-it > SMTP error 421 is a temporary deferral, not a bounce. Fix it by slowing your send rate and authenticating mail with SPF, DKIM, and DMARC before retrying. SMTP error 421 is a temporary deferral, not a permanent bounce: the receiving mail server is telling your server it cannot accept the message right now and to try again later. Because the code starts with a `4`, a well-behaved sending server should automatically queue the message and retry with backoff, and most 421s clear on their own within minutes to hours. When 421 keeps coming back on every send, it is no longer a blip: it is a signal that your sending rate, reputation, or authentication (SPF, DKIM, DMARC) needs fixing, because the receiver is deliberately throttling you. ## Quick Takeaways - `421` is a **transient** reply: RFC 5321 defines the whole `4yz` class as "the error condition is temporary, and the action may be requested again," so the message has not been rejected. - The canonical text is `421 Service not available, closing transmission channel`; providers attach an enhanced code such as `421 4.7.0`, `421 4.7.28`, or `421 4.3.2` to say *why*. - The single most common cause is **rate limiting**: you sent faster than the receiver trusts your IP or domain to send, so it deferred you to slow you down. - A properly configured mail server (Postfix, Exim, Exchange, or your ESP) retries automatically. You usually do **not** resend by hand. - The real fix for a *persistent* 421 is upstream: authenticate with [SPF](/tools/spf), [DKIM](/tools/dkim), and [DMARC](/tools/dmarc), lower your volume, and repair sending reputation. - 421 differs from a `5xx` bounce: `4xx` means "try again," `5xx` means "give up." Retrying a `5xx` just wastes attempts. ## 421 signal → meaning → action Read the enhanced status code and the text after the `421`. That string tells you which lever to pull. | Bounce / signal | What it means | First action | |---|---|---| | `421 4.7.0 ... temporarily rate limited` / low IP reputation | Provider is throttling your IP on a reputation or security policy | Reduce send rate; check IP/[domain reputation](/tools/domain-reputation) and confirm SPF, DKIM, and DMARC pass | | `421 4.7.28 ... unusual rate of unsolicited mail` (Gmail) | Gmail flagged a volume spike or spam-like pattern from your IP or DKIM domain | Cut volume to Gmail, warm up gradually, review Google's Bulk Sender Guidelines | | `421 4.3.2 System not accepting network messages` / `421 4.3.0 Temporary System Problem` | Receiver is overloaded, in maintenance, or applying back-pressure | Let your MTA retry with backoff; no change needed if it is isolated | | `421 4.4.5 Server busy, try again later` | The receiving server is at capacity in that moment | Retry automatically; reduce simultaneous connections | | `421 ...` from a greylisting filter (unknown sender) | A first-contact deferral that tests whether you retry like a real sender | Do nothing. A compliant MTA retries shortly and gets through | ![Triage flowchart for diagnosing and fixing an SMTP 421 temporary deferral](/images/figures/what-does-smtp-error-421-mean-and-how-to-fix-it-triage.webp "1200x980") ## What does SMTP error 421 actually mean? It means the receiving server accepted your connection but is closing the SMTP session without taking the message, and it wants you to come back later. [RFC 5321](https://www.rfc-editor.org/rfc/rfc5321.html), the standard that defines SMTP, lists `421` as "Service not available, closing transmission channel," and notes the server can return it "after detecting the need to shut down the SMTP service", either in response to a command or asynchronously mid-conversation. The important part is the leading digit. RFC 5321 sorts every reply into three severity classes, and a `4yz` reply is a *Transient Negative Completion reply*: "the command was not accepted, and the requested action did not occur. However, the error condition is temporary, and the action may be requested again." In plain terms, nothing was lost. The receiver is not saying your message is bad. It is saying "not now." The three-number enhanced status code that usually follows (defined in [RFC 3463](https://www.rfc-editor.org/rfc/rfc3463.html)) narrows the reason: `4.7.0` is a generic security/policy deferral, `4.7.28` is Gmail's spam-rate signal, `4.3.2` means "system not accepting network messages." All share the `4`, so all are temporary. ## Is a 421 error temporary or permanent? Temporary: that is the whole point of the `4` prefix, and it is the difference that decides how you should react. A `4xx` code means retry; a `5xx` code means stop. If you treat a 421 like a hard bounce and remove the recipient, you throw away deliverable mail. If you treat a `5xx` like a 421 and keep hammering the server, you damage your reputation for no reason. Here is the contrast that trips people up: - **421 / 4xx (transient):** "Service not available, try again." The message stays in your queue. Example neighbors: `450` (mailbox temporarily unavailable) and `451` (local error in processing, often greylisting). - **550 / 5xx (permanent):** "This will never work as sent." The message bounces. A `550 5.7.1` policy rejection or a `550 5.7.9` authentication failure (like the ones behind [Gmail's 550 rejections](/learning/smtp-error-codes/550-5-7-26)) needs a real change before you resend. So a one-off 421 is harmless. A 421 that repeats on every attempt, for days, is a soft signal hardening into a delivery problem. The receiver has decided it does not trust your stream enough to let it in at full speed. ## What do the 421 4.7.0, 4.7.28, and 4.3.2 variants mean? Each variant points at a different root cause, so read the enhanced code before you change anything. - **`421 4.7.0`** is a security or policy throttle. On Google's [SMTP error code list](https://support.google.com/a/answer/3726730), `4.7.0` covers messages deferred because "the very low reputation of the sending IP address," a missing PTR (reverse DNS) record, a required TLS connection, or an IP that is not allow-listed for the recipient domain. It is the catch-all "we don't trust this connection enough right now" code. - **`421 4.7.28`** is Gmail's rate-limit-for-spam code. The full text reads `421-4.7.28 ... Our system has detected an unusual rate of unsolicited mail originating from your IP address` (a DKIM-domain variant exists too), and it points you at Google's [Bulk Sender Guidelines](https://support.google.com/mail/?p=UnsolicitedRateLimitError). It fires when your volume to Gmail spikes or your mail looks unwanted, and Gmail defers rather than accepting it. - **`421 4.3.2`** is "System not accepting network messages" per RFC 3463: the receiving system is overloaded, shutting down, or applying back-pressure. Its cousins are `421 4.3.0` ("Temporary System Problem. Try again later.") and `421 4.4.5` ("Server busy, try again later."). These usually reflect the receiver's state, not yours, and clear on retry. The pattern is consistent: `4.7.x` codes are about *you* (reputation, policy, authentication), while `4.3.x` and `4.4.x` codes are more often about the *receiver's* capacity in the moment. ## How do you fix a 421 deferral? Work from "is this even my problem" outward. Most isolated 421s need no action at all; the steps below matter when the deferral is persistent. 1. **Confirm it is repeating, not a single blip.** Check your mail logs. If one 421 was followed by a successful retry an hour later, you are done. That was normal backoff or greylisting doing its job. 2. **Read the enhanced code and text.** `4.7.28` and low-reputation `4.7.0` mean slow down and clean up; `4.3.2` / `4.4.5` usually mean wait. Match the message to the table above. 3. **Slow your send rate and warm up.** If a spike triggered it, cut volume to the affected provider and ramp back up gradually over days rather than sending a large burst. New IPs and domains especially need a gentle warm-up curve before receivers extend trust. 4. **Authenticate and align.** Publish or repair the three records and confirm they *align* with your visible From domain. Verify each with Palisade's [SPF](/tools/spf), [DKIM](/tools/dkim), and [DMARC](/tools/dmarc) checkers, and confirm the underlying DNS resolves with the [DNS lookup tool](/tools/dns-lookup). Our overview of [email authentication](/learning/what-is-email-authentication-and-why-does-it-matter) explains how the three fit together. 5. **Check reverse DNS and IP reputation.** A missing PTR record or an IP on a blocklist is a classic `4.7.0` trigger. Make sure your sending IP has valid reverse DNS pointing back to your hostname. 6. **Repair sending reputation.** If Gmail or another mailbox has throttled you for spam-like behavior, the block eases as you send clean, wanted mail with low complaints. Our guide to [checking and improving domain reputation](/learning/how-can-you-check-and-improve-your-email-domain-reputation) covers the recovery work. 7. **Let the queue do its job.** After the upstream fix, do not manually blast the backlog. Your MTA will retry on its own; forcing everything at once can re-trigger the exact rate limit you just cleared. ## Why does 421 keep happening even after retries? Because the retry solves the symptom, not the cause. Each successful retry delivers *that* message, but if the underlying reason is a rate limit or a reputation problem, the very next batch hits the same wall. The receiver is not glitching. It is consistently deciding your stream should move slower than you are trying to push it. This is the concept most senders miss: a transient code can describe a *persistent* condition. `421 4.7.28` keeps firing as long as Gmail sees an unusual rate of mail it considers unsolicited; `421 4.7.0` for low IP reputation keeps firing until that reputation recovers. The `4` promises the message can succeed on retry, not that the *pattern* will change on its own. That is why the durable fix lives upstream of the retry loop, in authentication, volume shaping, and reputation, and why a 421 you see every day is a warning rather than noise. Left alone, a receiver that keeps deferring you can escalate to outright `5xx` rejections. If your messages are piling up rather than delivering, [why your email is queued](/learning/why-is-my-email-queued-and-how-do-i-fix-it) walks through the same throttling dynamics from the sender's side. ## What should a well-behaved sending server do about 421? It should queue the message and retry on a backoff schedule, not bounce it and not retry aggressively. RFC 5321's [retry-strategy guidance](https://www.rfc-editor.org/rfc/rfc5321.html) is specific: "the retry interval SHOULD be at least 30 minutes," and retries should continue "until the message is transmitted or the sender gives up," where "the give-up time generally needs to be at least 4-5 days." In practice a compliant MTA: - **Waits before retrying.** It holds, then tries again after a growing delay (exponential backoff), rather than re-sending the same second. - **Keeps the message queued for days.** Most production servers retry for roughly 24–72 hours or longer before generating a delayed-delivery warning, and only bounce after the give-up window. - **Passes greylisting naturally.** Greylisting defers unknown senders (identified by sending IP, envelope-from, and recipient) with a temporary `4xx` code, betting that spam software will not retry. A real MTA retries minutes later and is accepted. If your platform bounces mail immediately on a 421 instead of retrying, that is a misconfiguration on *your* side. It throws away deliverable messages the standard expects you to keep trying. ## Common issues with 421 deferrals ### The 421 clears on retry but comes back every send This is the textbook "persistent transient" case. Delivery succeeds eventually, so it looks fine, but every new batch gets deferred first. It almost always means you are bumping a rate limit or a reputation ceiling. Reduce volume to that provider, warm up more slowly, and confirm authentication passes. Do not just rely on the retries to carry you. ### Only Gmail (or only one provider) returns 421 A 421 from a single mailbox provider points at your standing with *that* provider, not a broken record. Gmail throttling you with `4.7.28` while Outlook and Yahoo accept your mail usually means your Gmail-specific reputation or volume is the issue. Check [Google Postmaster Tools](https://postmaster.google.com/) for your domain and IP reputation, and pace your Gmail sending separately. ### A brand-new domain or IP gets 421 immediately New senders have no reputation, so receivers extend trust cautiously and defer early bursts. This is expected. Warm up: start with small, engaged, low-volume sends and increase gradually over one to several weeks. Trying to push production volume through a cold IP on day one is the fastest way to earn a `4.7.0` or `4.7.28` deferral. ### Your MTA gives up and bounces before the message ever delivers If a 421 turns into a hard bounce within minutes, your own retry settings are too aggressive or your give-up window is too short. RFC 5321 expects at least a 30-minute interval and a multi-day give-up time, so lengthen the queue lifetime and backoff to give transient deferrals the retries they are designed to receive. ## Frequently asked questions ### Does a 421 error mean my email bounced? No. A 421 is a temporary deferral, so the message stays in your outbound queue for another attempt. It only becomes a bounce if your server keeps getting deferred past its give-up window (typically several days) and finally stops trying. A true bounce carries a `5xx` code. ### How long should my server retry a 421 before giving up? Follow RFC 5321: retry no sooner than every 30 minutes, and keep the message queued for at least 4–5 days before abandoning it, using a backoff that spaces attempts out over time. Most MTAs ship sensible defaults; the mistake is shortening them, not lengthening them. ### Can I just resend the email manually? You can, but it rarely helps and can hurt. If the cause is a rate limit, a manual resend adds to the volume the receiver is already throttling. Let the automatic retry run, and spend your effort on the upstream fix: authentication, rate, and reputation. ### Will fixing SPF, DKIM, and DMARC stop 421 deferrals? It stops the ones caused by weak authentication and low trust, which is a large share of persistent `4.7.0` and `4.7.28` cases. It will not stop deferrals caused purely by the receiver's own load (`4.3.2`, `4.4.5`). Those are theirs to resolve, and your MTA simply retries. Authentication is the foundation, not a magic switch. ### Is 421 the same as greylisting? Greylisting is one *reason* you might see a transient deferral, but it more often uses `450` or `451` than `421`. Whatever the exact code, the handling is identical: a compliant server retries and gets through on the next attempt. For a broader map of provider-specific deferrals and bounces, see [resolving Yahoo and Gmail error codes](/learning/how-can-you-resolve-yahoo-and-gmail-email-error-codes). Palisade takes the guesswork out of the upstream fixes that make 421s go away. It publishes and monitors your SPF, DKIM, and DMARC records, reads your DMARC reports to surface unauthorized or unaligned senders inflating your volume, and flags reputation and authentication problems before receivers start throttling you. Run your domain through the free [Email Security Score](/tools/email-security-score) tool to see, in one pass, whether your authentication is the reason mailbox providers are deferring your mail. ## Related reading - [Why is my email queued and how do I fix it?](/learning/why-is-my-email-queued-and-how-do-i-fix-it) - [Why is Gmail rejecting my emails with a 550 error?](/learning/smtp-error-codes/550-5-7-26) - [How can you check and improve your email domain reputation?](/learning/how-can-you-check-and-improve-your-email-domain-reputation) --- # Spoofing vs phishing: what's the difference? Canonical: https://www.palisade.email/learning/phishing-vs-spoofing-whats-the-difference > Spoofing vs phishing: spoofing fakes an identity, while phishing uses deception to prompt a harmful action. Learn how email authentication fits. Spoofing fakes or disguises an identity signal, such as an email address, sender name, or website URL. Phishing uses a deceptive message or site to make someone disclose information, open a harmful link, install software, or take another unsafe action. One email can be both, but phishing can come from a real compromised account and spoofing can occur without a request to a person. ## Quick takeaways - Spoofing concerns a false claim about identity. - Phishing concerns a deceptive request or attempt to cause harmful action. - A forged From domain plus a fake sign-in request is both spoofing and phishing. - A compromised legitimate mailbox can send phishing without forging its domain. - DMARC helps receivers evaluate unauthorized use of an exact visible From domain. It does not detect all phishing or all spoofing. - A public DMARC lookup checks a published DNS record, not the safety of an individual email. ## How spoofing and phishing work The [FBI's spoofing and phishing guidance](https://www.fbi.gov/how-we-can-help-you/scams-and-safety/common-frauds-and-scams/spoofing-and-phishing) describes spoofing as disguising a communication to make it appear to come from a trusted source. In email, the false signal might be a display name, visible From address, Reply-To address, or a domain that resembles a known brand. [NIST defines phishing](https://csrc.nist.gov/glossary/term/phishing) as a form of social engineering that uses fraudulent solicitation to acquire sensitive information or induce another harmful action. The deceptive request is the key distinction. An email that asks a recipient to sign in, pay an invoice, approve a transfer, or open an attachment may be phishing even if its sender identity is technically authentic. For the domain-authentication part of the problem, [RFC 9989 defines DMARC](https://www.rfc-editor.org/rfc/rfc9989.html) as a way for a domain owner to state handling preferences when mail using its visible From domain fails aligned SPF and DKIM authentication. DMARC addresses unauthorized use of the exact domain in the visible From field. It does not determine whether the words, attachment, or linked website are safe. ![Relationship diagram separating sender-identity forgery from a deceptive request and showing where DMARC checks the visible From domain](/images/editorial/phishing-vs-spoofing-whats-the-difference/phishing-vs-spoofing-relationship.webp "1200x738") *Source: Palisade.* ## When the distinction changes Use two separate observations: is the message making a false claim about a specific identity, and does it ask the recipient to take a deceptive or harmful action? - A false sender identity with a credential-harvesting link is spoofing and phishing. - A lookalike domain that asks for credentials can be phishing without spoofing the protected domain. RFC 9989 notes that visually similar domains are outside DMARC's direct scope. - A legitimate but compromised mailbox can send phishing. The mailbox may use its normal authenticated sending path, while the request itself is malicious. - A forged sender identity without a deceptive request is spoofing, but it does not necessarily meet the phishing definition. This classification helps incident responders avoid treating an authentication pass as a safety verdict. SPF, DKIM, and DMARC provide evidence about mail-domain authentication. They do not prove that a sender is trustworthy, that an account is uncompromised, or that a destination URL is legitimate. For a related distinction, see [spam vs phishing](/learning/spam-vs-phishing). Broader defensive context is available in the [email threats learning hub](/learning/threats). ## Worked email example Consider a message that appears to be from `billing@yourdomain.com` and asks the recipient to sign in through a link. The evidence should be recorded separately. ```text Visible From: billing@yourdomain.com Reply-To: accounts@attacker-example.com Requested action: Sign in to review an overdue invoice Link destination: login.attacker-example.com Authentication question: Did aligned SPF or DKIM authenticate yourdomain.com? ``` The visible From address claims to represent `yourdomain.com`. If the sender did not control an authorized, aligned authentication path for that domain, this is an exact-domain spoofing question that DMARC can help receivers evaluate. The sign-in request and attacker-controlled destination are phishing evidence. Even a passing DMARC result would not establish that the linked site is safe. Conversely, a failing DMARC result does not by itself prove that every element of the message is malicious. > Do not reply to a suspicious message or use its phone number, link, or attachment to verify it. Use contact details from a known vendor portal, address book, or established internal channel. ## What to check next Start with the evidence you have. - If you have the suspicious email, preserve the original message and record the visible From address, Reply-To address, destination URL, attachment name, and requested action. A screenshot can omit headers and link targets. - If the request involves payment, credentials, or access, verify it through a known contact method. [NIST's phishing guidance](https://www.nist.gov/itl/smallbusinesscyber/guidance-topic/phishing) recommends using independently known contact information instead of details in the suspicious message. - If the visible From domain belongs to your organization, inspect its published DMARC record. Compare that DNS result with the message's authentication results, if available. - If the message came from a legitimate business address but is suspicious, escalate it through the relevant incident-response process. A DNS change is not a first response to a potentially compromised mailbox. Authentication evidence in a delivered message is commonly recorded in the `Authentication-Results` header. [RFC 8601 specifies that header field](https://www.rfc-editor.org/rfc/rfc8601.html), including the authentication method results a receiver can report. Those results are message-specific evidence. A public DNS lookup cannot replace them. For another operational distinction about what a point-in-time check can establish, see [active vs passive monitoring](/learning/active-vs-passive-monitoring-whats-the-difference). ## Check the claimed domain's DMARC record If a suspicious message claims to come from a domain you control, inspect that domain's public DMARC record before considering any policy change. Compare the published policy with the original message's authentication evidence and the sending path your team expects. [Check the claimed domain's DMARC record](/tools/dmarc) A public DMARC check cannot inspect a private message, identify a compromised mailbox, prove a link is safe, or show a receiver's final phishing decision. If you need ongoing visibility into unauthorized use of your domains, [start monitoring with Palisade](https://app.palisade.email/signup). ## Sources and further reading - [FBI: Spoofing and phishing](https://www.fbi.gov/how-we-can-help-you/scams-and-safety/common-frauds-and-scams/spoofing-and-phishing) - [NIST glossary: phishing](https://csrc.nist.gov/glossary/term/phishing) - [NIST phishing guidance](https://www.nist.gov/itl/smallbusinesscyber/guidance-topic/phishing) - [RFC 9989: Domain-based Message Authentication, Reporting, and Conformance](https://www.rfc-editor.org/rfc/rfc9989.html) - [RFC 8601: Message Header Field for Indicating Message Authentication Status](https://www.rfc-editor.org/rfc/rfc8601.html) ## Frequently asked questions ### Is spoofing always phishing? No. Spoofing is a false identity claim. Phishing requires a deceptive solicitation or request intended to cause a harmful action or disclosure. ### Can phishing happen without spoofing? Yes. A compromised legitimate mailbox can send a deceptive request through its normal mail system. A lookalike domain can also support a phishing lure without forging the exact domain it resembles. ### Does DMARC stop phishing emails? No. DMARC helps receivers evaluate unauthorized use of an exact visible From domain when aligned SPF and DKIM fail. It does not evaluate every malicious link, attachment, display-name impersonation, lookalike domain, or compromised account. ### Can an email pass DMARC and still be phishing? Yes. A message can authenticate for the domain it uses while still containing a deceptive request or malicious destination. A DMARC pass is domain-authentication evidence, not a content-safety determination. ### What is the difference between a lookalike domain and email spoofing? A lookalike domain resembles a known domain but is separately registered or controlled. Exact-domain spoofing claims to use the protected domain itself. RFC 9989 identifies visually similar domains as outside DMARC's direct scope. --- # Why is Yahoo blocking my emails as unauthenticated? Canonical: https://www.palisade.email/learning/why-is-yahoo-blocking-my-emails-as-unauthenticated > Yahoo blocks unauthenticated mail because SPF, DKIM, or DMARC failed. Fix the 550 5.7.9 'sender is unauthenticated' bounce by authenticating and aligning. Yahoo blocks your email as "unauthenticated" when the message fails to prove who sent it: meaning SPF, DKIM, or DMARC did not pass and align with your From domain. Since February 2024, Yahoo requires senders to authenticate with SPF and DKIM and to publish a DMARC policy, and it rejects mail that does not comply with a bounce such as `550 5.7.9 This mail has been blocked because the sender is unauthenticated`. The fix is to set up all three protocols correctly and confirm the passing domain matches the domain in your From address. ## Quick Takeaways - "Unauthenticated" means Yahoo could not verify your identity: SPF, DKIM, or DMARC failed or did not align with your visible From domain. - The common bounce is `550 5.7.9 This mail has been blocked because the sender is unauthenticated`; forwarded mail can trigger `554 5.7.9 Message not accepted for policy reasons`. - Since February 2024, Yahoo requires SPF **and** DKIM plus a DMARC policy of at least `p=none` for bulk senders, per [Yahoo's sender best practices](https://senders.yahooinc.com/best-practices/). - Alignment is the piece most people miss: a passing SPF or DKIM check only counts if its domain matches your From domain. - Yahoo also expects a spam-complaint rate under 0.3% and one-click unsubscribe on bulk marketing mail. - Fixing authentication typically clears the block, but a damaged sending reputation can still slow delivery afterward. ## What does "sender is unauthenticated" mean on Yahoo? It means Yahoo received your message but could not confirm it genuinely came from your domain, so it refused to deliver it. Authentication is Yahoo's way of separating real senders from spoofers, and "unauthenticated" is the verdict when none of the checks give a trustworthy answer. Three things have to line up: - **SPF** confirms the sending server is authorized by your domain. - **DKIM** confirms the message carries a valid cryptographic signature from your domain. - **DMARC** ties those results back to the From address your recipient sees, through a rule called alignment. If SPF and DKIM both fail, or they technically pass but for a *different* domain than the one in your From header. Yahoo treats the message as unauthenticated and blocks it. This is the same failure mode behind [Gmail's 550 rejections](/learning/smtp-error-codes/550-5-7-26); Yahoo and Google adopted near-identical rules at the same time. ## Why did Yahoo start blocking unauthenticated mail? Because of a policy change that took effect in February 2024. Yahoo, alongside Google, began enforcing sender requirements that had previously been recommendations. The goal was to cut spoofing and phishing by refusing mail that cannot prove its origin. For bulk senders, [Yahoo's requirements](https://senders.yahooinc.com/best-practices/) are specific: - Implement **both** SPF and DKIM. - Publish a valid DMARC policy of at least `p=none`, and DMARC must pass. - Ensure the From domain **aligns** with either the SPF domain or the DKIM domain. - Keep your spam-complaint rate below **0.3%**. - Provide a working one-click unsubscribe on marketing and subscribed messages (the RFC 8058 POST method is recommended). Google defines a "bulk sender" as one sending 5,000 or more messages a day to its users; Yahoo applies its requirements to bulk senders without publishing a single fixed count. In practice, if you send marketing or automated mail at any real volume, assume the rules apply to you. ## How do you fix Yahoo's "unauthenticated" block? Work through authentication in order, then confirm alignment. This sequence resolves the large majority of "sender is unauthenticated" bounces. 1. **Publish SPF.** Add a single SPF TXT record listing every service that sends for your domain. If you send through Google Workspace, that is `v=spf1 include:_spf.google.com ~all`; [our Google Workspace SPF guide](/learning/how-do-i-set-up-spf-for-google-workspace) covers merging multiple senders into one record. Verify it with Palisade's [SPF checker](/tools/spf). 2. **Enable DKIM.** Turn on DKIM signing in your email platform and publish the public key it gives you as a DNS record. Confirm the signature validates with the [DKIM checker](/tools/dkim). Yahoo wants both SPF and DKIM present, not one or the other. 3. **Publish DMARC.** Add a DMARC record at `_dmarc.yourdomain.com`, starting at `v=DMARC1; p=none; rua=mailto:reports@yourdomain.com`. This satisfies the policy requirement and starts sending you reports. Check it with the [DMARC checker](/tools/dmarc). 4. **Confirm alignment.** Make sure the domain that passes SPF or DKIM matches your From domain (see the next section). This is where "everything is set up but Yahoo still blocks me" almost always resolves. 5. **Resend and monitor.** Send a test to a Yahoo address, then read the headers. A clean result shows SPF and DKIM passing and DMARC passing for your domain. If you are starting from zero, our overview of [email authentication](/learning/what-is-email-authentication-and-why-does-it-matter) explains how the three protocols fit together before you touch DNS. ## What is DMARC alignment and why does Yahoo check it? Alignment is the rule that a passing SPF or DKIM check must be for the *same* domain that appears in your visible From address. Without it, a spammer could pass SPF for their own throwaway domain while forging your name in the From field, technically authenticated, yet completely fraudulent. Two ways alignment commonly breaks: - **SPF authenticates the wrong domain.** SPF checks the hidden envelope sender (the Return-Path), which many email platforms set to *their* domain, not yours. SPF passes for the platform, but under DMARC that does not align with your From domain, so it does not count. - **DKIM signs with a mismatched domain.** If the `d=` value in the DKIM signature is your provider's domain rather than yours, the signature is valid but unaligned. The reliable fix is to authenticate on a subdomain of your own domain. A dedicated sending subdomain keeps SPF and DKIM aligned under DMARC's default relaxed matching. Our guide to [aspf, adkim, and subdomain policies](/resources-post/dmarc-and-subdomains-aspf-adkim-and-sp-tags-explained) walks through how relaxed and strict alignment differ. ## Common issues with Yahoo authentication blocks ### The bounce says 554 5.7.9 instead of 550 `554 5.7.9 Message not accepted for policy reasons` usually points at DMARC on a **forwarded** message. Per [Yahoo's help documentation](https://help.yahoo.com/kb/SLN36434.html), when mail is auto-forwarded, it can arrive from an unauthorized server and fail the original domain's `p=reject` policy. Look for an `X-Yahoo-Forwarded` header on the bounced message; the fix lives with the forwarding setup, not your own DNS. ### SPF and DKIM pass but Yahoo still blocks the mail This is nearly always an alignment failure. The checks succeed for your email platform's domain rather than yours. Read the message headers: if SPF passes for `yourprovider.com` and your From address is `you@yourdomain.com`, DMARC sees no aligned pass. Move sending to a subdomain you control and re-test. ### Only some recipients are affected If a portion of your mail is blocked, suspect an unlisted sender. A tool or department sending through a service you forgot to add to SPF will fail while your main platform passes. Your DMARC aggregate reports name every source sending as your domain. Check them, then add the legitimate ones to your records. ### Authentication is fixed but delivery is still slow Authentication clears the *block*; it does not instantly restore *reputation*. If Yahoo throttled you during the outage, or your complaint rate climbed above 0.3%, expect deferrals to ease over days as you send clean, wanted mail. Our guide to [checking and improving domain reputation](/learning/how-can-you-check-and-improve-your-email-domain-reputation) covers the recovery steps. ## Frequently asked questions ### Does one SPF or DKIM pass satisfy Yahoo? For low-volume mail, a single aligned pass often gets through. But Yahoo's bulk-sender rules ask for **both** SPF and DKIM, so configure both. Relying on one leaves you a single misconfiguration away from a block. ### I don't send bulk mail. Why is Yahoo blocking me? Even below bulk thresholds, mail with no authentication at all can be refused or filtered, especially if your domain has ever been spoofed. Publishing SPF, DKIM, and a `p=none` DMARC record is the baseline for any sender in 2026. ### Will a DMARC policy of p=none stop the blocks? `p=none` satisfies Yahoo's requirement to *have* a policy and lets your mail authenticate, as long as SPF or DKIM aligns. It tells receivers to take no punitive action on failures (useful while you monitor reports) but the actual delivery depends on that aligned pass, not on the policy strength. ### How do I read the authentication result on a bounced message? Open the original message source and find the `Authentication-Results` header. It lists `spf=`, `dkim=`, and `dmarc=` with pass or fail and the domain each applied to. If DMARC shows `fail`, compare the SPF and DKIM domains against your From domain to spot the misalignment. Palisade automates this for every domain you manage: it publishes the correct SPF, DKIM, and DMARC records, reads your DMARC reports to surface unaligned or unauthorized senders, and alerts you before a change breaks delivery to Yahoo or Gmail. Run your domain through the free [Email Security Score](/tools/email-security-score) tool to see exactly where you stand against Yahoo's requirements. ## Related reading - [Why is Gmail rejecting my emails with a 550 error?](/learning/smtp-error-codes/550-5-7-26) - [Why is my email queued and how do I fix it?](/learning/why-is-my-email-queued-and-how-do-i-fix-it) - [What can we learn from Travis Hazlewood about email deliverability?](/learning/what-can-we-learn-from-travis-hazlewood-about-email-deliverability) --- # Mailgun SPF and DKIM Setup: Exact DNS Records Canonical: https://www.palisade.email/learning/how-do-i-set-up-spf-and-dkim-for-mailgun > Set up Mailgun SPF and DKIM with the exact DNS records. Learn when to use DKIM CNAMEs, why send-only domains skip Mailgun MX, and how to verify alignment. To set up SPF and DKIM for Mailgun, add your sending domain, then publish the [sending DNS records Mailgun shows for that domain](https://documentation.mailgun.com/docs/mailgun/user-manual/domains/domains-verify): Mailgun's SPF example is `v=spf1 include:mailgun.org ~all`, plus either a DKIM TXT record or the two DKIM CNAMEs used by Automatic Sender Security. Copy your dashboard's exact hostname and values. Mailgun MX records are for receiving mail at that domain; [a send-only domain does not need its MX records pointed to Mailgun](https://documentation.mailgun.com/docs/mailgun/faq/faqs), and changing MX on a domain that receives mail elsewhere can reroute inbound mail. After the domain verifies, check a real message or DMARC aggregate report: DNS verification alone does not prove that the SPF or DKIM identity aligns with the address in the visible From header. ## Quick Takeaways - Mailgun's sending setup uses an SPF TXT record plus DKIM. DKIM may be one TXT record or two CNAME records, depending on whether Automatic Sender Security is enabled. - Mailgun recommends separating transactional or marketing traffic on a sending subdomain such as `mg.yourdomain.com`. - Mailgun's DKIM selector is not universal. Copy the TXT hostname or both `pdk1` and `pdk2` CNAMEs shown for your domain. - The tracking CNAME enables Mailgun's click, open, and unsubscribe tracking; it is not an MX record. - Mailgun MX records are only needed when Mailgun will receive mail for the domain. Do not replace the MX records of a domain receiving mail through another provider. - A verified Mailgun domain can still fail DMARC if neither the SPF domain nor the DKIM signing domain aligns with the visible From domain. - Verification can take up to 24 to 48 hours; trigger a manual check under Domain settings → DNS records. ## What DNS records does Mailgun require? Mailgun separates records needed for sending from records used for receiving. Its [domain-verification documentation](https://documentation.mailgun.com/docs/mailgun/user-manual/domains/domains-verify) lists SPF and DKIM for sender authentication, a CNAME for tracking, and MX records for receiving and routing messages addressed to the Mailgun domain. Automatic Sender Security changes the DKIM part of that setup from one public-key TXT record to [two delegated CNAME records](https://documentation.mailgun.com/docs/mailgun/user-manual/domains/dkim_security). | Record | Host and value example | When to publish it | |---|---|---| | SPF TXT | `mg.yourdomain.com` → `v=spf1 include:mailgun.org ~all` | Publish the exact sending record shown by Mailgun. If that hostname already has SPF, merge the Mailgun mechanism into the existing record. | | DKIM TXT | `mx._domainkey.mg.yourdomain.com` → `k=rsa; p=...` | Publish this only when Mailgun shows manual DKIM for the domain. The selector and public key are domain-specific. | | DKIM CNAMEs | `pdk1._domainkey...` and `pdk2._domainkey...` → Mailgun-hosted targets | Publish both when Automatic Sender Security is enabled; they replace the manual DKIM TXT record for those selectors. | | Tracking CNAME | `email.mg.yourdomain.com` → the target shown by Mailgun | Publish when using Mailgun click, open, or unsubscribe tracking. | | MX records | `mxa.mailgun.org` and `mxb.mailgun.org`, priority 10 | Publish only if Mailgun should receive mail for this domain. Skip them for a send-only domain that receives mail elsewhere. | Verifying is worth doing immediately: per [Mailgun's docs](https://documentation.mailgun.com/docs/mailgun/user-manual/domains/domains-verify), unverified domains carry a 300-message daily limit and show a "sent via Mailgun.org" note to recipients. ## Should you use a subdomain or your root domain? Mailgun recommends separating transactional or marketing traffic on a dedicated domain or subdomain such as `mg.yourdomain.com`. A subdomain is especially useful when the root domain already receives corporate mail through Microsoft 365 or Google Workspace. Mailgun technically allows the visible From domain to differ from the sending domain, but [its sending FAQ recommends matching them for deliverability](https://documentation.mailgun.com/docs/mailgun/faq/sending). A subdomain is the better choice for three practical reasons: 1. **Traffic separation.** Bulk and transactional traffic builds a distinct subdomain sending history, though mailbox providers may still connect related domain signals. 2. **Fewer record conflicts.** A root domain often already has SPF and MX records for Microsoft 365 or Google Workspace, which an [MX record lookup](/tools/mx) will show you. A fresh subdomain lets you publish Mailgun's sending records without changing the root domain's inbound mail routing. 3. **Easier multi-service management.** If you run email for clients as an MSP, a `mg.` subdomain per client domain keeps each platform's records isolated and auditable. A root-domain setup is supported too. If the root already has an SPF record, [merge `include:mailgun.org` into that record](/learning/glossary/spf-include) instead of creating a second SPF policy. Do not point the root domain's MX records to Mailgun unless Mailgun is meant to receive its inbound mail. ![Mailgun Add new domain form with region, IP assignment, and Advanced settings for DKIM.](/images/editorial/how-do-i-set-up-spf-and-dkim-for-mailgun/mailgun-add-new-domain.png "1664x889") *Source: [Mailgun Help Center, “Domain Verification Setup Guide”](https://help.mailgun.com/hc/en-us/articles/32884700912923-Domain-Verification-Setup-Guide), checked July 29, 2026. First-party public interface excerpt, unmodified.* ## How do you add the Mailgun SPF record? ### 1. Open the Mailgun domain list Log in to the Mailgun control panel, expand **Sending** in the left navigation, and click **Domains**. ### 2. Add the sending domain Click **Add New Domain**, enter your sending domain (for example `mg.yourdomain.com`), and click **Add Domain**. ### 3. Publish the SPF record Mailgun shows the DNS records to publish. In your DNS host, create the SPF record on the sending domain: ``` Type: TXT Host: mg.yourdomain.com Value: v=spf1 include:mailgun.org ~all ``` If you are setting up the root domain and it already has an SPF record, do not create a second one. A hostname can only have one. Insert `include:mailgun.org` after `v=spf1` and before the existing terminal `all` mechanism, preserving that mechanism's qualifier (`-`, `~`, `?`, or `+`). Mailgun's example uses `~all`: ``` v=spf1 ip4:1.2.3.4 include:smtp.domain.tld include:mailgun.org ~all ``` Keep the merged record under SPF's limit of 10 DNS lookups, or receivers will return a permerror. You can confirm the record resolves and stays within the limit with Palisade's free [SPF checker](/tools/spf). ### 4. Confirm the public record Query the sending hostname after DNS propagates, then return to Mailgun's **DNS records** tab and click **Check status**. The result should expose one SPF policy containing `include:mailgun.org`. ## How do you add the Mailgun DKIM record? First check whether Automatic Sender Security is enabled for the Mailgun domain. With manual DKIM, Mailgun generates the key pair, keeps the private key, and gives you a TXT record containing the public key. The selector varies by domain, so always copy the exact hostname and value from the control panel: ``` Type: TXT Host: mx._domainkey.mg.yourdomain.com Value: k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4... (copy the full key from Mailgun) ``` With [Automatic Sender Security](https://documentation.mailgun.com/docs/mailgun/user-manual/domains/dkim_security), publish both CNAME records shown by Mailgun instead of copying the manual TXT example. The CNAME hosts resemble `pdk1._domainkey.mg.yourdomain.com` and `pdk2._domainkey.mg.yourdomain.com`; their targets are account-specific Mailgun hostnames. The two records let Mailgun rotate the hosted public keys without another DNS edit. Two details from Mailgun's DKIM documentation matter during verification: - **Key length.** Mailgun supports 1024-bit and 2048-bit keys. 2048 is stronger, but the record value is significantly longer, which some DNS panels handle awkwardly. - **Rotation interval.** Automatic Sender Security rotates keys every 120 days by default, and Mailgun allows the interval to be adjusted. If the dashboard lists several DKIM keys and some sit in an "Unverified" state, extra keys may be present during rotation. Verify the key or keys required by the current domain configuration; Automatic Sender Security requires both `pdk1` and `pdk2` CNAMEs to resolve to the targets Mailgun supplied. Our guide to [managing multiple DKIM records](/learning/how-can-you-effectively-manage-multiple-dkim-records) explains how selectors let keys coexist. After publishing, use Palisade's [DKIM checker](/tools/dkim) to confirm the public record resolves, then inspect a message sent through Mailgun to confirm it carries a passing signature. ## How do you verify your domain in the Mailgun dashboard? Once the records are live, Mailgun's system checks them periodically and emails you when the domain flips to Verified. Propagation can take 24 to 48 hours, though it is usually much faster. To check manually: ![Five steps to verify a Mailgun sending domain, from adding the domain in the control panel to confirming DMARC alignment with external checks.](/images/figures/how-do-i-set-up-spf-and-dkim-for-mailgun-fig2.webp "1200x813") *Mailgun also emails you automatically when the domain flips to Verified.* 1. In the control panel, expand **Sending** and click **Domain settings**. 2. Open the **DNS records** tab. 3. Pick the right domain in the **Domain** drop-down at the top right. 4. Click **Check status** (Mailgun's setup guide calls the same control the **Check DNS Records Now** button on the DNS Settings page). If Mailgun still reports records as missing, query DNS from the outside rather than trusting your provider's panel. Palisade's [DNS lookup tool](/tools/dns-lookup) shows exactly what public resolvers see for each hostname, which catches typos and propagation lag quickly. ![Mailgun Domain settings DNS records tab with verified SPF and active DKIM rows.](/images/editorial/how-do-i-set-up-spf-and-dkim-for-mailgun/mailgun-domain-dns-records.png "2318x1218") *Source: [Mailgun Help Center, “Domain Verification Setup Guide”](https://help.mailgun.com/hc/en-us/articles/32884700912923-Domain-Verification-Setup-Guide), checked July 29, 2026. First-party public interface excerpt, unmodified.* ## How does the setup affect DMARC alignment? [DMARC](/learning/what-is-dmarc) requires SPF or DKIM to pass with an authenticated domain aligned to the visible From domain. [RFC 9989 defines relaxed alignment](https://www.rfc-editor.org/rfc/rfc9989.html#section-4.4) as sharing the same organizational domain and strict alignment as an exact domain match. Here is how a Mailgun subdomain setup plays out when you send as `you@yourdomain.com` through `mg.yourdomain.com`: - **SPF:** DMARC evaluates the SPF-authenticated MAIL FROM identity, often visible as the Return-Path. If it is `mg.yourdomain.com` and the visible From domain is `yourdomain.com`, the two align in relaxed mode but not strict mode. - **DKIM:** DMARC evaluates the `d=` domain on a passing DKIM signature. A `d=mg.yourdomain.com` signature aligns with a From domain of `yourdomain.com` in relaxed mode but not strict mode. If Mailgun signs with `d=yourdomain.com`, it can align in either mode. Strict alignment is the common break point. If your DMARC record sets `aspf=s`, SPF alignment requires `yourdomain.com` and `mg.yourdomain.com` to match exactly; `adkim=s` applies the same exact-match rule to the DKIM `d=` domain. Keep relaxed alignment unless you have a tested reason to require strict matching: our guide to [aspf, adkim, and subdomain policies](/resources-post/dmarc-and-subdomains-aspf-adkim-and-sp-tags-explained) explains the tradeoff. After your first sends, inspect a delivered message's Authentication-Results header and use DMARC aggregate reports to confirm which Mailgun identity passed and aligned. ## What are common Mailgun SPF and DKIM setup problems? ### Why does Mailgun still show the domain as Unverified? An Unverified Mailgun domain usually means DNS is still propagating or a hostname or value was copied incorrectly. Verify each hostname with `dig` or an external lookup, then click **Check status**. Records must match Mailgun's values exactly. ### Why is the Mailgun SPF record missing? A missing Mailgun SPF record often means it was published at the wrong hostname. The SPF record belongs on the configured sending domain: `mg.yourdomain.com` for a Mailgun `mg.` subdomain, or the root only when the root itself is the Mailgun sending domain. Some DNS panels append the zone name automatically, so entering the full hostname can accidentally create `mg.yourdomain.com.yourdomain.com`. ### Why does Mailgun report more than one SPF record? Multiple SPF records at one hostname do not combine their authorizations. [RFC 7208 requires SPF to return PermError](https://www.rfc-editor.org/rfc/rfc7208.html#section-4.5) when DNS yields more than one SPF record, so merge Mailgun's include with the other authorized mechanisms in one policy. ### Why do Mailgun's DKIM CNAMEs conflict with existing records? Mailgun's DKIM CNAMEs cannot share their exact `pdk1._domainkey` or `pdk2._domainkey` hostname with other DNS data. Remove the conflicting record only after confirming it is obsolete, or configure Mailgun with different selectors; do not delete an active key used by another sender. ### Why does DMARC fail on Mailgun's sandbox domain? Mailgun's shared sandbox domain is [for testing with authorized recipients](https://documentation.mailgun.com/docs/mailgun/user-manual/domains/domains-sandbox), not for authenticating your own From domain. Move real traffic to a verified custom domain and then check whether its SPF or DKIM identity aligns with the visible From domain. ### Why can Mailgun SPF pass while DKIM fails alignment? A Mailgun message can pass SPF while DKIM remains misaligned because DMARC evaluates the two authenticated domains separately. Check the message's DKIM `d=` value, the MAIL FROM or Return-Path domain, and the visible From domain; our guide to [why DKIM signatures fail alignment](/learning/why-does-my-dkim-signature-fail-alignment) covers the DKIM branch. ## Frequently asked questions ### Do I need Mailgun's MX records if I only send email? No. A Mailgun send-only domain does not need its MX records pointed to Mailgun. Mailgun's [domain FAQ explicitly says to omit its MX records](https://documentation.mailgun.com/docs/mailgun/faq/faqs) when the domain sends through Mailgun but receives mail elsewhere. Add Mailgun MX records only when Mailgun should receive and route messages addressed to that domain. ### Which DKIM selector does Mailgun use? There is no single Mailgun DKIM selector. Manual DKIM may show a selector such as `mx`, while Automatic Sender Security uses `pdk1` and `pdk2` CNAMEs with account-specific targets. Treat the Mailgun DNS settings page as the source of truth and copy every hostname exactly. ### Is the tracking CNAME required? The tracking CNAME is required for Mailgun's click, open, and unsubscribe tracking, not for SPF or DKIM authentication. Publish the exact tracking hostname and target shown in the dashboard when you use those features; it does not replace either authentication record. ### I already send through other platforms. Will Mailgun's records conflict? Mailgun's records do not conflict with other sending platforms when you keep their hostnames and selectors distinct. DKIM keys can coexist when each service uses a unique selector. SPF needs one policy per hostname, which is another reason to give Mailgun its own subdomain. The pattern is the same one we walk through for [Amazon SES](/learning/how-do-i-set-up-spf-and-dkim-for-amazon-ses) and [Klaviyo](/learning/how-do-i-set-up-spf-and-dkim-for-klaviyo): one subdomain or selector per service, with the organizational domain's DMARC policy covering subdomains unless a more specific policy applies. ## Sources and further reading - [Mailgun: domain verification setup guide](https://help.mailgun.com/hc/en-us/articles/32884700912923-Domain-Verification-Setup-Guide) - [Mailgun: verify a domain](https://documentation.mailgun.com/docs/mailgun/user-manual/domains/domains-verify) - [Mailgun: DKIM key length and rotation](https://documentation.mailgun.com/docs/mailgun/user-manual/domains/dkim_security) - [Mailgun: sending and receiving domain FAQ](https://documentation.mailgun.com/docs/mailgun/faq/faqs) - [Mailgun: From domain and sending domain FAQ](https://documentation.mailgun.com/docs/mailgun/faq/sending) - [RFC 9989: DMARC identifier alignment](https://www.rfc-editor.org/rfc/rfc9989.html#section-4.4) - [RFC 7208: multiple SPF records](https://www.rfc-editor.org/rfc/rfc7208.html#section-4.5) - [Google Workspace: MX record values for Gmail](https://support.google.com/a/answer/140034), the root-domain MX records this guide warns against replacing. - [Microsoft 365: domains FAQ, including MX and mail routing](https://learn.microsoft.com/en-us/microsoft-365/admin/setup/domains-faq), the Microsoft 365 equivalent. --- # How do I set up SPF and DKIM for Postmark? Canonical: https://www.palisade.email/learning/how-do-i-set-up-spf-and-dkim-for-postmark > Postmark authenticates via its own Return-Path, so the include is unnecessary. Real setup: one DKIM TXT record plus a Return-Path CNAME for alignment. Authenticating Postmark takes one required DNS record, not three. Add the DKIM TXT record that Postmark's DNS Settings page generates for your domain, then add a custom Return-Path CNAME (`pm-bounces.yourdomain.com` pointing to `pm.mtasv.net`) so SPF aligns for DMARC. That is the whole setup. You do not need to add Postmark to your SPF record: [Postmark's own documentation](https://postmarkapp.com/support/article/how-do-i-set-up-spf-for-postmark) states that "it is no longer required to include Postmark in your own custom SPF record," because SPF is checked against the Return-Path domain, which Postmark already covers. Most third-party guides still tell you to paste `include:spf.mtasv.net` anyway. ## Quick Takeaways - DKIM is the only required record: a TXT record with a timestamped selector, generated in Sender Signatures → DNS Settings. - Postmark's default Return-Path domain is `pm.mtasv.net`, which carries Postmark's SPF record, so your mail passes SPF with zero setup. - Passing SPF is not the same as SPF *alignment*. For DMARC, add the custom Return-Path CNAME. - `include:spf.mtasv.net` on your root domain does nothing for Postmark mail. The documented exception is Apple's Private Email Relay. - Keep the SPF record for your mailbox provider (Google Workspace, Microsoft 365). That one still matters. ## What DNS records does Postmark actually need? Postmark authenticates your mail with [DKIM](/learning/what-is-dkim) and handles [SPF](/learning/what-is-spf) on its own bounce domain. Three records come up in setup conversations, but they are not equally important: ![Three DNS records for Postmark: required DKIM TXT record, recommended Return-Path CNAME to pm.mtasv.net, and optional SPF include for edge cases.](/images/figures/how-do-i-set-up-spf-and-dkim-for-postmark-fig1.webp "1200x533") *Only the DKIM TXT record is required; the Return-Path CNAME is what earns DMARC alignment.* | Record | Type | Example value | Do you need it? | |---|---|---|---| | DKIM | TXT | `v=DKIM1; k=rsa; p=<long key>` at `2023060112345pm._domainkey.yourdomain.com` | Required | | Custom Return-Path | CNAME | `pm-bounces.yourdomain.com` → `pm.mtasv.net` | Strongly recommended for DMARC | | SPF include | TXT | `v=spf1 include:spf.mtasv.net ~all` | Optional, edge cases only | The rest of this guide walks through each one, in that order. ## How do I set up DKIM for Postmark? Postmark generates a unique DKIM record per domain, with a timestamped selector. Per [Postmark's DKIM setup guide](https://postmarkapp.com/support/article/setting-up-dkim-for-your-domain), the hostname "usually follows a format like `2023060112345pm._domainkey`", so don't copy a selector from a blog post; use the exact one your dashboard issues. 1. Log in to Postmark and open **Sender Signatures** from the top menu. 2. Add your domain if it isn't there, then click **DNS Settings** next to it. 3. Copy the DKIM record: a **TXT** record with a hostname like `2023060112345pm._domainkey.yourdomain.com` and a value starting with `v=DKIM1; k=rsa; p=...`. 4. Create that TXT record at your DNS provider. Many providers append your domain automatically, so enter only the part before your domain (e.g. `2023060112345pm._domainkey`) in the host field. 5. Back on Postmark's DNS Settings page, click **Verify**. When it turns green, Postmark is signing your email with your domain's key. The record you publish looks like this: ``` Type: TXT Host: 2023060112345pm._domainkey.yourdomain.com Value: v=DKIM1; k=rsa; p=<long key from your Postmark dashboard> ``` Because the selector is unique and dated, treat each Postmark DKIM record as its own entry: it will sit alongside selectors from Google, Microsoft, or any other sender without conflict. ![Postmark sender-signature screen with the Add DKIM control.](/images/editorial/how-do-i-set-up-spf-and-dkim-for-postmark/postmark-add-dkim.png "1716x558") *Source: [Postmark Support, “How do I set up DKIM for Postmark?”](https://postmarkapp.com/support/article/1091-how-do-i-set-up-dkim-for-postmark), checked July 29, 2026. First-party public interface excerpt, unmodified.* ## Do I need to add an SPF record for Postmark? No, and this is where most Postmark guides get it wrong. Postmark [removed the SPF requirement back in 2017](https://postmarkapp.com/blog/why-we-no-longer-ask-for-spf-records) and has been explicit about it since. Here's the mechanism. Receiving servers evaluate SPF against the **Return-Path domain** (the bounce address), not the From address your recipients see. The old practice of adding every ESP to your domain's SPF record dates from SenderID, a Microsoft standard that checked the From domain, and as Postmark puts it, "SenderID is a dead standard now. SPF is still alive, so the DNS record lookup only happens on the Return-Path domain." By default, Postmark's Return-Path is its own domain, `pm.mtasv.net`, which publishes Postmark's sending IPs. That's why their docs say "your emails sent through Postmark will always pass SPF by default, without any necessary action on your end." It goes further: adding `include:spf.mtasv.net` to your root domain's SPF record is not just unnecessary, for Postmark mail, it never gets read. Postmark's [SPF FAQ](https://postmarkapp.com/support/article/1102-why-is-it-not-required-to-include-postmark-in-our-own-custom-spf-record) confirms that "email providers no longer check the From field's domain when evaluating SPF and determining the results", the lookup lands on the Return-Path domain, which with Postmark is never your root domain. So the copy-pasted include just sits there, spending one of your ten SPF DNS lookups every time a receiver evaluates your record for some other mail stream. Two honest caveats: 1. **Your mailbox provider still needs SPF.** Postmark is blunt about this: "for your main mailbox provider, and any provider who uses your domain for the Return-Path, you still very much need an SPF record." Keep `include:_spf.google.com` or `include:spf.protection.outlook.com` where they are. 2. **Apple's Private Email Relay is the documented exception.** If your app supports Sign in with Apple and emails relay addresses, [Postmark's guide](https://postmarkapp.com/support/article/1283-using-apples-private-email-relay-with-postmark) says Apple requires an SPF record, `v=spf1 include:spf.mtasv.net ~all`, plus DKIM signed by your domain and a custom Return-Path that matches it. So the question isn't "how do I add Postmark to SPF", it's "does my SPF *align* for DMARC," which the Return-Path setting controls. ![Postmark DKIM DNS settings in an Inactive state with host and value fields.](/images/editorial/how-do-i-set-up-spf-and-dkim-for-postmark/postmark-inactive-dkim-settings.png "1712x922") *Source: [Postmark Support, “How do I set up DKIM for Postmark?”](https://postmarkapp.com/support/article/1091-how-do-i-set-up-dkim-for-postmark), checked July 29, 2026. First-party public interface excerpt, unmodified.* ## How do I set up a custom Return-Path for Postmark? [DMARC](/learning/what-is-dmarc) doesn't just ask whether SPF passed; it asks whether the domain that passed matches your From domain. With Postmark's default Return-Path, SPF passes on `pm.mtasv.net`, Postmark's domain, not yours. As their [alignment FAQ](https://postmarkapp.com/support/article/1093-why-do-emails-sent-through-postmark-fail-spf-alignment) explains, "with DMARC, the Return-Path and From address must match for SPF alignment," so that pass contributes nothing to your DMARC evaluation. Your mail still passes DMARC through aligned DKIM, "DMARC only requires either SPF or DKIM to be aligned", but you're running on one rail. If a migration or a stray CMS integration breaks DKIM signing, there's no aligned SPF to catch the fall, and mail starts failing DMARC outright. Our [SPF alignment guide](/resources-post/fixing-spf-alignment-dmarc----full-guide) covers why two aligned paths beat one. ![Comparison of Postmark's default Return-Path on pm.mtasv.net versus a custom Return-Path subdomain, showing SPF alignment and DMARC outcomes.](/images/figures/how-do-i-set-up-spf-and-dkim-for-postmark-fig2.webp "1200x442") *Both pass SPF: only the custom Return-Path makes that pass count toward DMARC.* The fix is a single CNAME, per [Postmark's Return-Path guide](https://postmarkapp.com/support/article/910-how-do-i-add-a-custom-return-path): ``` Type: CNAME Host: pm-bounces.yourdomain.com Value: pm.mtasv.net ``` 1. Create the CNAME above at your DNS provider (`pm-bounces` is Postmark's default alias for the subdomain). 2. In Postmark, open **Sender Signatures** → **DNS Settings** for your domain. 3. In the **Return-Path** section, enter the alias you used in your CNAME record. Because `pm.mtasv.net` already publishes Postmark's SPF record, the CNAME inherits it: bounces still flow to Postmark, but the Return-Path is now a subdomain of *your* domain, so SPF aligns under DMARC's default relaxed mode. No TXT record to maintain, no IP lists to babysit. ## How do I verify my Postmark records? - **In Postmark:** the DNS Settings page is the source of truth, click **Verify** and look for the DKIM record to turn green. - **From a terminal:** Postmark's [troubleshooting guide](https://postmarkapp.com/support/article/1095-my-dkim-record-wont-verify) recommends `dig`, e.g. `dig 2023060112345pm._domainkey.yourdomain.com txt`, to confirm the record exists where you think it does. - **With Palisade:** run your domain through the [DKIM checker](/tools/dkim) and [DNS lookup tool](/tools/dns-lookup) to confirm the published values, then the [DMARC checker](/tools/dmarc) to confirm your policy is in place before you tighten it. Then send a real test through Postmark and read the `Authentication-Results` header: you want `dkim=pass` with your domain, and, after the Return-Path change, `spf=pass` with `pm-bounces.yourdomain.com`. ## Common issues **DKIM won't verify (stuck pending).** Two causes dominate, per Postmark's docs. First, propagation: "DNS changes might take several hours to propagate," so a just-published record can legitimately sit unverified for a while. Second, the duplicated-domain trap: some DNS providers auto-append your root domain, leaving the record at `2023060112345pm._domainkey.yourdomain.com.yourdomain.com`. Check with `dig`; if it's doubled, re-enter the host as just the selector plus `._domainkey`. **DMARC reports show SPF failing alignment on Postmark mail.** This is expected behavior on the default Return-Path, not an incident. The mail passes SPF on `pm.mtasv.net`, which can't align with your From domain. If DKIM is verified, these messages still pass DMARC. Add the custom Return-Path CNAME and the alignment failures in your [DMARC reports](/learning/why-dmarc-fails-how-to-fix-it) turn into aligned passes. **You added `include:spf.mtasv.net` but reports didn't change.** Because that include sits on your root domain and Postmark's default Return-Path never queries it. Unless you need it for Apple's Private Email Relay, remove it to reclaim the DNS lookup. The custom Return-Path is what actually moves SPF alignment. **DKIM passes but doesn't align.** If mail signs as a different domain than the From address (common after white-labeling or domain migrations), DKIM passes without helping DMARC. See [why DKIM signatures fail alignment](/learning/why-does-my-dkim-signature-fail-alignment). ## Frequently asked questions ### What is pm.mtasv.net? It's Postmark's Return-Path (bounce) domain. By default, mail sent through Postmark uses a Return-Path at `pm.mtasv.net`, which hosts Postmark's SPF record. That's how your mail passes SPF without any DNS work. It's also the CNAME target for your custom Return-Path. ### Does Postmark work with a DMARC policy of p=reject? Yes. With the DKIM record verified and a custom Return-Path in place, Postmark mail is aligned on both DKIM and SPF, and since DMARC enforcement only needs one aligned mechanism, that gives you redundancy. Verify both before tightening: a domain on [a `p=reject` policy](/learning/glossary/dmarc-p-reject) with broken DKIM and no aligned SPF will see Postmark mail rejected. ### Should I remove include:spf.mtasv.net from my existing SPF record? If you're not using Apple's Private Email Relay, it's doing nothing for Postmark mail, and every include costs one of SPF's ten DNS lookups. Keep your mailbox provider's include; drop redundant ESP includes when you're near the limit. ### Is this the same process as other email providers? The DKIM step is similar everywhere, but the SPF story is unusually honest at Postmark, most providers hand you a MAIL FROM subdomain plus TXT records instead. Compare [Amazon SES](/learning/how-do-i-set-up-spf-and-dkim-for-amazon-ses), which uses three DKIM CNAMEs and a custom MAIL FROM domain. Postmark's defaults get you delivering; the custom Return-Path gets you aligned. If you're rolling this out across client domains, [Palisade](https://www.palisade.email) monitors DMARC reports for every domain in one place and flags exactly which source is failing alignment before it becomes a deliverability ticket. --- # Why am I not receiving emails? How to troubleshoot Canonical: https://www.palisade.email/learning/why-am-i-not-receiving-emails-how-to-troubleshoot > Not receiving emails? Work through spam filters, a full mailbox, forwarding loops, MX records, and blocklists, the fixes that recover missing mail fast. If you are not receiving emails, the cause is almost always one of five things: the message was filtered to spam or a rules folder, your mailbox is full, a forwarding rule is dropping it, your domain's MX records are wrong, or the sender's server is being blocked. Work from the mailbox outward: check the spam folder and storage first, then filters and forwarding, and only then move to DNS and blocklists. Most missing mail is recovered in the first two steps. ## Quick Takeaways - Check the spam or junk folder first. Filtered mail is the single most common cause of "missing" email. - A full mailbox silently rejects new mail; free up space or raise the quota before anything else. - Inbox rules and server-side forwarding can move or delete messages before you ever see them. - Broken or missing MX records mean senders have nowhere to deliver. Verify them from outside your DNS panel. - If one specific sender can't reach you, your server may be blocking their IP or a shared blocklist is. - Greylisting delays first-time senders by design; the message usually arrives within an hour on retry. ## Is the email in spam, junk, or another folder? Start here, because filtered mail accounts for more "missing" email than every other cause combined. Open your Spam or Junk folder and search it for the sender. In Gmail, also check the Promotions and Updates tabs and search `in:anywhere` to include folders the main view hides. In Outlook, check Junk Email and the Other tab of the Focused Inbox. If you find the message there, mark it "Not spam" or "Not junk" so the provider learns the sender is safe, and add the address to your contacts or a safe-sender list. A single message in spam is filtering; a pattern of a sender's mail landing in spam usually means that sender has an authentication or reputation problem on their end, not yours. If a whole domain's mail is being filtered, ask the sender to confirm their [SPF, DKIM, and DMARC](/learning/dkim-vs-spf-difference) are passing. Misconfigured authentication is the most common reason legitimate mail gets junked. ## Is your mailbox full or over quota? A mailbox at its storage limit stops accepting new mail. Depending on the provider, the sender gets a bounce ("mailbox full" / "quota exceeded", often a 452 or 552 response) or the message is deferred and eventually returned. Either way, nothing reaches your inbox. Check your account's storage usage. On Google Workspace and Microsoft 365 the quota is shared across mail, files, and photos, so a full Drive or OneDrive can block email even when the mailbox itself looks small. Free up space by deleting large attachments and emptying Trash and Spam (deleted items often still count against quota until purged), or ask your administrator to raise the allocation. This one is easy to miss because outgoing mail keeps working normally, only inbound delivery breaks. ## Are inbox rules or forwarding hiding your mail? Filters and forwarding run automatically, so mail can be moved, archived, marked read, or deleted before you notice it arrived. Two layers are worth auditing: 1. **Client-side rules.** In Outlook, open Rules and look for anything that moves or deletes matching mail. In Gmail, open Settings → Filters and Blocked Addresses. A stale rule ("move anything from this domain to a folder") is a frequent culprit, especially one a predecessor set up on a shared account. 2. **Forwarding.** If the account forwards to another address, a broken destination or a forwarding loop can drop mail. Check Settings → Forwarding and disable or repair anything pointing somewhere unexpected. Note that forwarding also breaks SPF alignment, which is why forwarded mail sometimes fails authentication at the final destination. Also confirm the address isn't on a blocked-senders list. It is easy to block a domain by accident and then wonder why its mail vanished. ## Are your domain's MX records correct? If you run email on your own domain and *no one* can reach you, the problem is usually DNS. MX (Mail Exchanger) records tell the world which server accepts mail for your domain. If they are missing, pointing at a decommissioned host, or were overwritten during a migration, senders have nowhere to deliver and their messages bounce. Verify the records from outside your own DNS panel, since the panel can show a value that hasn't propagated. Run your domain through Palisade's [MX record lookup](/tools/mx) and confirm: - The MX hostnames match your current provider (for example `smtp.google.com` for Google Workspace, or the `mail.protection.outlook.com` host for Microsoft 365). - Each MX points at a hostname that itself resolves to an address. An MX pointing at a missing A record is a dead end. - There are no leftover MX records from a previous provider competing with the current ones. A broader [DNS lookup](/tools/dns-lookup) shows every record at once, which helps when a migration left records half-changed. If you recently changed hosts, remember that DNS changes are not instant, allow up to 24–48 hours for propagation before assuming the records are wrong. ## Is the sender being blocked or blocklisted? When only one sender or one domain can't reach you, the block is specific rather than global. A few things can cause it: - **Your server is rejecting their IP.** Business mail servers and security gateways maintain their own block rules. Check your provider's or gateway's admin console for a rejected-sender or connection log entry for that domain. - **A shared blocklist (DNSBL) lists the sender.** Many mail servers reject connections from IPs on public blocklists. If a legitimate sender lands on one (often after a malware incident or a shared-IP neighbor's spam) their mail is refused until they delist. - **Their authentication is failing your policy.** If the sender's SPF or DKIM fails and your inbound policy quarantines or rejects on failure, their mail never lands. Ask them to check their setup with an [SPF checker](/tools/spf). If you suspect reputation, check the sending IP or domain against Palisade's [domain reputation tool](/tools/domain-reputation). And if the errors are Gmail- or Yahoo-specific, our guide to [Yahoo and Gmail error codes](/learning/how-can-you-resolve-yahoo-and-gmail-email-error-codes) decodes the exact responses their servers return. ## Common issues with missing inbound email ### Mail arrives late, sometimes an hour or more This is usually greylisting. Many servers temporarily reject the first delivery attempt from an unknown sender and accept the retry a few minutes later, a cheap, effective spam filter. Legitimate servers always retry, so the mail arrives; it just looks "delayed." If a specific message is stuck rather than slow, our guide to [email stuck in the queue](/learning/why-is-my-email-queued-and-how-do-i-fix-it) covers the sender-side causes. ### Some senders get through, others don't Selective failure points at filtering or authentication, not infrastructure. If your MX records were broken, *everyone* would fail. Compare a working sender against a failing one: check whether the failing domain's mail is landing in spam, being caught by a rule, or failing your inbound authentication policy. ### You stopped receiving mail after a domain or host migration Migrations are the classic cause of a total inbound outage. The usual suspects are MX records still pointing at the old host, a lapsed DNS zone, or the new mailbox not yet provisioned. Re-run an [MX lookup](/tools/mx) and confirm every record reflects the new provider, then send a test from an outside address. ### A distribution list or shared mailbox receives nothing Shared mailboxes and groups have their own membership and delivery settings. Confirm your address is still a member, that the group accepts external mail if the sender is outside your organization, and that no moderation rule is holding messages for approval. ## Frequently asked questions ### Why can I send emails but not receive them? Sending and receiving use different paths. Outgoing mail leaves through your provider's SMTP service; incoming mail depends on your MX records, mailbox quota, and inbound filters. When sending works but receiving doesn't, the problem is almost always on the receiving side (a full mailbox, a filter or forwarding rule, or broken MX records) not your connection. ### How do I test whether my email is being delivered at all? Send a message from a completely separate account (a personal address on another provider) and watch what happens. If it bounces, read the bounce text: it names the reason, such as "mailbox full" or "no such user." If it silently disappears, the cause is filtering or forwarding on your side. Checking your domain's records with a [DNS lookup](/tools/dns-lookup) rules out an infrastructure problem quickly. ### Could my antivirus or security software be blocking email? Yes. Desktop antivirus suites and email security gateways can quarantine messages before they reach your inbox, especially ones with attachments. Check the quarantine or held-messages area of whatever security product sits in front of your mailbox, and release any legitimate mail found there. ### Does DMARC ever cause me to lose incoming mail? DMARC governs how *your* domain's outbound mail is authenticated, but if your inbound gateway enforces senders' DMARC policies, a sender publishing `p=reject` whose mail fails authentication will be refused. That is the sender's misconfiguration to fix, not yours. You can confirm your own domain's policy with Palisade's [DMARC checker](/tools/dmarc). Palisade automates the authentication side of this problem for MSPs and their clients: it monitors SPF, DKIM, and DMARC across every domain you manage, flags the misconfigurations that quietly send legitimate mail to spam, and turns raw DMARC reports into plain-language fixes. Run any domain through the free [Email Security Score](/tools/email-security-score) to see where it stands in about a minute. ## Related reading - [Why is my email queued and how do I fix it?](/learning/why-is-my-email-queued-and-how-do-i-fix-it) - [Why is Gmail rejecting my emails with a 550 error?](/learning/smtp-error-codes/550-5-7-26) - [How can you check and improve your email domain reputation?](/learning/how-can-you-check-and-improve-your-email-domain-reputation) --- # What are rogue apps and how can I stop them? Canonical: https://www.palisade.email/learning/whatarerogueappshowcanistop > Rogue apps are malicious OAuth apps that bypass MFA via consent phishing. How MSPs detect, remove, and prevent illicit consent grants in Microsoft 365 and "Rogue app" is the plain-English name for a malicious OAuth application, an app an attacker registers and tricks a user into granting access to. Microsoft calls this an *illicit consent grant*; the attack that plants it is *consent phishing*. What makes it dangerous is that it sidesteps the defenses you already trust: once a user clicks "Accept," the app has account-level access to their mail and files, and resetting the password or turning on MFA does not remove it. ## Quick takeaways - A rogue app is a malicious OAuth application. The user *willingly* grants it access on a real Microsoft or Google consent screen, so no password is ever stolen. - Microsoft states plainly that password resets and MFA do **not** remediate this attack, because the app is external to your tenant. That is why rogue apps "bypass MFA" and persist. - Detection lives in the audit log: search Microsoft Purview / Defender for **"Consent to application"** events. Microsoft advises reviewing consent grants weekly if you run many apps and users. - The entry point is almost always an account without MFA. In Microsoft's 2022 spam case, the compromised admin accounts had no MFA; Midnight Blizzard (APT29) got in through a legacy test account with no MFA. - This is an identity-console problem, not a DNS one. DMARC, SPF, and DKIM do not stop consent phishing, but strong email-security posture is what keeps the account-compromise door shut in the first place. ## What exactly is a rogue app? In an illicit consent grant attack, an attacker registers an app in Microsoft Entra ID that requests access to data like contacts, email, or documents. They then use phishing (or malicious code injected into a trusted site) to drive a user to the app's consent screen and get them to approve it. Because the Microsoft identity platform hosts that consent screen and lists the requested permissions, it looks completely legitimate, and unsuspecting users accept (per Microsoft Entra ID docs). The moment consent is granted, the app holds a token that lets it act on the user's data, without ever needing an account in your organization. That external position is the whole problem. As Microsoft spells out, normal remediation like resetting passwords or requiring MFA is not effective here, because those controls protect *accounts*, and the malicious app is not an account. Microsoft, Google, and CISA don't use the term "rogue app": their language is "illicit consent grant," "consent phishing," and "malicious OAuth application." Treat "rogue app" as a useful umbrella, not an official technical term. ## Why do rogue apps bypass MFA and passwords? Consent phishing bypasses authentication entirely. Credential phishing tries to steal a password; consent phishing skips that step and asks the user to *authorize an app*. The user is fully authenticated (they log in normally, MFA and all) and then hand a third-party app a durable OAuth token. Nothing about that flow is "wrong" from the login system's point of view. That is also why rogue apps are such good persistence. In Microsoft's September 2022 spam campaign, attackers credential-stuffed into Azure AD accounts that lacked MFA, registered a malicious OAuth app, gave it the `Exchange.ManageAsApp` permission, added their own credentials to it, and used it to create transport rules that sent spam. In some cases they didn't even reuse the app for weeks or months after planting it. In the Midnight Blizzard (APT29) intrusion disclosed in January 2024, the actor compromised a legacy OAuth app, created more malicious apps, and granted itself the Exchange Online `full_access_as_app` role to read mailboxes, retaining access even after losing the original account. The common thread in both: the initially compromised account had no MFA. ## How do I detect rogue apps in Microsoft 365? Start in the audit log. In the Microsoft Defender portal (security.microsoft.com), open **Audit** and search for **"Consent to application"** activities. Those events are your primary indicator of compromise. Microsoft recommends reviewing consent grants **weekly** in tenants with many registered apps and a large user base. To inventory what's already been consented to, you have three options (per Microsoft Learn): - **Entra admin center:** Identity → Users → All users → pick a user → Applications, to see per-user app access. - **Self-service:** have users check **myapps.microsoft.com**, where they can view and revoke their own app access. - **PowerShell**: the fastest method. Microsoft references a community script, `Get-AzureADPSPermissions.ps1`, run through the Microsoft Graph PowerShell SDK (`Connect-MgGraph`), to dump every OAuth consent grant and app across all users into a single CSV. (The filename references the retired AzureAD module, but the current doc runs it via Graph.) When you review the output, scrutinize apps with the **`AllPrincipals`** consent type (access to *everyone's* content), broad **Read/Write.All** permissions, and suspicious client display names. CISA's AA21-008A advisory adds more signals: audit the creation and use of service-principal credentials, watch for dormant apps, and flag credentials that allow non-interactive sign-in. CISA's free **Sparrow** tool checks OAuth consent and Graph API permissions across your service principals and apps. ## How do I remove a rogue app? Per Microsoft, you have several remediation moves. Use more than one: - **Revoke in Entra:** user → Applications → select the app → **Remove**. - **Revoke the consent grant in PowerShell:** `Remove-MgOauth2PermissionGrant`. - **Revoke a service app role assignment:** `Remove-MgServicePrincipalAppRoleAssignment`. - **Disable sign-in** for the affected account as a short-term containment step. Note that when Microsoft itself confirms an app violates its terms, Entra ID disables it across all Microsoft services; it shows `DisabledDueToViolationOfServicesAgreement` and cannot be deleted (so it can't be re-instantiated), and a Privileged Role Administrator is emailed if anyone had already consented. ## How do I prevent rogue apps? Prevention is a consent-policy problem. Microsoft recommends configuring **user consent settings** so users can only consent to apps that meet criteria you set: for example, apps from your own organization or from **verified publishers**, and only for low-risk permissions you choose. Publisher Verification is Microsoft's vetting process for confirming a developer's authenticity; even then, review the requested permissions, because a verified publisher is not a blank check. Do not let users lean on app names or domain URLs as proof of authenticity, Microsoft warns that attackers spoof both to look legitimate. For deeper coverage, Microsoft points to **Defender for Cloud Apps** OAuth app policies and app governance to detect and remediate risky apps, plus **Defender for Office 365** to block consent-phishing emails before they land. On **Google Workspace**, the equivalent control lives under **Security → Access and data control → API controls → App access control**. Each app can be **Trusted** (all scopes, including restricted services), **Limited** (unrestricted Google services only), or **Blocked** (no access at all). You can restrict specific services like Gmail or Drive so an app can't be added unless you've explicitly trusted it. Google also restricts unverified apps that access Gmail data and have more than 100 users worldwide. New installs of those are blocked unless an admin trusts the app. ## Where does Palisade fit? Palisade does **not** scan Entra or Workspace OAuth grants or remediate rogue apps. That work happens in the Microsoft and Google admin consoles above. What Palisade addresses is the entry point. Every one of these cases started with a compromised email account, and rogue apps are one more reason to keep your email-security posture tight: enforced MFA, clean authentication, and no unmonitored mailboxes. Think of it as layered defense: [Hosted DMARC](/tools/dmarc) and the free [tools](/tools/email-security-score) harden the account and the domain, while OAuth governance closes the consent path. ## Frequently asked questions ### Do DMARC, SPF, or DKIM stop rogue apps? No. Consent phishing bypasses authentication entirely: the user willingly grants OAuth scopes, and Microsoft says MFA and password resets don't remediate it. Email authentication is part of a layered posture, not a fix for this attack. ### Will resetting the user's password fix it? No. Microsoft is explicit that password resets and MFA don't remove an illicit consent grant, because the app is external to your organization. You have to revoke the app's consent or permissions directly. ### How often should we review OAuth consents? Microsoft recommends **weekly** reviews of consent grants for organizations with many registered apps and a large user base. Searching "Consent to application" in the audit log is the fastest recurring check. ### What's the single biggest risk factor? Accounts without MFA. In Microsoft's 2022 spam case the compromised admin accounts lacked MFA, and Midnight Blizzard entered through a no-MFA legacy test account. MFA doesn't remediate a planted rogue app, but it blocks the compromise that plants one. ### Is this only a Microsoft problem? No. Google Workspace has the same OAuth exposure, managed through App access control (Trusted / Limited / Blocked). Any platform that supports OAuth consent can host a rogue app. Want to check your account and domain security posture first? Run the free [Email Security Score](/tools/email-security-score): it reviews your DMARC, SPF, and DKIM setup in seconds. ## Related reading - [DMARC checker](/tools/dmarc) - [Email Security Score](/tools/email-security-score) - [Microsoft compliance checker](/tools/microsoft-compliance-checker) - [Palisade for Managed Service Providers](/for-managed-service-providers) --- # How does sandboxing help stop malware? Canonical: https://www.palisade.email/learning/how-does-sandboxing-help-stop-malware > FAQ: sandboxing basics, how it works, benefits, and where to use it in security stacks. Sandboxing isolates suspicious files or programs inside a disposable, controlled environment so they cannot damage real systems or networks. The file is allowed to run and its behavior is watched: what it writes to disk, which processes it starts, which domains it contacts. If it acts maliciously, the sandbox is destroyed along with it, and the verdict feeds alerts, automated playbooks, or a manual investigation. This catches malware that signature scanning misses, including newly built samples with no known hash. ![sandboxing illustration](/images/cms/68e1ecfca1091924281c7649_img-az6qsgp880u3uv899fuyn6cz.png) ## Common questions about sandboxing ### 1. What is a sandbox in cybersecurity? A sandbox is a controlled, isolated environment where unknown files or code run without access to production systems. Security teams use sandboxes to observe behavior, like file changes or network calls, without risk to users. Sandboxes can be full virtual machines, lightweight containers, or cloud-hosted environments, depending on the use case. They capture detailed telemetry (process actions, registry edits, and outbound connections) that help analysts decide if a sample is malicious. The isolation and detailed logs make sandboxes a powerful tool against evasive and unknown threats. ### 2. How does sandboxing detect malware? Sandboxing detects malware by executing suspicious samples and watching for risky behavior patterns. Instead of relying on signatures, sandboxes look for actions such as encryption routines, new service installs, or suspicious network traffic. They then correlate those behaviors with known indicators to flag threats like ransomware or remote access trojans. Because they test behavior, sandboxes can pick up zero-day exploits and polymorphic malware variants that signature-based tools miss. Results feed into alerts, automated playbooks, or manual investigations. ### 3. Where are sandboxes used in a security stack? Sandboxes are commonly integrated into email gateways, web filtering, and endpoint protection platforms. Email gateways send attachments and links to sandboxes to check for phishing payloads before delivery. Web proxies or secure browsing platforms route downloads to sandboxes to stop drive-by downloads. Endpoint protection and EDR solutions also use sandboxes to analyze quarantined files. This distributed use ensures multiple layers can catch threats at different stages. ### 4. Can sandboxing stop zero-day attacks? Sandboxing greatly improves detection of zero-day attacks because it focuses on behavior, not signatures. By executing unknown code, sandboxes reveal malicious actions that signature-based tools wouldn’t recognize. That said, no single control guarantees 100% protection (attackers can use sandbox evasion techniques) but sandboxing reduces the window of exposure and increases the chance of early detection. Combining sandboxing with EDR, threat intelligence, and patching gives better coverage. ### 5. Do sandboxes affect system performance? Sandboxes generally do not slow down end-user devices because they run in separate environments like cloud-hosted VMs or dedicated servers. Analysis happens outside the user’s machine, which prevents performance impact during normal work. Some local sandbox implementations can consume host resources, but most enterprise deployments are designed for scalability. Administrators can tune analysis depth and retention to balance detection fidelity and performance. ### 6. Are there different types of sandboxes? Yes: common types include full virtual machine sandboxes, container-based sandboxes, and cloud-hosted analysis platforms. Full VMs emulate entire operating systems for high-fidelity analysis, while containers offer faster spin-up and lower resource use. Cloud sandboxes scale easily and integrate with email gateways or web proxies. There are also specialized sandboxes for mobile apps, macros, or browser-based threats. ### 7. Can sophisticated malware avoid sandboxes? Sophisticated malware sometimes uses sandbox-detection tricks: delaying execution, checking for virtualization artifacts, or requiring human input to trigger malicious behavior. These evasion methods can reduce a sandbox’s visibility into the malicious activity. Defenders counter with longer observation windows, simulated user interactions, and environment obfuscation to make the sandbox appear more like a real endpoint. No defense is perfect, but layered controls make evasion more costly and less reliable. ### 8. How do analysts use sandbox reports? Analysts review sandbox reports to find indicators of compromise (IOCs), determine the scope of an incident, and prioritize responses. Reports include file hashes, network destinations, modified files, and registry changes. Details that help map attacker activity. That telemetry feeds into SIEM, EDR, and SOAR tools for automated containment or manual investigation. Clear reports speed up triage and reduce false positives in broader security operations. ### 9. Is sandboxing suitable for small businesses? Yes: sandboxing is accessible to smaller organizations through cloud-based or managed services that minimize setup and cost. Many security vendors offer sandbox analysis as an integrated feature within email security or endpoint protection packages. For small teams, managed sandboxes provide expert tuning and reporting without heavy infrastructure. Even basic sandboxing adds a meaningful detection layer against phishing and malicious attachments. ### 10. What are the limitations of sandboxing? Sandboxing can miss threats that are well-crafted to hide in analysis environments or that require long trigger conditions. Resource constraints and analysis timeouts can also limit detection fidelity. Integration gaps and alert volume may overwhelm teams without automation. Despite these limits, sandboxing remains a high-value control when combined with complementary security layers like EDR, threat intelligence, and robust patching. ### 11. How is sandboxing different from antivirus? Sandboxing is behavior-focused: it runs unknown files to observe what they do, while antivirus typically matches files against known signatures. That means sandboxes can detect novel threats and attack techniques that signature-based tools miss. Antivirus is still useful for blocking known malware quickly, so the two work best together. Sandboxing provides richer forensic data and helps security teams understand novel threats for broader defenses. ### 12. How should teams deploy sandboxing effectively? Deploy sandboxing where suspicious content first enters your environment: email, web downloads, and third-party file shares. Integrate sandbox outputs with EDR and SOAR to automate containment and reduce manual workload. Tune analysis settings (observation time, simulated user actions, and telemetry collection) to match your threat model. Regularly review sandbox detections and update rules to keep pace with evolving attacker techniques. ## Quick Takeaways - Sandboxing runs suspicious code in isolated environments to prevent harm. - It detects threats by behavior, not only by signatures, so it finds unknown attacks. - Common deployments include email scanning, web filtering, and endpoint analysis. - Attackers may attempt sandbox evasion; defenders counter with longer analysis and simulation. - Cloud sandboxes scale for SMBs and enterprises alike. - Sandbox results feed EDR, SIEM, and SOAR for faster response. ## FAQs ### Q: Will sandboxing replace antivirus? A: No: sandboxing complements antivirus by catching unknown or behavior-based threats that signature scans miss. Both should be part of a layered defense strategy. ### Q: How long does sandbox analysis take? A: Analysis typically takes seconds to minutes, but longer observation windows increase the chance of catching delayed or stealthy behavior. Administrators choose timeouts that balance speed and detection depth. ### Q: Can sandboxes analyze email links as well as attachments? A: Yes: modern sandboxes can follow redirected links and render web content to detect malicious pages and drive-by downloads. Integration with email gateways and web proxies enables link scanning before users click. ### Q: Do sandboxes store my data? A: Sandboxes record telemetry about the sample’s behavior, not personal user data. Choose trusted vendors and review data retention policies to meet compliance needs. ### Q: Where can I learn more about sandboxing tools? A: Find additional resources and testing options at [Palisade](/), which offers tools and guidance for email and endpoint security. ## Related reading - [How does SOA influence cybersecurity in modern enterprises?](/learning/threats) - [How does system development ensure cybersecurity?](/learning/threats) - [How is AI reshaping cybersecurity for MSPs?](/learning/msp) --- # How fast should your team respond to incidents (MTTR)? Canonical: https://www.palisade.email/learning/how-quickly-should-your-security-team-respond-to-incidents-mttr-explained > A concise guide to Mean Time to Respond (MTTR) in cybersecurity: definition, calculation, and tactics to lower response times. ## Quick summary Mean Time to Respond (MTTR) measures how long it takes a security team to start and complete actions that contain and remediate a cybersecurity incident. Shorter MTTR means less damage and lower recovery costs; tracking it helps teams get faster over time. ![MTTR illustration](/images/cms/68e19b227c044f5a306ef14c_img-cnzvtitgvxckodz9fe3cdudd.png) ## 1. What is MTTR and why should I care? MTTR is the average elapsed time to detect, respond to, and resolve a security incident depending on the definition you use. It’s important because a faster response reduces the window attackers have to move laterally, exfiltrate data, or cause system outages. Organizations that lower MTTR typically face fewer lost records and lower remediation costs. For security leaders, MTTR is a direct indicator of operational maturity and tooling effectiveness. Track it to prioritize investments and prove improvements. ## 2. How do I calculate MTTR? Calculate MTTR by summing the response durations for all incidents in a set period, then divide by the incident count. Define your start and end points consistently (for example, from alert receipt to full remediation) so comparisons are meaningful. Use a monthly cadence to spot trends quickly or quarterly for broader strategy shifts. If incidents vary widely, report median and mean to avoid skew from outliers. Automate collection with your logging and ticketing systems where possible. ## 3. What start and end points should I use? The most useful start point is when your team receives a clear notification or confirms a malicious event. End points can be when systems are restored, when the immediate threat is neutralized, or when documentation and follow-up are completed. Choose one and stick with it. Different teams publish different MTTR variants; be explicit about which you report. Consistency is more valuable than perfection for trend analysis. Document the definition in your incident response plan. ## 4. What MTTR types should I track? There are several related metrics that help different roles make decisions: Mean Time to Respond (alert to action), Mean Time to Repair (hands-on remediation time), Mean Time to Recover (full restoration), and Mean Time to Resolve (detection to closure). Each highlights a separate phase of incident handling and points to different improvements. Security operations may focus on response and repair while leadership watches recovery and resolution. Report multiple MTTRs to capture the full lifecycle. ## 5. Why faster MTTR matters Faster responses limit attacker dwell time, reduce data exposure, and lower service downtime. Research from major security organizations shows that every hour saved in containment can cut overall breach costs substantially. Quick MTTR also protects reputation and customer trust by reducing the scale of an incident. Internally, it signals well-tuned processes and precise detection. Use MTTR reductions as a core KPI for operations teams. ## 6. Common obstacles to lowering MTTR Teams often struggle with alert fatigue, incomplete telemetry, and staffing gaps that slow response. Too many low-quality alerts overwhelm analysts and push real threats down the queue. Data scattered across endpoints, cloud services, and logs delays investigations. Budget or hiring limits can keep teams understaffed during peak events. Complex environments with diverse platforms also increase remedial work. ## 7. Practical steps to reduce MTTR Start by tuning detections to reduce false positives and improve signal-to-noise. Automate repetitive containment actions with playbooks so analysts can focus on harder problems. Conduct regular tabletop exercises and post-incident reviews to refine runbooks. Improve telemetry and centralize logs to speed investigations. Finally, monitor MTTR alongside related metrics to measure progress. ## 8. Tools and automation that help Security orchestration and automated response platforms (SOAR) and centralized logging speed containment and diagnostics. Endpoint detection tools and managed detection providers can shorten detection and response windows. Integrate ticketing systems so alerts create incident records automatically and track times without manual effort. Automation should be applied conservatively. Use it for routine tasks while keeping humans in the loop for judgement calls. Consider external partners when internal coverage is limited. ## 9. How to set realistic MTTR targets Set targets by incident severity: trivial issues may accept hours, whereas critical breaches often need initial containment in 15–60 minutes. Benchmark against peers in your industry and adjust for your environment’s complexity. Start with achievable goals and tighten them as tooling and staff improve. Use SLAs and runbooks that reflect these tiers so responders know expectations. Measure performance and revise targets every quarter. ## 10. Using MTTR for resource planning MTTR trends reveal gaps in staffing, tooling, or runbooks and guide investment decisions. If MTTR stays high despite process changes, consider additional analysts or vendor support. Use MTTR to justify purchases like advanced detection software or managed services. Pair MTTR data with cost analysis to show expected return on security spending. This makes business cases for investment tangible to executives. ## 11. Measuring success beyond MTTR MTTR is essential but incomplete; combine it with metrics like incident volume, recurrence rate, and time-to-detect for a fuller view. Track the proportion of incidents resolved by automation to measure operational leverage. Monitor the number and severity of repeat incidents to spot systemic issues. Use post-incident lessons to reduce both future incidents and response times. Dashboards that combine these indicators give leaders a clear picture. ## 12. Where to learn more and get help For practical tools and templates, check resources from Palisade and explore incident response guides on https://palisade.email/. Palisade can help with detection tuning, automation playbooks, and response services to reduce MTTR. Start with a gap assessment to find the highest-impact improvements. Regular testing and documentation will keep gains durable as systems evolve. ## Quick Takeaways - MTTR measures the average time from detection/notification to remediation. Shorter is better. - Be explicit about start/end definitions so your MTTR is consistent. - Track multiple MTTR types (respond, repair, recover, resolve) for a complete picture. - Tune alerts, centralize telemetry, and automate routine actions to cut response time. - Use MTTR trends to justify staffing and tooling investments. - Benchmark and set severity-based targets (e.g., 15–60 minutes for critical incidents). ## Frequently Asked Questions ### What’s the difference between MTTR and mean time to detect? MTTR focuses on how long it takes to act and fix an incident, while mean time to detect (MTTD) measures how long it takes to discover a problem. Both matter: faster detection plus faster response gives the best outcomes. Improving telemetry lowers MTTD; improving playbooks and automation lowers MTTR. Report both to leadership for balanced visibility. ### How often should I calculate MTTR? Calculate MTTR monthly to spot trends and quarterly for strategic reporting. Monthly figures show operational shifts quickly; quarterly numbers smooth short-term variability. Use both frequencies if you can. Align reporting cadence with your incident volume and business rhythms. ### Can automation make MTTR worse? Poorly designed automation can create mistakes or excessive blocking, but well-scoped playbooks usually lower MTTR. Test automations in staging and start with low-risk actions like isolating a host or blocking an IP. Monitor automated outcomes and maintain human review for critical decisions. Iterate to keep automation effective and safe. ### Is a single MTTR target realistic for all incidents? No: incidents vary in severity and complexity, so a single target is misleading. Use tiered targets tied to severity levels and system criticality. That approach gives responders clear expectations and helps prioritize resources. Communicate these tiers in your incident response documentation. ### How do I prove MTTR improvements to executives? Show side-by-side dashboards of MTTR, incident volume, and containment costs before and after changes. Use specific examples where faster response reduced impact and quote estimated savings. Pair quantitative dashboards with brief post-incident summaries that explain the operational changes made. This combination makes improvements concrete for non-technical stakeholders. ## Related reading - [How should organizations apply the principle of least privilege?](/learning/threats) - [How should organizations handle log retention?](/learning/threats) - [How should organizations protect data privacy in cybersecurity?](/learning/threats) --- # How does malspam work, and how can organizations stop it? Canonical: https://www.palisade.email/learning/how-does-malspam-work-and-how-to-stop-it > What malspam is, how attackers use spam to deliver malware, and the defensive steps IT teams can take today: filtering, authentication, and training. ## Introduction Email is still the number-one vector attackers use to deliver malware; malspam is the malicious subset of those messages. This guide answers common operational questions IT teams ask about malspam and gives practical steps to reduce risk. ### What is malspam? Malspam is unsolicited email crafted to deliver harmful software or to trick recipients into exposing credentials. These messages usually include attachments, links to malicious sites, or embedded scripts that execute when opened. Attackers often disguise malspam as invoices, delivery notices, or internal messages to increase trust. Campaigns range from broadly distributed blasts to targeted spear-phishing aimed at high-value users. Malspam is a primary entry point for ransomware, credential theft, and remote-access tools. ### How does malspam reach users? Malspam travels over standard email channels and leverages social engineering to prompt interaction. Adversaries harvest addresses from public sources, buy lists, or compromise accounts to send from trusted senders. They exploit events (like tax season or urgent notices) to increase click-through rates. Many campaigns use URL shorteners, lookalike domains, or compromised websites to hide malicious hosting. A single user action (opening an attachment or following a link) can start the infection chain. ### What types of malware do attackers deliver via malspam? Malspam commonly pushes malware in the form of ransomware, credential stealers, remote access trojans (RATs), and banking trojans. Ransomware encrypts files and demands payment; credential stealers harvest logins for later abuse. RATs give attackers persistent, remote control of infected hosts. Many campaigns combine payloads: a dropper installs a loader, which then fetches the final malware. The exact family changes quickly, but the delivery pattern remains consistent, which is why no single product stops ransomware on its own. ### How do attackers craft convincing malspam? Attackers design messages that mimic real organizations and exploit human responses like fear or curiosity. They use logos, familiar wording, and spoofed reply addresses to appear legitimate. Targeted campaigns ([spear-phishing](/learning/what-is-spear-phishing)) include personal details to increase credibility. Social engineering techniques include creating urgency, referencing recent events, or forging internal processes. Sophisticated actors test messages and iterate based on which variants succeed — the same playbook behind broader [phishing](/learning/what-is-phishing) and [business email compromise](/learning/business-email-compromise-vs-phishing) campaigns. ### How serious is the risk from malspam? Malspam is extremely dangerous because it requires only one user mistake to trigger a breach. Past incidents show a single email can lead to multi-million-dollar disruptions and data loss. Malware delivered by malspam can move laterally, escalate privileges, and exfiltrate sensitive information. Small businesses and enterprises alike have been locked out of systems due to malspam-enabled ransomware. The scale and frequency of these campaigns keep defense teams busy. ### What signs indicate a malspam email? Common red flags include unexpected attachments, mismatched sender domains, and urgent calls to action. Poor grammar, generic greetings, or requests for credentials are also suspicious. Hovering over links to reveal their true destination often exposes misleading URLs. Unusual sender behavior (like an external address claiming to be internal) should trigger verification. When in doubt, validate the message via a separate communication channel before interacting. ### What technical controls reduce malspam risk? Layered email defenses cut the probability of malicious mail reaching users. Implement these controls: spam filtering with heuristic and reputation checks, URL rewrites and [attachment sandboxing](/learning/how-does-sandboxing-help-stop-malware), attachment sanitization, and enforced [DMARC](/tools/dmarc)/[DKIM](/tools/dkim)/[SPF](/tools/spf) records. Authentication does not scan a payload, but it blocks the spoofed-sender lure that most malspam relies on, so enforcing it removes an entire delivery technique. Endpoint protection that detects suspicious behaviors and network segmentation to limit lateral movement are also essential. Regularly review and tune filters, and subscribe to threat intelligence feeds to block known indicators. To see where a domain's authentication currently stands, run it through the [Email Security Score](/tools/email-security-score). ### How should incident responders handle malspam infections? Responders should assume compromise and act quickly to contain and eradicate the threat. Isolate affected endpoints, preserve volatile logs, and collect indicators of compromise (IOCs) such as file hashes and malicious domains. Reset credentials for impacted accounts and perform lateral movement checks across the environment. Restore from verified backups only after ensuring the threat is removed. Post-incident, perform root-cause analysis and adjust controls to prevent recurrence. If the trigger was a user following a link rather than opening an attachment, the [steps to take after a phishing-link click](/resources-post/what-to-do-if-you-clicked-on-a-phishing-link) apply in parallel. ### How can security teams improve user awareness? Frequent, realistic training reduces click rates and exposes risky behaviors. Phishing simulations tailored to your organization spotlight high-risk groups and provide measurable results. Use short, targeted training after simulation failures and reward users who report suspected phishing. Combine awareness with easy reporting paths: an "Report Phish" button in mail clients accelerates response. Metrics from these programs should feed into control tuning and policy updates. ### How do attackers bypass filters? Attackers evade filters through obfuscation, compromised legitimate services, and gradual low-volume campaigns. Techniques include embedding malware in encrypted archives, using cloud storage links, or rotating senders and domains. Some actors weaponize trusted email threads by replying with malicious content (thread hijacking). To counter this, defenses must inspect content in multiple layers and monitor sender behavior over time. Continuous tuning and threat intelligence are essential to stay ahead. ### What trends shape the future of malspam? Expect more targeted campaigns, abuse of AI-generated lures, and increased use of legitimate platforms for payload hosting. Automation helps attackers craft plausible messages at scale, while supply-chain compromises provide new distribution paths. Defenders will need behavioral detection and signal-sharing to keep up with agile adversaries. Zero-trust email practices and stronger authentication will play larger roles. Staying proactive (rather than reactive) will be the differentiator for security teams. ## Quick Takeaways - Malspam is email designed to deliver malware or steal credentials; a single click can cause a breach. - Common payloads include ransomware, RATs, and credential stealers; campaigns can be broad or targeted. - Defend with layered controls: spam filters, sandboxing, attachment rules, and strong authentication. - User training plus easy reporting reduces successful clicks and speeds incident detection. - Incident response should isolate, collect IOCs, reset credentials, and validate backups before recovery. ## Common issues stopping malspam Even a layered program leaves gaps. These are the failures IT teams hit most often, with the fix for each. ### Malspam still lands despite spam filtering A tuned filter reduces volume but never reaches zero, because attackers rotate senders, domains, and low-volume sends to stay under reputation thresholds. Do not treat a delivered message as a filter failure alone. Add a fast user-reporting path so delivered lures are triaged quickly, and enforce [DMARC](/tools/dmarc) at a reject or quarantine policy so the spoofed-sender variants are refused before content scanning even matters. ### An authenticated domain is still spoofed in malspam DMARC only protects the domains you publish policy for. Attackers pivot to lookalike domains and cousin domains you do not own, which pass their own authentication. Widen the defense to display-name and lookalike detection, train users to check the full sending domain, and monitor [DMARC aggregate reports](/tools/dmarc) for unexpected sources on the domains you do control. ### Encrypted or password-protected attachments bypass sandboxing A sandbox cannot detonate a payload it cannot open, so malspam increasingly ships malware inside password-protected archives with the password in the message body. Configure mail flow to quarantine or strip encrypted archives from untrusted senders, and route them for manual review rather than delivering them unopened. ### Users disable or ignore warning banners External-sender and suspicious-link banners lose their effect when every message carries them. Reserve banners for genuinely higher-risk conditions, pair them with a one-click report button, and reinforce with targeted training after simulation failures so the warning still signals something when it appears. ## Frequently Asked Questions ### How is malspam different from regular spam? Malspam is designed to harm, regular spam mostly advertises or annoys. Malspam contains payloads or links that lead to exploitation. The intent and technical mechanisms distinguish it from harmless bulk mail. While both may be unsolicited, malspam's goal is compromise rather than promotion. Filtering approaches therefore prioritize different detection signals. ### Can antivirus stop all malspam threats? No: signature-based antivirus alone is insufficient against modern malspam. Many threats use zero-day exploits, obfuscation, or living-off-the-land techniques that bypass signatures. Combining endpoint detection, behavioral analytics, and network controls improves detection rates. Sandboxing suspicious attachments and isolating new behaviors are effective complements. Defense in depth is the practical approach. ### What immediate steps should I take if a user clicked a malspam link? Contain the potential spread: disconnect the device from the network and change any exposed credentials. Collect logs and indicators (URLs, file names, hashes) for analysis. Scan the environment for related activity and reset passwords for accounts accessed. If you suspect ransom or data exfiltration, engage legal and cyber-insurance contacts as needed. Then perform a forensic review before restoring services. ### How often should email security settings be reviewed? Review email controls at least quarterly or when new threats emerge. Tune spam rules, update blocklists, and validate DMARC/DKIM/SPF policies regularly. After incidents or simulation results, perform immediate reviews to close gaps. Continuous monitoring combined with periodic review balances stability and responsiveness. Automate what you can to reduce manual drift. ### Where can I learn more about hardened email controls? Start with best-practice guides and threat intelligence feeds that focus on email vectors. Practical resources include vendor whitepapers and community-run abuse lists, plus the related explainers on [phishing](/learning/what-is-phishing), malware, and [anti-phishing software](/learning/anti-phishing-software). Implementing layered email defenses and user reporting procedures will yield the most immediate risk reduction. ## Related reading - [What is phishing?](/learning/what-is-phishing) - [What to do if you clicked on a phishing link](/resources-post/what-to-do-if-you-clicked-on-a-phishing-link) - [How does sandboxing help stop malware?](/learning/how-does-sandboxing-help-stop-malware) --- # How does POP3 work and why should security teams care? Canonical: https://www.palisade.email/learning/howdoespop3workandwhyshouldsecurityteamscare > How POP3 works step by step, why its download-and-delete model creates security gaps, and how MSPs can lock down or retire legacy mail clients. POP3 (Post Office Protocol version 3) is the protocol old-school email clients use to pull messages down from a mail server, defined in [RFC 1939](https://datatracker.ietf.org/doc/html/rfc1939) in 1996. A client connects, logs in with a username and password, downloads the mail, and in the classic setup deletes the server copy. Security teams should care for three reasons: mail ends up scattered across endpoints where it is hard to protect and preserve, POP3 grew up on password-only logins that dodge MFA, and deleted server copies punch holes in retention and incident response. Microsoft and Google have both shut off basic authentication for POP3, which tells you where this protocol is heading. ## What is POP3? POP3 is one of the two standard ways an email client retrieves mail from a server. It was published as [RFC 1939](https://datatracker.ietf.org/doc/html/rfc1939) (Internet Standard 53) in May 1996 and designed for the dial-up era: connect briefly, pull everything down, then read offline. The protocol only handles retrieval. Sending is a separate job that belongs to [SMTP](/learning/what-is-smtp), and the modern multi-device alternative for reading mail is [IMAP](/learning/smtp-vs-imap-vs-pop3-whats-the-difference). Because it is so simple, POP3 support is baked into nearly every desktop client ever shipped, plus plenty of scanners, ticketing systems, and line-of-business apps that poll a mailbox. That install base is why MSPs still trip over it in 2026. For the short primer version, see [What is POP3?](/learning/smtp-vs-imap-vs-pop3-whats-the-difference) ## How does a POP3 session work step by step? RFC 1939 defines three session states: AUTHORIZATION (log in), TRANSACTION (list and fetch mail), and UPDATE (apply deletions and hang up). A typical session looks like this: ```text S: +OK POP3 server ready C: USER alice@example.com S: +OK C: PASS ******** S: +OK maildrop has 2 messages (620 octets) C: LIST S: +OK 2 messages (620 octets) C: RETR 1 S: +OK 320 octets S: <message content> C: DELE 1 S: +OK message 1 deleted C: QUIT S: +OK POP3 server signing off ``` Three details in that flow matter for security work: 1. **Authentication is a plain USER/PASS pair.** The base protocol sends static credentials at the start of every session. Optional mechanisms (APOP, SASL) exist, but the lowest common denominator is a reusable password. 2. **DELE only marks messages.** Nothing is removed until the client sends QUIT and the server enters the UPDATE state, where it deletes everything marked. A dropped connection leaves the mailbox intact, which is why deleted mail sometimes reappears. 3. **"Leave a copy on the server" is a client setting, not the default model.** Clients that offer it use the optional UIDL command to remember which messages they already fetched. If that box is unticked, the server copy is gone the moment the download finishes. ## What ports does POP3 use, and which should you allow? | Port | What it is | Recommendation | | --- | --- | --- | | 110 | POP3 in cleartext (optional STLS upgrade) | Block at the firewall unless a documented legacy device needs it | | 995 | POP3 over implicit TLS ("POP3S") | Allow only if POP3 is still required | | 143 / 993 | IMAP cleartext / IMAP over implicit TLS | Same logic: prefer 993, block 143 | The IETF settled this argument in 2018. [RFC 8314](https://datatracker.ietf.org/doc/html/rfc8314), titled "Cleartext Considered Obsolete," recommends TLS 1.2 or later for all traffic between mail clients and mail servers, and prefers implicit TLS on port 995 over upgrading a cleartext port-110 connection with STLS. NIST's [SP 800-177 Rev. 1](https://csrc.nist.gov/pubs/sp/800/177/r1/final) gives the same advice for POP and IMAP clients: connect over TLS, and it calls authenticating with a username and password over an unencrypted connection "strongly discouraged." On port 110 without STLS, the username, password, and full message content cross the network readable by anyone in a position to sniff it. If you are new to how [TLS](/learning/ssl-vs-tls-whats-the-difference) protects a session, start there. ## Why should security teams care about POP3? **Credentials are the big one.** POP3 in practice means basic authentication: a static password presented on every poll, often every few minutes, from a client that cannot do MFA. Providers have concluded this is untenable. Microsoft [disabled basic authentication](https://learn.microsoft.com/en-us/exchange/clients-and-mobile-in-exchange-online/deprecation-of-basic-authentication-exchange-online) for POP and IMAP in Exchange Online starting October 1, 2022, and it can no longer be re-enabled; POP/IMAP now require OAuth 2.0 there. Google followed: as of March 14, 2025, [Google Workspace no longer accepts password-only sign-in](https://knowledge.workspace.google.com/admin/sync/transition-from-less-secure-apps-to-oauth) for POP, IMAP, SMTP, CalDAV, and CardDAV, leaving OAuth (or app passwords) as the only path. A POP3 client still using a bare password today is talking to an on-prem or smaller hosted server, and those accounts are prime targets for [credential theft](/learning/threats) because legacy protocols skip modern sign-in checks. **Mail sprawls onto endpoints.** After download, the only copy of a message may live in a mailstore file on one laptop. Lose the laptop, lose the mail. Attachments also land straight on disk, so gateway filtering and endpoint protection have to carry the load; see [how to handle malicious email attachments](/learning/how-can-you-safely-handle-malicious-email-attachments). **Investigations get harder.** Once the server copy is deleted, nothing is left centrally to search during an incident or e-discovery request. Responders have to image endpoints instead of querying the mail platform. If clients are subject to retention rules (HIPAA, financial regulations, cyber-insurance requirements), download-and-delete can quietly put them out of compliance. ## How is POP3 different from IMAP? IMAP keeps mail on the server and syncs read/unread state, folders, and deletions across every device. POP3 pulls mail to one device and, by default, removes it from the server. For security and compliance the difference is stark: IMAP centralizes data you can back up, search, and preserve; POP3 fragments it across endpoints. Few cases remain where POP3 wins: a single-device user on a server with hard storage quotas, or a legacy appliance that speaks nothing else. Treat those as exceptions with an expiry date, not architecture. ## How do you secure POP3 if you cannot retire it yet? 1. **Inventory first.** Pull sign-in or protocol logs from each mail platform and list every account using POP3, what client it is, and why. Expect service mailboxes, scanner or ticketing integrations, and a few individual holdouts. 2. **Force TLS.** Allow port 995 only, disable cleartext logins on 110, and require TLS 1.2+, per RFC 8314. 3. **Kill bare passwords.** On Microsoft 365 and Google Workspace this is already done for you. Elsewhere, require OAuth-capable clients or unique app passwords, and enforce MFA on the account itself. 4. **Turn on "leave a copy on the server"** via managed client configuration, and archive at the gateway so a copy exists before any client downloads it. 5. **Monitor the accounts.** Alert on POP3 logins from new IP ranges or countries, spikes in failed logins, and full-mailbox downloads in one session. These are cheap, high-signal detections for account takeover. 6. **Set a migration date.** Move users to IMAP or native cloud clients, and replace mailbox-polling integrations with APIs. ## Does POP3 affect SPF, DKIM, or DMARC? Not directly. SPF, DKIM, and [DMARC](/learning/what-is-dmarc) authenticate mail at the receiving server, before anything reaches a mailbox, so messages a POP3 user downloads have already passed or failed those checks. Retrieval and sender authentication are separate layers; you need both. Two honest caveats: DMARC protects only your exact domain, not [lookalike domains](/learning/how-can-i-take-down-lookalike-domains) that phishers register, and a basic POP3 client gives users fewer visual warnings than webmail, so mail that lands despite a failed check gets less scrutiny. While you clean up legacy access on the receiving side, run a client domain through Palisade's free [email security score](/tools/email-security-score) to check the sending side. ## Common issues **A POP3 client suddenly cannot sign in to Microsoft 365 or Gmail.** The password is not wrong; basic authentication is gone. Exchange Online requires OAuth for POP/IMAP (and Microsoft [says there is no plan](https://learn.microsoft.com/en-us/exchange/clients-and-mobile-in-exchange-online/deprecation-of-basic-authentication-exchange-online) for Outlook clients to support OAuth for POP and IMAP), and Google Workspace requires OAuth or an app password. Fix: switch to an OAuth-capable client or issue an app password where policy allows. **Mail disappeared from webmail after someone set up a desktop client.** That is POP3's download-and-delete default doing its job. Enable "leave messages on server" in the client, then restore from the gateway archive or backup if copies were removed. **The same messages download twice.** The client lost its UIDL cache, or the server does not support UIDL, so it cannot tell what it already fetched. Clear the cache and confirm UIDL support server-side. **Connections to port 110 time out.** A firewall is (correctly) blocking it. Reconfigure the client for port 995 with SSL/TLS instead of asking for an exception. **Certificate errors on connect.** The client is usually pointed at the wrong hostname (the domain instead of the provider's mail host), or the server has an expired certificate or TLS below 1.2. Fix the server name first. ## Frequently asked questions ### Is POP3 still safe to use in 2026? It can be used safely, but only with the full set of compensating controls: TLS on port 995, OAuth or app passwords instead of bare passwords, server-side copies or gateway archiving, and monitoring on the account. That is a lot of effort to prop up a 1996 protocol, which is why the practical answer for most clients is migration to IMAP or native cloud mail. ### Should we block port 110 on client firewalls? Yes, in almost every environment. Port 110 defaults to cleartext credentials, which RFC 8314 declares obsolete and NIST SP 800-177 strongly discourages. Block it, watch for anything that breaks, and isolate any legacy device that genuinely needs it while you plan its replacement. ### Does POP3 still work with Microsoft 365 and Gmail? The protocol still works, but password-only sign-in does not. Exchange Online has required OAuth for POP/IMAP since basic auth was disabled (starting October 2022), and Google Workspace turned off access for apps that sign in with only a password on March 14, 2025. Clients that cannot do OAuth need app passwords where permitted, or replacement. ### Can POP3 sync mail across devices? No. POP3 has no concept of folders, read state, or multiple clients. "Leave a copy on the server" lets a second device download the same messages, but nothing stays in sync. If a user reads mail on more than one device, they need [IMAP](/learning/smtp-vs-imap-vs-pop3-whats-the-difference) or a native cloud client. ### Why do providers care so much about killing basic auth on POP3? Because a static password replayed on every connection is the easiest credential to steal and reuse, and legacy protocols bypass MFA. Microsoft's deprecation notice says exactly that: basic auth makes it easier for attackers to capture credentials, and it makes MFA enforcement difficult or in some cases impossible. Google's [less-secure-apps shutdown](https://knowledge.workspace.google.com/admin/sync/transition-from-less-secure-apps-to-oauth) followed the same logic. See [Microsoft's email authentication requirements](/learning/microsoft-email-auth-requirements) for the day-to-day impact. ## Related reading - [What is IMAP?](/learning/smtp-vs-imap-vs-pop3-whats-the-difference) - [What is SMTP?](/learning/what-is-smtp) - [How can IT teams prevent credential theft?](/learning/threats) --- # Why should MSPs prioritize cybersecurity risk assessments? Canonical: https://www.palisade.email/learning/msps-cyber-risk-assessments > How cybersecurity risk assessments protect MSPs and their clients, with practical steps, the benefits to expect, and quick takeaways for your next audit. ## Introduction Cybersecurity risk assessments are systematic reviews of an organization’s digital defenses that reveal gaps, prioritize threats, and recommend fixes. For MSPs, these assessments are a service and a risk-reduction practice that protect clients and the MSP’s reputation. ### What is a cybersecurity risk assessment? A cybersecurity risk assessment is a structured analysis that finds weaknesses across networks, access controls, authentication methods, and software configurations. It measures how likely each vulnerability is to be exploited and estimates the potential impact. The result is a prioritized list of remediation steps for the business. ### Why do MSPs need to run assessments regularly? Regular assessments are essential because threats and infrastructures change constantly. They ensure that updates, new services, and changing privileges don’t introduce new exposure. Periodic checks also let MSPs track security improvements over time. ### What elements are included in a typical assessment? A standard review covers external attack surface scans, configuration and patch reviews, access and permission audits, and checks for compromised credentials or leaked data. Many teams also test email security, endpoint defenses, and common exploitation vectors. The goal is an end-to-end view of risk. ### How do assessments reduce liability and compliance risk? Assessments document current controls, create a remediation plan, and prove due diligence: the evidence regulators and insurers ask for. They lower the chance of fines, litigation, and reputational harm that come with data breaches. For MSPs, this reduces contractual and legal exposure. ### How do you communicate the value to clients? Clients respond to clear, prioritized findings and a roadmap for fixes. Present assessments as a way to prevent downtime and lost revenue rather than as a technical audit. Use plain language, risk scores, and estimated remediation timelines to show ROI. ### How often should MSPs perform assessments? Assessments should occur at least annually and after major changes such as M&A, cloud migrations, or large software updates. High-risk clients or environments may need quarterly or continuous scanning. Frequency depends on client size, industry, and threat exposure. ### Can automated tools replace manual checks? Automation speeds discovery, but human analysis is still required to interpret context and plan remediation. Automated scans surface issues; experts evaluate risk prioritization and validate fixes. MSPs get the best outcomes when automation and human review are combined. ### What’s the business upside for MSPs? Regular assessments create recurring revenue, improve client retention, and give MSPs a sales differentiator. They also reduce incident costs and protect the MSP’s brand when a client faces attacks. Many MSPs use assessments as an entry point for deeper managed security services. ### How should an MSP get started? Start with a baseline external scan and an access-permissions review, then document findings and build a prioritized action plan. Present results to clients with clear next steps and estimated timelines. Offer follow-up assessments to measure progress and close the loop. ### Tools and reporting Use a mix of external surface scanners, vulnerability scanners, and configuration review tools, plus reporting templates that translate technical findings into business impact. Branded, repeatable reports make assessments scalable and easier to sell. ### Case examples Several high-profile MSP compromises show how one exploited vulnerability can affect hundreds of downstream clients. That blast radius is why proactive discovery and remediation belong in every MSP’s service catalog. ## Quick Takeaways - Assessments reveal hidden vulnerabilities and prioritize fixes. - Regular checks cut legal, compliance, and reputational risk. - They’re a recurring service MSPs can sell to clients. - Automation helps, but human review remains necessary. - Frequency should match client risk and business changes. - Palisade’s prospecting report can speed risk discovery and sales conversations. ## FAQs #### 1. How long does a basic assessment take? Small engagements can be completed in a few days; larger environments may take weeks depending on scope and access. External scans are fast; internal audits require coordination with the client. #### 2. Do clients need to give admin access? Some checks need elevated access for a full internal review, but many useful assessments start with external and configuration data that don’t require admin credentials. Define scope with the client up front. #### 3. Will assessments find everything? No single assessment finds every issue, but regular, layered assessments significantly lower risk and uncover most high-impact problems. Combine different assessment types for broad coverage. #### 4. Can MSPs automate reporting? Yes. Templates and automated report generation speed delivery, but personalize findings and remediation plans to each client’s context. Reports that map findings to business impact are most persuasive. #### 5. How do assessments affect insurance? Documented assessments and remediation can improve an organization’s cyber insurance standing and may reduce premiums by demonstrating proactive risk management. ## Related reading - What should MSPs do in the first 24 hours after a data breach? - [How MSPs protect businesses after macOS security flaws](/learning/msp) - [How should MSPs respond to Biden’s ban on Kaspersky to protect SMBs?](/learning/msp) --- # How should MSPs respond to the FBI email phishing surge? Canonical: https://www.palisade.email/learning/mspemailphishingfbireport2024 > Phishing/spoofing is the FBI IC3's #1 crime type by volume; BEC drove $2.77B in 2024 losses. A practical playbook for MSPs to defend client email. The FBI's Internet Crime Complaint Center (IC3) has ranked phishing and spoofing as the single most-reported crime type two years running: 193,407 complaints in 2024 and 298,878 in 2023, per the FBI IC3 annual reports. For MSPs, that isn't a headline to react to; it's a standing condition to build a service around. Here's what the data actually says and where you can move the needle for clients. ## Quick Takeaways - Phishing/spoofing is the **#1 IC3 crime type by complaint volume**: 193,407 complaints in 2024, ahead of extortion (86,415) and personal data breach (64,882), per the FBI IC3 2024 report. - Phishing's *direct* reported loss is comparatively small ($70,013,036 in 2024). The real money is in **Business Email Compromise: $2.77 billion in 2024 losses** from just 21,442 complaints, a phishing-adjacent attack that spoofing enables. - The controls that address this are the boring, proven ones: **SPF, DKIM, DMARC at `p=reject`, and MFA**, the same stack CISA mandated for federal agencies in BOD 18-01. - A `p=reject` [DMARC policy](/tools/dmarc) is, in CISA's words, the strongest protection against spoofed email. It tells receiving servers to block messages that fail authentication for your domain. - Palisade's hosted DMARC lets an MSP take a client from monitoring to `reject` from a dashboard slider, and turns aggregate reports into readable charts instead of raw XML, so enforcement across a portfolio is a repeatable process, not a per-domain research project. ## What does the FBI data actually say about phishing? Read the IC3 numbers carefully, because the loudest stat isn't the most important one. Phishing/spoofing tops the complaint count every year, but its *directly reported* loss was $70,013,036 in 2024, a rounding error next to the year's costliest categories. The FBI IC3 2024 report puts total losses across all crime types at $16.6 billion (a 33% jump over 2023), with investment fraud the costliest single type at roughly $6.57 billion and BEC second at about $2.77 billion. ![Comparison of 2024 FBI IC3 figures for phishing/spoofing versus business email compromise, showing phishing leads complaints while BEC leads losses.](/images/figures/mspemailphishingfbireport2024-fig1.webp "1200x442") *Figures from the FBI IC3 2024 report: phishing leads complaint volume; BEC drives the losses.* The takeaway for an MSP: phishing is rarely the crime that empties the account. It's the *entry point*. A credential harvested through a convincing spoofed email becomes the compromised mailbox that a BEC scheme runs through. The IC3 describes BEC exactly this way, an attacker compromises a legitimate business email account, then uses it to redirect payments. And the scale is enormous: the FBI's September 2024 PSA on BEC reported $55,499,915,582 in exposed losses across 305,033 incidents between October 2013 and December 2023, spanning all 50 states and 186 countries. (That's a cumulative decade-plus figure, not a single year, but it shows where spoofing ultimately leads.) ## Which controls actually address this, per CISA and IC3? CISA and IC3 recommend controls, not products. The clearest blueprint is CISA's Binding Operational Directive 18-01, which required federal agencies to publish SPF records, sign outbound mail with DKIM, and set a DMARC policy of `p=reject`. Three of those work together: - **SPF** lists the IPs allowed to send for your domain. Check any client's record with the [SPF tool](/tools/spf). - **DKIM** cryptographically signs outbound mail so receivers can verify it wasn't altered. Verify signing with the [DKIM tool](/tools/dkim). - **DMARC** ties them together: it tells receiving servers what to do when a message fails both checks: monitor (`p=none`), quarantine, or reject. CISA calls `p=reject` the strongest protection against spoofed email because unauthenticated messages impersonating the domain get blocked at the mail server before a user ever sees them. On the account side, CISA's MFA campaign frames multi-factor authentication as making an account "99% less likely to get hacked," and points to phishing-resistant MFA (FIDO/WebAuthn) as the strongest form. Treat that 99% as CISA's awareness-campaign framing rather than a precise lab figure, but the direction is not in dispute. ## How should an MSP prioritize across a client base? Don't boil the ocean. Sequence it: ![Four-step card showing the order MSPs should sequence email defenses, from DMARC enforcement through MFA and mailbox lockdown to training.](/images/figures/mspemailphishingfbireport2024-fig2.webp "1200x699") *The sequence from this article; DMARC enforcement is the highest-leverage first move.* 1. **Get every client domain to DMARC enforcement.** This is the highest-leverage move because it structurally kills exact-domain spoofing. The technique behind the spoofing complaints IC3 counts. Start each domain at `p=none` to inventory senders, fix SPF/DKIM alignment, then ramp to quarantine and `reject`. 2. **Enforce MFA everywhere**, and push phishing-resistant MFA (FIDO/WebAuthn) for finance staff and executives, the roles a BEC attacker targets. 3. **Lock down the mailbox mechanics** attackers abuse: restrict external auto-forwarding rules and audit OAuth app grants, which can bypass MFA entirely. 4. **Train against the current pattern** (urgency, spoofed sender names, and payment-change requests) and rehearse a short incident-response playbook: isolate the account, revoke tokens, force a password and MFA reset. The bottleneck on step 1 is almost always the DNS work. Getting one domain from `none` to `reject` means several record changes over weeks; across fifty client domains, that's where DMARC projects stall for months. ## Where does Palisade fit for an MSP? Palisade is built for exactly the step-1 bottleneck. With hosted DMARC, the client adds **one CNAME** at `_dmarc.<domain>` delegating to Palisade, and Palisade publishes and maintains the actual record. From then on, policy changes (`none` → quarantine (with a percentage ramp) → `reject`) happen from a dashboard slider with a diff preview before anything is applied. A status badge (Verifying → Active, or Error) tells you where each domain stands. Just as important for defending against BEC: Palisade parses the DMARC aggregate (`rua`) reports into readable charts in a Reports tab, so you can *see* who's spoofing a client's domain and confirm every legitimate sender passes before you tighten policy, no raw XML. Across a portfolio, that turns enforcement into a batch process instead of fifty separate DNS tickets. Palisade doesn't do the training or the mailbox forensics, but it removes the reason DMARC enforcement usually gets deferred. ## Common issues when rolling DMARC out across a client base ### The client's SPF record hits the 10-lookup limit and starts failing Adding every SaaS sender (marketing, invoicing, help desk) can push an SPF record past the DNS lookup cap, at which point it `permerror`s and legitimate mail fails. Flatten nested includes, remove services the client no longer uses, and re-check with the [SPF tool](/tools/spf) before you tighten policy. ### Mail authenticates but still fails DMARC alignment A message can pass raw SPF or DKIM yet fail DMARC because the authenticated domain doesn't match the visible From address. This is the usual culprit for third-party senders. Fix the alignment domain (configure the platform to sign with the client's domain via [DKIM](/tools/dkim)) rather than loosening policy. ### Forwarded mail breaks SPF and looks like a failure Forwarding rewrites the sending IP, so SPF fails for legitimately forwarded messages. DKIM survives forwarding, which is why DKIM alignment matters most before you move to `reject`. Read the aggregate reports to confirm these are forwards, not spoofing, before acting. ### A subdomain is being spoofed even though the root domain is at reject DMARC policy doesn't automatically cover subdomains unless you set the [`sp` tag](/learning/glossary/dmarc-sp). Publish an explicit subdomain policy (or a record on the subdomain itself) so `marketing.client.com` inherits enforcement. Verify each domain and subdomain with the [DMARC checker](/tools/dmarc). ## Frequently asked questions ### Is phishing really the biggest email threat if its losses are low? By complaint volume, yes: it's the #1 IC3 crime type. By dollars, the direct phishing loss was $70M in 2024, while BEC (which spoofing enables) drove about $2.77 billion. Read them together: phishing is the entry point, BEC is the payout. ### Does DMARC stop phishing? It stops one specific, high-value technique: mail that spoofs *your* exact domain. At `p=reject`, receiving servers block those messages. It won't catch look-alike domains or attacks from a genuinely compromised account: which is why MFA, filtering, and training sit alongside it. ### Is MFA enough on its own? No. CISA credits MFA with making accounts far harder to compromise, but attackers use MFA-bypass and OAuth-consent abuse. Pair it with phishing-resistant methods (FIDO/WebAuthn), and audit connected app grants regularly. ### How fast can we get a client to DMARC enforcement? A domain with clean SPF/DKIM alignment can reach `reject` in weeks. The pacing is set by how quickly you confirm every legitimate sender passes at `p=none`. With hosted DMARC, each policy step is a dashboard change, not a DNS ticket, so enforcement day doesn't wait on the client's IT. ### What should we preserve after a suspected mailbox compromise? Authentication logs, full [email headers](/tools/email-header-analyzer), mailbox forwarding rules, and OAuth consent grants, plus any DMARC reports showing the spoofing. Those establish timeline and scope before you revoke tokens and reset credentials. Want a fast read on any client domain? Run the free [Email Security Score](/tools/email-security-score): it checks DMARC, SPF, and DKIM posture in seconds. ## Related reading - [DMARC checker](/tools/dmarc) - [Microsoft compliance checker](/tools/microsoft-compliance-checker) - [Palisade for Managed Service Providers](/for-managed-service-providers) --- # How did the 2024 DMARC rules change MSP email protection for SMBs? Canonical: https://www.palisade.email/learning/how-will-2024-dmarc-rules-change-msps-email-protection-for-smbs > The 2024 DMARC rules pushed MSPs from passive monitoring to active enforcement for SMB clients: quarantine or reject policies, reports, and alignment. ## Introduction [Email authentication](/learning/what-is-email-authentication-and-why-does-it-matter) tightened in 2024 forces MSPs to shift from passive monitoring to active enforcement to protect SMB clients. This Q&A guide outlines practical steps, operational playbooks, and communication tips to implement stronger DMARC policies while keeping business mail flowing. ## Quick Takeaways - 2024 DMARC guidance favors enforcement (quarantine/reject) over monitor (p=none). - MSPs must manage aggregate reporting and automate parsing to scale across SMBs. - Inventorying all senders and aligning SPF/DKIM is essential before enforcement. - Third-party senders need verification or subdomain delegation to avoid delivery loss. - A staged rollout (monitor → quarantine → reject) reduces operational risk. - Palisade provides tools and templates to audit and improve email authentication posture. ## Q&A ### 1. What exactly changed in the 2024 DMARC requirements? The 2024 updates press domain owners to adopt enforcement policies (p=quarantine or p=reject) instead of just monitoring. Reporting obligations are stricter, requiring regular collection and review of aggregate DMARC data. Third-party sender rules were tightened so that every service sending mail on a domain’s behalf must align with SPF/DKIM. For MSPs, this means ongoing operations, not one-time configuration, across multiple SMB clients. Automated tooling is now a practical necessity to handle scale. ### 2. Why should MSPs care about these new DMARC rules? Because the new rules move responsibility for active protection onto MSPs managing SMB email, they directly affect client security and reputation. Without enforcement, spoofed or phishing emails can reach users and cause financial and brand damage. MSPs that deliver reliable enforcement reduce incident risk and can offer DMARC management as a paid service. Proper execution also improves deliverability since mailbox providers treat enforced domains as more trustworthy. In short, it’s both risk and opportunity. ### 3. How does DMARC work and how should MSPs assess a client’s posture? DMARC tells receivers how to handle messages that fail SPF or DKIM checks: monitor, quarantine, or reject. MSPs should start with a comprehensive sender inventory, verify SPF records and DKIM signing for each mail stream, then publish a baseline [DMARC record](/tools/dmarc). Collect and parse aggregate reports to identify failing senders and misconfigurations. To speed up assessments, use Palisade’s [Email Security Score](/tools/email-security-score) to map gaps and prioritize fixes: [Check your DMARC posture with Palisade](https://www.palisade.email/tools/email-security-score). Schedule staged enforcement once failures are resolved. ### 4. What technical steps are needed to move a domain to p=reject safely? Moving a domain to p=reject safely starts at p=none, which gathers reports and discovers every legitimate sender. Implement [DKIM](/tools/dkim) for all streams and tighten [SPF](/tools/spf) to list only authorized IPs and includes. Use p=quarantine as an intermediate testing phase (see [reject vs quarantine](/resources-post/dmarc-reject-vs-quarantine-whats-the-difference) for how each policy is treated) and monitor reports closely to catch edge cases. Prepare rollback plans and communicate windows with stakeholders to avoid disrupting transactional mail. Automate report ingestion to accelerate detection and remediation of newly failing senders. ### 5. How should MSPs handle third-party sending platforms? Treat each external sender as a likely source of DMARC failures until validated. Get a vendor inventory from the client, verify that each platform can sign with DKIM or send from an aligned subdomain, and work with vendors to correct misalignment. For services that can’t align, use subdomain delegation or dedicated sending domains to isolate risk. Document approved vendors centrally and re-audit on a schedule or after major changes. This governance prevents unexpected delivery issues when enforcement is raised. ### 6. What does mandatory DMARC reporting mean for daily operations? It means MSPs must collect XML aggregate reports and convert them into actionable insights regularly rather than occasionally. Manual review won’t scale across many SMBs. Automated ingestion and parsing are required. Reports show who’s sending mail for a domain and whether it passed authentication, revealing misconfigurations, spoofing, or unauthorized senders. Use this data to prioritize fixes and demonstrate to clients that enforcement won’t break legitimate flows. Retain reports (90 days minimum) to spot trends and regressions. ### 7. Which tools and workflows work best for scaled DMARC enforcement? Platforms that automate reporting, parsing, visualization, and alerting are essential, combine them with ticketing and change-control workflows. Look for tooling that integrates SPF/DKIM checks and recommends policy changes. Palisade offers auditing and orchestration features designed for multi-client operations, plus playbooks to standardize rollouts. Standardized dashboards and SLAs help turn DMARC into a repeatable managed service offering. Automate remediation where possible to reduce manual toil and error. ### 8. Will stricter DMARC hurt email deliverability? If you inventory and align senders first, stronger DMARC improves deliverability because mailbox providers gain confidence in your domain. The main risk is moving to reject before all legitimate senders are aligned. This can block transactional or marketing messages. A phased approach (monitor → quarantine → reject) minimizes surprise drops and gives time to fix exceptions. Always notify internal teams and vendors before policy changes so they can prepare. Post-change monitoring should be continuous to detect and correct issues quickly. ### 9. How should MSPs plan a rollout for SMB clients? MSPs should plan an SMB client rollout as a four-step program: discover, remediate, test, enforce. Start with a reporting window to discover senders, fix SPF/DKIM problems for core systems, test in quarantine, then move to reject when stable. Keep communication lines open with clients and vendors and schedule rollback windows as a precaution. Pilot the process on a handful of clients to tune the playbook before broad rollout. Use automated reports and SLAs to prove value and reduce friction. ![Four-step DMARC rollout flow for MSPs: discover senders, remediate SPF and DKIM, test in quarantine, then enforce reject.](/images/figures/how-will-2024-dmarc-rules-change-msps-email-protection-f-fig1.webp "1200x699") *A staged rollout, discover, remediate, test, enforce, reduces operational risk.* ### 10. What common mistakes must MSPs avoid? The common mistakes MSPs must avoid are skipping a full sender inventory, neglecting DKIM signing, and relying on manual report review. Overlooking marketing platforms or transactional services can cause major delivery failures after enforcement. Too-fast policy changes without alerts and rollback options increase client disruption. Treat DMARC as an operational service: automate, document, and test. Tailor policies per domain rather than applying a one-size-fits-all approach. ![Checklist of six common DMARC mistakes MSPs should avoid, from skipped sender inventories to one-size-fits-all policies.](/images/figures/how-will-2024-dmarc-rules-change-msps-email-protection-f-fig2.webp "1200x639") *Frequent errors that cause delivery failures and client disruption after enforcement.* ### 11. How can MSPs demonstrate DMARC value to SMB owners? MSPs demonstrate DMARC value to SMB owners by leading with measurable risk reduction: show how enforcement reduces impersonation and phishing attempts that lead to fraud or data loss. Use report data to quantify spoofed message volumes and how many were blocked during testing. Offer enforcement as a managed service with reporting dashboards and SLA commitments for remediation time. Emphasize brand protection and improved deliverability as additional benefits. Packaging DMARC with monitoring and incident response makes it easier for SMBs to buy and trust the service. ### 12. What ongoing maintenance does DMARC enforcement require? Daily ingestion and analysis of [DMARC reports](/resources-post/how-to-understand-dmarc-reports), alerts for new failing senders, and scheduled audits of authorized services are the core tasks. Rotate DKIM keys regularly and keep SPF records concise to avoid DNS lookup limits. Integrate changes into your ticketing and change-control systems and produce regular client reports that show improvements and any actions taken. Treat DMARC as a continuous operational control, not a one-off project. Periodic re-validation after marketing campaigns, vendor changes, or mergers is critical. ## FAQs ### Q: How long does it typically take to move from p=none to p=reject? Expect 4–12 weeks for most SMBs, depending on the number of sending services and vendor responsiveness. Complex environments can take longer due to legacy systems and multiple vendors. Planning staged changes and automation shortens the timeline. Communication with stakeholders is essential to prevent surprise delivery issues. Factor in time for report analysis and repeated remediation cycles. ### Q: Can strict DMARC block marketing emails? Yes: if marketing platforms aren’t configured to sign mail or send from an aligned domain, enforcement can block those messages. Verify marketing providers beforehand, or use subdomain delegation to isolate marketing sends. Use quarantine testing to identify issues before moving to reject. Vendor collaboration and a documented inventory prevent major disruptions. Automation helps detect blocked streams fast so fixes can be applied quickly. ### Q: Will DNS SPF changes cause downtime? Direct downtime is uncommon if changes are validated and rolled out with care, but misconfigured SPF records can cause authentication failures. Use low TTLs during testing, validate records before propagation, and avoid long include chains that exceed DNS lookup limits. Monitor reports immediately after changes and have a rollback plan. Treat DNS updates as controlled change requests to reduce risk. ### Q: Does DMARC stop all phishing? No: DMARC prevents domain spoofing for properly configured domains but doesn’t stop phishing from look-alike domains or compromised accounts. Combine DMARC with user training, inbound filtering, and threat detection for a layered defense. Regular monitoring and rapid incident response are still required. DMARC is a critical control, not a silver bullet. ### Q: Where can MSPs get help implementing DMARC at scale? Use platforms that automate reporting, parsing, remediation workflows, and integrate with ticketing systems to manage many clients simultaneously. Palisade provides tools, templates, and playbooks to accelerate audits and enforcement rollouts for MSPs. Focus on standardization, automation, and documented SOPs to reduce time to enforcement. Partner with vendors that offer multi-tenant visibility and clear SLAs for remediation support. For a quick check of domain posture, start here: [Palisade Email Security Score](https://www.palisade.email/tools/email-security-score). ## Sources and further reading - [RFC 9989](https://www.rfc-editor.org/rfc/rfc9989.html) defines DMARC, including the policy values and the aggregate reporting that enforcement depends on. - [RFC 7208](https://www.rfc-editor.org/rfc/rfc7208.html) defines SPF, including the 10 DNS-lookup limit that keeps include chains short. - [RFC 6376](https://www.rfc-editor.org/rfc/rfc6376.html) defines DKIM signing and key management. - [Email sender guidelines](https://support.google.com/a/answer/81126) set out the bulk sender authentication requirements that pushed domains toward enforcement in 2024. - [Sender Best Practices](https://senders.yahooinc.com/best-practices/) documents the matching bulk sender requirements on the other side. --- # Can Rockstar 2FA bypass Microsoft 365 MFA? Canonical: https://www.palisade.email/learning/rockstar2fam365 > Rockstar 2FA is a phishing-as-a-service kit that steals M365 session cookies to bypass MFA. How the AiTM attack works and what actually stops it. Yes: Rockstar 2FA can get past Microsoft 365 MFA, but not by cracking your second factor. It's a phishing-as-a-service kit that uses an adversary-in-the-middle (AiTM) proxy to steal the live session cookie *after* the user completes MFA. Trustwave SpiderLabs researchers Diana Solomon and John Kevin Adriano documented the toolkit in late November 2024. Here's how it works and what actually stops it. ## Quick Takeaways - Rockstar 2FA doesn't break MFA, it **steals the session cookie** issued after a legitimate MFA sign-in, then replays it. Per Trustwave, that means "even users with multifactor authentication (MFA) enabled can still be vulnerable." - It's a **subscription PhaaS kit**, sold from around **$200 for a two-week subscription** (other outlets report ~$350/month) via ICQ, Telegram, and Mail.ru. Trustwave counted more than 1,500 subscribers on its Telegram channel in August 2024. - Landing pages are built to **mimic Microsoft 365 login pages**; the kit also ships themes for Google, Hotmail, GoDaddy, and generic SSO. - OTP, SMS codes, and push approvals **do not stop it** once the victim authenticates through the proxy. Only **phishing-resistant MFA (FIDO2/WebAuthn security keys and passkeys)** resists the attack, CISA calls FIDO/WebAuthn the only widely available phishing-resistant authentication. - **DMARC, SPF, and DKIM reduce lure delivery** but don't stop cookie theft after a click, and many Rockstar lures arrive from already-compromised legitimate accounts. ## What is Rockstar 2FA? Rockstar 2FA is a phishing-as-a-service (PhaaS) toolkit, attackers rent the infrastructure instead of building it. Trustwave traces its lineage to the **DadSec** phishing kit (also called Phoenix), which originated around May 2023, with the Rockstar variant emerging in late 2023. Microsoft tracks the actor cluster behind DadSec/Rockstar as **Storm-1575**. Worth being precise here: Storm-1575 is Microsoft's temporary tracking label for the DadSec/Phoenix cluster, not a confirmed single group. Because Rockstar 2FA is sold as a service to many unrelated buyers, campaigns using it aren't one coordinated actor, they're whoever paid the subscription that month. The marketed feature list reads like a SaaS product: 2FA bypass, harvesting of 2FA cookies, antibot protection, multiple login-page themes, randomized source code and attachments, "fully undetectable" (FUD) links, Telegram bot integration, and a user-friendly admin panel for tracking campaigns. That packaging is the point. It lets low-skill buyers run account-takeover campaigns that used to require real technical chops. ## How does the AiTM technique defeat MFA? This is the mechanic MSPs need to understand, because it changes what "having MFA" actually protects against. The AiTM proxy sits between your user and the real Microsoft sign-in service as a reverse proxy: 1. The victim clicks a lure and lands on a fake login page that looks like Microsoft 365. 2. They type their username and password. The proxy **relays those to the real Microsoft service** in real time. 3. Microsoft prompts for the second factor. The victim approves the push or enters the OTP, and the proxy passes that through too, completing genuine MFA. 4. Microsoft returns a **valid session cookie** to the browser. The attacker's proxy captures it. That stolen cookie represents an already-authenticated session. The attacker replays it to access the mailbox **without the password and without triggering MFA again**: the second factor was already satisfied, in real time, through the proxy. This is why one-time passcodes, SMS codes, and push-notification approvals don't help here: they all get completed live and the resulting token is what gets stolen. MFA that relies on a phishable code or tap is defeated not by breaking the factor but by hijacking what the factor produces. ## What lures and evasion tricks does it use? Rockstar 2FA campaigns are built to reach inboxes and dodge scanners. Reporting from Trustwave, The Hacker News, and BleepingComputer describes a consistent playbook: - **Delivery from compromised accounts** and abused legitimate services, which passes basic sender checks because the mail genuinely comes from a real, authenticated account. - **Familiar lure themes**: file-sharing and document notifications, e-signature requests, IT notices, password resets, and payroll alerts. - **Multiple delivery formats**: direct URLs, QR codes, and HTML and PDF attachments, QR codes and attachments move the malicious link off the message body where filters look. - **Trusted-platform abuse**: hosting links behind Atlassian Confluence, Google Docs Viewer, Microsoft OneDrive/OneNote, and Dynamics 365 Customer Voice, plus URL shorteners, open redirects, and link-protection rewriters. - **Antibot filtering**: Cloudflare Turnstile challenges and redirects to decoy pages to screen out automated scanners and researchers before the phishing page ever renders. Trustwave reported more than 3,700 urlscan.io hits matching the campaign's URL pattern since May 2024, and over 5,000 hits on car-themed decoy domains linked to the operation over the same window. (Those are Trustwave's telemetry proxies for a specific window, not total victim counts.) The kit also promotes "fully undetectable" (FUD) links and obfuscated HTML to slip past URL-based detection and antispam. ## What actually stops Rockstar 2FA? The uncomfortable answer: most of the MFA you've already rolled out won't. The controls that do work come from CISA and Microsoft, not the Trustwave writeup itself. **Phishing-resistant MFA is the real fix.** FIDO2/WebAuthn security keys and passkeys are cryptographically bound to the legitimate site's origin, so the credential simply won't authenticate against the attacker's proxy domain, there's nothing for the AiTM relay to forward. CISA calls FIDO/WebAuthn the only widely available phishing-resistant authentication and describes FIDO2 as the gold standard of MFA. Frame this correctly with clients: passkeys are the mitigation here, not a victim. **Layer Microsoft's token controls.** Microsoft recommends Conditional Access policies that require a compliant or Microsoft Entra hybrid-joined device, which blocks token issuance to untrusted endpoints like an AiTM proxy, plus **Token Protection (token binding)** in Conditional Access to cut the risk of a stolen token being replayed from another device. **Reduce lure delivery upstream.** This is where email authentication earns its place. Enforcing DMARC, SPF, and DKIM blocks spoofed and unauthenticated messages that carry these lures. Be honest about the limit, though: authentication doesn't stop credential or session theft once a user reaches the AiTM page, and many Rockstar lures come from genuinely compromised accounts that pass authentication. Treat DMARC as thinning the volume that reaches inboxes, not as an AiTM cure. If you run Managed DMARC across a client portfolio, moving every domain to enforcement is one fewer channel attackers can spoof. Check any domain's posture with the free [DMARC checker](/tools/dmarc) or a full [Email Security Score](/tools/email-security-score). ## Frequently asked questions ### Does MFA still matter if Rockstar 2FA can bypass it? Yes: just not all MFA equally. Phishable factors (OTP, SMS, push) still block password-only attacks and credential stuffing, so keep them. But against AiTM specifically, only phishing-resistant MFA (FIDO2/WebAuthn keys and passkeys) holds up, because the credential is tied to the real site's origin and can't be relayed through a proxy. ### Will better email filtering stop it? Filtering reduces how many lures reach users, which matters, but it won't stop well-built AiTM campaigns delivered from compromised senders, hidden behind trusted platforms, or wrapped in QR codes and PDF attachments. Pair filtering with phishing-resistant MFA and Conditional Access. ### Do DMARC, SPF, and DKIM protect against Rockstar 2FA? They help on the front end by cutting spoofed and unauthenticated mail, but they don't stop session-cookie theft once someone clicks through to the proxy. And lures sent from already-compromised legitimate accounts can pass authentication. Useful layer, not a standalone defense. ### How much does Rockstar 2FA cost attackers? Trustwave lists roughly $200 for a two-week subscription; some outlets report around $350 for a month. It's marketed and sold via ICQ, Telegram, and Mail.ru, and Trustwave found more than 1,500 subscribers on its Telegram channel in August 2024. ### Who is most at risk? Any organization that relies on Microsoft 365 with phishable MFA. The kit is built to mimic M365 login pages, and its subscription model puts credible AiTM phishing in reach of low-skill buyers, which is exactly why the defensive bar has moved to phishing-resistant MFA. Want to see which of your client domains still let spoofed lures through? Run the free [Email Security Score](/tools/email-security-score): it checks DMARC, SPF, and DKIM in seconds. ## Related reading - [DMARC checker](/tools/dmarc) - [Microsoft compliance checker](/tools/microsoft-compliance-checker) - [DMARC automation for MSPs](/for-managed-service-providers) --- # What are the main MSP types and how do their pricing models work? Canonical: https://www.palisade.email/learning/what-are-the-main-msp-types-and-how-do-their-pricing-models-work > Clear answers on MSP types, common pricing models, and how to pick a model that protects margins and serves clients. ## Introduction MSP pricing models come in five shapes: tier-based, per-device, per-user, value-based, and pay-as-you-go. Which one fits depends on the type of provider you are. A general MSP runs routine IT operations on fixed-fee contracts, an MSSP sells security-first work from a SOC, a pure-play MSP goes deep on one capability such as cloud migration or penetration testing, and a managed IT services provider does hands-on help desk and break/fix work. The trap in per-device and per-user billing is margin erosion when device complexity grows without a matching price adjustment. ![MSP types illustration](/images/cms/68dff83b350016667e7cdd5b_img-yomdp37vzlaomvt6xw9zlby7.png) ## 1. What is an MSP? An MSP is a company that handles routine IT operations for other organizations. Typical responsibilities include systems maintenance, backups, patch management, and vendor coordination. MSPs often provide fixed-fee contracts or retainers to create predictable revenue. They are ideal for businesses that lack internal IT staff or want to outsource day-to-day operations. MSPs can scale services across multiple clients using standardized tools and processes. ## 2. What is an MSSP? An MSSP focuses on security-first services like threat detection, incident response, and continuous monitoring. MSSPs usually operate a security operations center (SOC) and use specialized tools and frameworks to hunt threats. They charge for advanced security expertise that goes beyond general IT support. Many organizations choose an MSSP when they need proactive defense and compliance help. MSSPs can be offered by standalone security firms or as a specialized arm of an MSP. ## 3. What are pure-play MSPs? Pure-play MSPs specialize in one technical area, such as cloud migration, endpoint protection, or penetration testing. Their depth in a niche makes them valuable for clients with focused needs who want expert-level service. Pure-play MSPs typically use subscription models tied to the specific capability they provide. They fit organizations that need a targeted skill set rather than broad IT coverage. Work is often delivered by small, highly skilled teams with tight SLAs. ## 4. How do managed IT services differ? Managed IT services concentrate on hands-on support: hardware, help desk, onboarding, and break/fix work. They are often structured around hourly rates, service bundles, or basic retainers. This model is practical for businesses needing frequent hands-on tech support. The provider’s value is in speed, reliability, and technician availability. For many, a managed IT provider is the front line while an MSP or MSSP provides broader strategy or security. ## 5. What pricing models do MSPs use? MSPs use several popular pricing approaches: tier-based, per-device, per-user, value-based, and pay-as-you-go. Tiered plans bundle discrete features and support levels into named packages for predictable billing. Per-device and per-user pricing scale linearly and are simple to explain to clients. Value-based pricing ties fees to outcomes or business impact, which can drive higher margins when you prove ROI. Pay-as-you-go charges based on actual consumption, common for cloud services. ## 6. When does tier-based pricing work best? Tier-based pricing is best when clients need clear, predictable packages and you offer standardized services. It simplifies sales conversations by letting customers compare Bronze/Silver/Gold bundles. This model helps you sell higher tiers by stacking features and response SLAs. It’s scalable and reduces billing complexity across many clients. However, it can limit flexibility for clients with unusual or rapidly changing needs. ## 7. What are the pros and cons of per-device and per-user pricing? Per-device and per-user structures are easy to implement and explain, and they scale with client growth. They work well for organizations with steady headcounts or device counts and for distributed workforces. The downside is margin erosion if device complexity increases (e.g., servers or specialized hardware) without proportional price adjustments. Both models can misalign incentives, encouraging providers to grow seats rather than deliver efficiency. Regularly review what counts as a billable device or user to avoid surprises. ## 8. What is value-based pricing and when should you use it? Value-based pricing charges based on the business outcome you deliver rather than inputs. Use it when you can measure clear KPIs: fewer incidents, reduced downtime, or compliance cost avoidance. It can produce higher margins because clients pay for results, not time. This model needs strong monitoring, reporting, and a trust relationship to work. Start with pilot clients and measurable goals before rolling it out broadly. ## 9. When is pay-as-you-go the right choice? Pay-as-you-go suits customers that want consumption-based billing, like startups or businesses with seasonal spikes. It is common for cloud compute, storage, and API-driven services. This model keeps costs aligned with actual usage but can be unpredictable month-to-month. It’s attractive when clients want to avoid long-term commitments while they test or scale new workloads. For MSPs, integrating pay-as-you-go requires good cost transparency and chargeback tooling. ## 10. How do I choose the right pricing model for my MSP? Pick a model that aligns with your service mix, client base, and margin targets. Analyze your cost to deliver each service, then map pricing to outcomes you can reliably provide. Many MSPs mix models: tiered core services plus per-device add-ons and consumption-based cloud fees. Test price points with pilot clients and track churn and profitability. Prioritize transparency so clients understand how charges map to value. ## 11. How should I set prices to protect profit margins? Protect margins by calculating your true cost of delivery (tools, labor, overhead) and then add a target margin. Factor in onboarding costs, escalation time, and expected ticket volume per client. Use service tiers to capture different willingness-to-pay and create upsell pathways for higher-margin offerings. Monitor utilization and adjust prices when SLAs or scope change. Automate reporting and billing to reduce overhead and shrink the gap between list price and realized margin. ## 12. How do I present pricing to clients clearly? Lead with value: explain outcomes, SLAs, and what problems you remove for the client. Offer simple, comparable packages and a clear list of inclusions and exclusions. Use examples and case numbers to show typical monthly costs and expected savings from fewer incidents. Provide a transition plan showing onboarding steps, timelines, and responsibilities. Make contracts transparent with defined renewal windows and an easy change control process. ## Quick Takeaways - MSPs, MSSPs, and pure-play providers serve different needs. Match specializations to client pain points. - Tiered plans simplify selling while per-device/per-user models make billing straightforward. - Value-based pricing can boost margins but requires measurable outcomes and trust. - Pay-as-you-go fits cloud-native or seasonal customers but needs clear cost visibility. - Mixing models (tier + consumption + add-ons) often gives the best balance of predictability and flexibility. - Always calculate true delivery costs before setting prices and test with pilot clients. ## FAQs ### Can one company be both an MSP and an MSSP? Yes. Many firms offer both general IT management and dedicated security operations as separate service lines. The key is clear scope separation, pricing for specialized security work, and the right tooling and staffing for a SOC. Offering both expands your revenue streams but increases operational complexity. Make sure SLAs and reporting differ when clients buy security vs. standard IT support. ### How do I handle mixed device environments in per-device pricing? Define device categories (workstation, server, network appliance) and price them accordingly. Use clear rules for what counts as a device and which are included in base tiers. Regular audits and an automated inventory system prevent billing disputes. Consider hybrid pricing with per-user for workstations and per-device for servers to maintain margins. Communicate device classifications to clients as part of onboarding. ### Should startups always choose pay-as-you-go? Not always. Startups with variable workloads or short-term needs often prefer pay-as-you-go for flexibility. However, if a startup plans predictable growth or needs hands-on support, a tiered or per-user plan can be cheaper and more stable. Evaluate expected usage patterns and support needs before deciding. Offer short trial periods or convertible credits to help startups test services without long-term risk. ### How often should MSPs reevaluate pricing? Review pricing at least annually and after major changes in tooling, labor costs, or service scope. Track utilization, ticket volumes, and margin trends monthly to catch erosion early. Reprice or restructure when onboarding costs rise or when frequent custom work becomes standard. Communicate changes with plenty of notice and offer grandfathered options when practical. Continuous monitoring helps keep prices aligned with delivery costs and market rates. ### Where can I read more about MSP pricing best practices? For practical resources and tools on MSP pricing and service design, visit Palisade. Our guides and calculators help you model margins and test pricing scenarios to find what works for your business. ## Related reading - [What Are the Most Common Types of DDoS Attacks and How Do They Work?](/learning/threats) - [What Are the Most Effective Data Loss Prevention Strategies?](/learning/threats) - [What Are the Top Email Security Tips for Small Businesses?](/learning/what-are-the-top-email-security-tips-for-small-businesses) --- # Which podcasts should every MSP bookmark? Canonical: https://www.palisade.email/learning/which-podcasts-should-every-msp-bookmark > Fourteen podcasts that help MSPs grow revenue, improve operations, and tighten security. Practical picks for IT leaders, with what each show does best. The MSP podcasts worth a standing subscription cover three jobs: business growth, technical operations, and security news. We pulled together 14 shows that deliver tactical advice, growth strategy, and threat updates aimed specifically at managed service providers. Listening regularly keeps your service packaging competitive and surfaces emerging threats before clients ask about them. ## What makes MSP-focused podcasts valuable? They translate industry trends into practical steps: actionable sales tips, operations fixes, and security controls you can adopt immediately. Episodes often feature peers who share hard-earned lessons, saving you trial-and-error time. Regular listening exposes you to vendor demos, case studies, and market shifts that affect pricing and service models. For busy leaders, the right show is a compact way to stay sharp without long conferences. ## Which podcasts cover cybersecurity and threat response for MSPs? Several shows focus on cyber risk, incident response, and defensive tooling. Ideal for MSPs that want to harden client environments. Look for episodes that include incident post-mortems, vendor roundtables, or CTO interviews; they often explain how to operationalize tools and apply controls. Palisade also contributes to conversations about aligning MDR and endpoint protection with MSP workflows to speed investigations and reduce dwell time. Use those episodes to map controls to client risk profiles and to build repeatable security packages. ## Why listen to MSP business-growth shows? Growth episodes teach repeatable ways to package services, price for value, and scale delivery without adding chaos. Hosts break down lead generation, sales processes, and client lifecycle management into templates you can test. Hearing how peers structured SLAs or automated onboarding gives you blueprints to trial immediately. That practical focus makes these podcasts a form of on-demand mentoring for your leadership team. ## Which podcasts dig into technical implementation? There are shows devoted to deep technical walkthroughs, product demos, and platform comparisons that help engineers choose the right stack. These episodes frequently include step-by-step guides and real demos that shorten deployment time. Engineers benefit from hearing detailed troubleshooting approaches and configuration tips they can reuse across clients. Use technical podcasts as training content for junior staff or to plan project timelines. ## How often should MSPs listen to podcasts? Listen weekly when possible; a consistent cadence keeps you up to date without overwhelming your schedule. Pick 2–3 favorite shows and rotate episodes that match current priorities, sales one week, security the next. Use podcast notes and timestamps to jump to directly relevant segments. Make listening part of routine activities like commutes or maintenance windows to squeeze value from downtime. ## Can podcasts replace formal training? No: podcasts are a complement, not a substitute for structured certification or hands-on labs. They’re great for strategic thinking, vendor awareness, and peer lessons, but you still need formal courses for deep technical competence. Treat episodes as ongoing professional development that points you to tools and training to follow up on. Combine podcasts with workshops, vendor training, and certifications for a rounded program. ## How do I pick the best episodes quickly? Scan episode descriptions and listen to chunks using playback speed controls to find value fast. Prioritize episodes with guests who match your role: CEOs for pricing, engineers for rollouts, CISOs for security architecture. Subscribe to show newsletters or follow hosts on social channels for curated highlights. Create a shared playlist for your team so others can flag must-listen segments. ## Which shows are top picks for MSP leadership? Look for leadership and marketing shows that include case studies, sales scripts, and operational templates. These programs highlight how to retain clients, increase recurring revenue, and build a team that scales. Palisade often appears on the guest list discussing how security services tie to profitable MSP offerings. Use those discussions to refine your managed detection and response packages. Apply insights immediately: test one new pricing model or automation in a controlled pilot. ## What are good podcasts for technical teams? Choose podcasts offering step-by-step product demos, scripting examples, and incident breakdowns. These shows help tech teams adopt new tools faster and avoid common configuration pitfalls. Encourage junior staff to summarize episodes and present short demos. This turns listening into active learning. Use episode transcripts to create internal SOPs and runbooks for recurring tasks. ## How can I use podcasts as a sales enablement tool? Share episodes that showcase customer wins or explain pain points your services solve to prime prospects. Use clips as conversation starters in discovery calls to build credibility and open doors for deeper demos. Recommend episodes to prospects as pre-meeting homework to elevate discussions and save demo time. Embed short clips into proposals or onboarding to reinforce best practices. ## Top 14 shows MSPs should consider ## Quick Takeaways ## Frequently Asked Questions ### How many podcasts should an MSP team follow? Follow 2–4 core shows across leadership, security, and technical tracks to cover priorities without overload. Rotate additional niche episodes as needed. Use playlists and team recommendations to surface the best content. Align listening with monthly goals so episodes feed actionable plans. ### Are there podcasts that focus only on cybersecurity for MSPs? Yes: some shows are dedicated to cyber risk, incident response, and vendor tools tailored to MSPs. Seek episodes with post-incident analysis and interviews with security practitioners. Palisade contributes to discussions that help MSPs align MDR and EDR with service delivery. Use these shows to refine detection rules and response playbooks. ### Can podcasts help with technical onboarding? Podcasts can accelerate onboarding by exposing new hires to product comparisons, common pitfalls, and demo walkthroughs. Pair episodes with hands-on labs to cement learning. Ask new team members to present episode summaries to validate comprehension. That practice makes listening active rather than passive. ### What’s the best way to share useful episodes with my team? Create a shared playlist, clip highlights, and add episode notes to your internal wiki. Assign short presentations to teammates who listened to an episode to spread knowledge. Integrate recommendations into weekly meetings or training sessions to reinforce application. Track which episodes led to measurable changes. ### How do I measure ROI from podcast listening? Measure ROI by tracking actions taken after episodes: new processes, improved close rates, reduced incident response times, or automated workflows. Set small pilots to test ideas and compare metrics before and after implementation. Assign owners to convert episodes into experiments so outcomes are measurable. ## Related reading - Which RMM solutions should MSPs choose in 2025? - [Which newsletters should MSPs read to grow sales and security?](/learning/msp) - [Which YouTube channels should MSPs subscribe to?](/learning/msp) --- # How can MSPs drive sales without a dedicated sales team? Canonical: https://www.palisade.email/learning/how-can-msps-drive-sales-without-a-dedicated-sales-team > Owner-led outreach, simple messaging, and an automated prospect funnel help MSPs grow without a dedicated sales team. Practical steps and quick wins. Short answer: MSPs can grow revenue by simplifying their message, having owners lead early outreach, and building a lightweight, automated prospect funnel that converts. These steps cut cost, speed up learning, and create a repeatable sales playbook you can hand off later. Below are 12 focused questions and concise answers to help IT leaders implement these tactics quickly. MSP growth illustration (generated image stored in Palisade assets) ## What is the fastest way for an MSP to start selling without hiring a salesperson? Lead: Begin with owner-led outreach and one clear offer. Owners should send short, direct messages that aim to book a 15–20 minute conversation rather than close a sale immediately. Use replies to learn common objections and refine your outreach script. Track responses in a simple spreadsheet so you can convert what works into repeatable templates. This approach validates demand before you hire. ## Why simplify your brand message first? Lead: A clear value statement reduces confusion and increases trust in seconds. Use a one-line “who-do-get” sentence that tells prospects who you help, what you do, and the outcome they receive. Avoid technical jargon and emphasize measurable outcomes like less downtime or lower security risk. Simple messaging also makes it easier to onboard future salespeople. ## How do you write a one-line value statement that converts? Lead: Focus on client, service, and benefit: “We help [who] with [what] so they get [benefit].” Keep it under 15 words and test variations on your site headline and email openers. Measure which version drives clicks or replies, then standardize the winner across channels. Localizing the line (e.g., mentioning your city) can increase relevance. ## What should owners say in their first outreach emails? Lead: Keep it short and ask one clear question that invites a reply. Example: “Are you actively looking for outsourced IT that reduces downtime?” Offer a 15–20 minute call as the next step. Short, targeted messages get higher reply rates and faster feedback. Use returned answers to adjust your qualifying criteria and scripts. ## How can automation support a small MSP sales process? Lead: Automation maintains professionalism and moves prospects through the funnel without extra headcount. Use scheduling links, automated confirmations, and two reminders (24 hours and one hour before) to reduce no-shows. Automations free owners for the conversations that matter and ensure consistency. Start small and expand sequences as you scale. ## What does a simple appointment funnel look like? Lead: A basic funnel has a clear CTA, scheduling, confirmation, reminders, and a pre-call checklist. Drive visitors to a “Schedule a Call” button, capture basic qualifying info, and trigger an immediate confirmation email. Send prep notes and reminders before the meeting and define the next step after the call (proposal, trial, or demo). This keeps prospects engaged and sets expectations. ## How do testimonials and case studies help when you don’t have a sales team? Lead: Social proof shortens the decision process and reduces skepticism. Place short, specific case results and client quotes near your CTA to reassure visitors. Highlight numbers and timelines (e.g., “Reduced downtime by 45% in 3 months”) to make outcomes tangible. Relevant examples build credibility without a pushy salesperson. ## When is it time to hire a salesperson? Lead: Hire when demand is predictable and your process is repeatable. Signals include steady appointment flow, reliable conversion rates, and the ability to forecast revenue. Use owner-led outreach to refine your ideal client profile and hand over a tested script. Hiring too early can waste budget; wait until you have a playbook to scale. ## How can MSPs measure sales performance without a complex CRM? Lead: Track a handful of metrics: appointments booked, call-to-proposal ratio, close rate, and average deal size. A simple spreadsheet or lightweight CRM is enough initially. Review results weekly and double down on channels that produce meetings and closes. Focus on metrics tied to revenue so adjustments are actionable. ## What role does responsiveness play in closing deals? Lead: Fast replies signal professionalism and increase engagement. Aim to acknowledge inquiries the same business day and schedule follow-ups quickly. Use automation for confirmations and quick human responses for questions. Speed differentiates small teams and builds trust with prospects. ## Can content and local targeting replace a sales team? Lead: Targeted content combined with local outreach can generate qualified leads without hiring. Publish short, outcome-focused pages or emails that solve local pain points and promote them via email, local ads, or referrals. Pair content with a clear CTA and a short form to convert interest into scheduled calls. This builds a pipeline that owner-led outreach can manage. ## What are the first three actions MSPs should take this week? Lead: Do three things: simplify your headline, send five short owner-led outreach messages, and add a visible “Schedule a Call” CTA to your site. Track replies, tweak wording, and set up basic confirmations and reminders. Repeat weekly until you have a standard process you can scale or hand off. ## Quick Takeaways - Lead with a concise value statement that explains who you help and the benefit. - Owners should run initial outreach to learn fast and refine messaging. - Automate scheduling and reminders to reduce no-shows and save time. - Measure a few key metrics to validate what drives revenue before hiring. - Show short case results near CTAs to build trust without a salesperson. ## FAQs ### Do I need a professional website to start? Short answer: No. A clear, usable page with a strong headline, CTA, and contact options is enough to start testing outreach and funnels. ### How long until I see results from owner-led outreach? Short answer: Often within days to a few weeks, depending on outreach volume and follow-up consistency. Regular outreach leads to faster improvements. ### What if I don’t want to do sales outreach myself? Short answer: You can hire a part-time contractor or consultant, but keep owners involved to review messaging and outcomes. Owner input speeds learning and keeps the strategy aligned with business goals. ### How much automation should I use? Short answer: Start small (scheduling links, confirmations, and two reminders) and add more only when needed. The goal is to save time for conversations, not to replace them. ### Where can I find templates and guides for MSP growth? Find practical templates and guides at Palisade: [MSP growth strategies](/). ## Related reading - [How can MSPs run a results-driven Quarterly Business Review (QBR)?](/learning/how-can-msps-run-results-driven-qbr-a8ad9) - How do you sell an MSP and maximize your exit valuation? - [How should MSPs build an effective disaster recovery plan?](/learning/how-should-msps-build-an-effective-disaster-recovery-plan) --- # How can MSPs build a business plan that drives sustainable growth? Canonical: https://www.palisade.email/learning/msp-business-plan-blueprint-growth > Step-by-step Q&A for MSPs building a pragmatic business plan: market focus, service packaging, pricing, and the metrics that drive predictable growth. Start with a simple, measurable roadmap that aligns services, pricing, and operations with growth goals. A clear plan reduces reactive firefighting and turns client wins into repeatable revenue. This guide takes an FAQ approach so leaders can scan for the exact guidance they need. ![Blueprint for MSP growth](/images/cms/68df3981f645aa7531bdd59c_img-s5dhwwzvyxjxvfmkf8t2vuvw.png) ## 1. What is the purpose of an MSP business plan? It provides a focused framework to grow profitably and scale operations. A plan captures your target clients, service lineup, pricing logic, and measurable goals so every decision ties back to growth targets. For MSPs that struggle with inconsistent revenue and churn, the plan turns reactive choices into a repeatable strategy. Use it to align team responsibilities and set realistic timelines. ## 2. What sections should an MSP business plan include? Include market analysis, offerings, pricing, sales channels, operations, team plan, and financial projections. Each section should answer who you serve, what you sell, and how you deliver value consistently. Financials must model recurring revenue, gross margin, and cash flow to spot funding needs early. Keep sections short and data-driven so the plan stays usable. ## 3. How do I define my ideal client profile (ICP)? Start with the clients where you already deliver measurable outcomes and the highest margins. Define ICP by industry, company size, tech stack, and pain points, for example, mid-market firms using cloud-first infrastructure with weak patching. Prioritize prospects who match your strengths; targeting everyone dilutes sales effectiveness. Use CRM data and win/loss reviews to refine your ICP quarterly. ## 4. How should MSPs price services for growth? Lead with predictable, subscription-based pricing that reflects value and total cost-to-serve. Bundle services into clear tiers (basic, standard, premium) and calculate unit economics per seat or endpoint. Aim for recurring gross margins above 60% where possible and model churn impact in forecasts. Test pricing on small segments before full rollout. ## 5. What role does cybersecurity play in the plan? Cybersecurity is a core revenue driver and a trust signal for clients. Position managed detection, endpoint protection, and vulnerability management as premium services that reduce client risk and increase retention. Consider partnering with Palisade for AI-driven security services to scale protection and win higher-value contracts: [AI-powered cybersecurity for MSPs](/). Make security part of your standard offer to differentiate. ## 6. How do I build a repeatable sales process? Create a simple funnel with defined stages, messaging, and close benchmarks. Map outbound sequences, referral programs, and partner channels, and assign clear owners for each stage. Measure conversion rates and deal velocity to identify friction points and coach reps effectively. Invest in one reliable lead source rather than chasing many low-quality channels. ## 7. How can MSPs reduce churn? Start by delivering measurable outcomes and regular client check-ins. Use onboarding playbooks, SLA tracking, and quarterly business reviews to show value and surface issues early. Price renewals to reward long-term commitments and offer upgrade paths tied to outcomes. Track NPS and churn reasons to create action plans for at-risk accounts. ## 8. What operational changes support scaling? Standardize onboarding, documentation, and runbooks to reduce tribal knowledge and speed delivery. Automate repetitive tasks such as patching, ticket triage, and billing to free technical staff for higher-value work. Define capacity metrics (tickets per tech, endpoints per tech) and hire before capacity drops. Use metrics to trigger hiring, not intuition. ## 9. How should MSPs plan hiring and team structure? Hire around capability gaps that limit growth: sales, onboarding, engineering, and customer success. Define roles with measurable outputs (e.g., new ARR per seller, mean time to resolve for engineers). Consider contractors for short-term projects and invest in cross-training to reduce single points of failure. Create career paths to retain high performers. ## 10. How do I forecast revenue and cash flow? Model recurring revenue, churn, upgrades, and one-time services separately. Use conservative assumptions for churn and sales velocity, and build monthly cash-flow projections for 12–18 months. Include hiring and marketing spend as line items so funding needs are visible. Revisit forecasts monthly and update assumptions with actuals. ## 11. When should an MSP seek outside funding or partners? Consider external funding when growth is constrained by capital, for example, when demand outpaces hiring capacity or you need product investment. Strategic partnerships can accelerate go-to-market or add capabilities without heavy upfront spend. Make sure any funding preserves operational discipline and ties to clear ROI milestones. Use partners to fill capability gaps rather than core competence. ## 12. How often should I review and update the plan? Review the plan at least quarterly, and update key assumptions when major changes occur. Use monthly dashboards to track KPIs and trigger deeper strategy sessions when targets drift. Treat the plan as a living document: keep it concise and action-oriented so stakeholders actually use it. Small, frequent adjustments beat infrequent big rewrites. ### Quick Takeaways ### Frequently Asked Questions #### Q: How long should a practical MSP business plan be? A: A concise plan (8–15 pages or a one-page executive roadmap plus appendices) is usually enough. Focus on actionable sections: ICP, offerings, pricing, ops, and financials. Avoid overplanning; the goal is clarity and execution. Keep appendices for detailed models and SOPs. #### Q: Can small MSPs use the same plan as larger firms? A: The structure is the same, but scale the assumptions and hiring timelines to match capacity. Small MSPs should prioritize high-margin niches and automation before hiring aggressively. Tailor sales and service tiers to buyer budgets and expected deal size. #### Q: What KPIs should MSP leaders track monthly? A: Track MRR/ARR, churn rate, gross margin, average revenue per customer, tickets per tech, and pipeline conversion. These metrics show financial health and operational capacity. Use them to trigger hiring or pricing changes. #### Q: How do I price one-time projects versus recurring services? A: Price one-time projects to cover labor and margin while keeping them complementary to recurring offerings. Avoid relying on project revenue for core operations; aim to convert projects into subscriptions where possible. Use projects for strategic upsells and renewals. #### Q: Where can I get help implementing security at scale? A: Partnering with a platform like Palisade can speed deployment and provide AI-driven protection that scales with your client base: [https://palisade.email/](/). Look for solutions that integrate into your RMM and ticketing systems to reduce overhead. ## Related reading - [How can MSPs create sales presentations that win more deals?](/learning/msp) - [Which MSP conferences and events should you attend in 2024?](/learning/msp) - Which MSP events and conferences should you attend in 2025? --- # How long should organizations retain EDR data for investigations? Canonical: https://www.palisade.email/learning/howlongshouldorganizationsretainEDRdata > How long to keep EDR data: vendor defaults (14-30 days), what PCI DSS and HIPAA require, and how to size retention to real attacker dwell times. Keep raw EDR telemetry searchable for at least 90 days, and keep alerts, incident records, and exported forensic artifacts for at least 12 months. Vendor defaults are much thinner: [Microsoft Defender XDR](https://learn.microsoft.com/en-us/defender-xdr/advanced-hunting-overview) lets you query only 30 days of raw data, and [SentinelOne's Singularity Complete package](https://www.sentinelone.com/platform-packages/) includes 14 days. Mandiant's [M-Trends 2026 report](https://cloud.google.com/blog/topics/threat-intelligence/m-trends-2026/) puts global median attacker dwell time at 14 days, and [25 days when someone outside the organization spots the breach](https://www.helpnetsecurity.com/2026/03/24/mandiant-m-trends-2026-report/). If your retention window is shorter than the time attackers spend inside networks, the evidence is gone before the investigation starts. Regulated environments need more: [PCI DSS requires 12 months of audit log history](https://explore.kirkpatrickprice.com/videos/pci-v4-0-10-5-1-retain-audit-log-history-for-at-least-12-months). ## What counts as EDR data? EDR (endpoint detection and response) tools record what happens on every device they protect: process launches, file changes, network connections, registry edits, and logon events. Retention is simply how long that record stays stored and searchable. Two jobs depend on it. Threat hunters query history to find attacks that slipped past real-time detection rules. Incident responders rebuild timelines to find patient zero and scope the damage. Once the retention window lapses, purged telemetry cannot be recovered, a [digital forensic analyst](/learning/threats) can only work with what you kept. The same logic applies to [server and application logs](/learning/threats), but endpoint telemetry is the highest-volume, most expensive slice, which is why vendors cap it aggressively. ## How long do major EDR vendors keep data by default? Shorter than most people assume. Here are the published windows as of mid-2026: | Platform | Included searchable window | Extended options | | --- | --- | --- | | Microsoft Defender XDR | [30 days of raw data in advanced hunting](https://learn.microsoft.com/en-us/defender-xdr/advanced-hunting-overview); [alerts and incidents kept 180 days](https://learn.microsoft.com/en-us/defender-xdr/data-privacy) | Stream tables to Microsoft Sentinel or a data lake tier for longer windows | | SentinelOne | [14 days in Singularity Complete; 90 days in the Commercial and Enterprise tiers](https://www.sentinelone.com/platform-packages/) | Longer retention is sold by package tier | | CrowdStrike Falcon | Short included window that varies by subscription | [Falcon Search Retention](https://www.crowdstrike.com/wp-content/uploads/2024/01/Falcon-Search-Data_Retention_V2.pdf) stores platform data "for months or years" via license upgrade; [Falcon Long Term Repository](https://www.crowdstrike.com/en-us/blog/getting-started-with-falcon-long-term-repository/) advertises a year or longer | Two details catch teams out. First, "retention" runs on two clocks: Microsoft keeps alerts and incidents for 180 days while the raw hunting data behind them disappears after 30. Second, extended retention only collects going forward. Microsoft's docs state that streaming-API retention "starts from the first day that you implement and enable the streaming API", so turn it on before you need it, not during an incident. ## Why are default retention windows too short? Because attackers routinely outlast them. The [M-Trends 2026 report](https://cloud.google.com/blog/topics/threat-intelligence/m-trends-2026/) measured global median dwell time at 14 days, up from 11 the year before. A median means half of all intrusions run at least that long. Organizations that found intrusions themselves did so in [about 9 days, but breaches reported by an external party sat for a median of 25 days](https://www.helpnetsecurity.com/2026/03/24/mandiant-m-trends-2026-report/), and espionage and North Korean IT-worker cases ran a median of 122 days. The joint CISA, NSA, FBI, and ACSC guidance on [event logging and threat detection](https://www.cisa.gov/news-events/cybersecurity-advisories/aa24-234a) makes the same point: default retention periods are often insufficient, some incidents take up to 18 months to discover, and some malware dwells 70–200 days before causing overt harm. It recommends setting retention from a risk assessment, keeping logs "long enough to support cybersecurity incident investigations." There is a second reason to retain data off-platform: attackers target the record itself. Techniques that blind or tamper with EDR agents can leave gaps in live telemetry, so an independent archive is often the only clean copy. Longer, intact history also directly improves [how fast your team can scope and respond to incidents](/learning/how-quickly-should-your-security-team-respond-to-incidents-mttr-explained). ## What do compliance frameworks require? No regulation names "EDR" specifically, but several set floors for security records that EDR data falls under: | Framework | Retention expectation | | --- | --- | | PCI DSS 4.x, Requirement 10.5.1 | [Retain audit log history at least 12 months, with the most recent 3 months immediately available](https://explore.kirkpatrickprice.com/videos/pci-v4-0-10-5-1-retain-audit-log-history-for-at-least-12-months) | | HIPAA Security Rule | No explicit log number, but [required documentation must be kept 6 years](https://www.law.cornell.edu/cfr/text/45/164.316) (45 CFR 164.316), and auditors commonly apply that bar to security activity records | | US federal agencies | OMB M-21-31 required [12 months active plus 18 months cold storage](https://aws.amazon.com/blogs/publicsector/aws-federal-customers-memorandum-m-21-31/); it was [rescinded in May 2026 by M-26-14](https://www.whitehouse.gov/wp-content/uploads/2026/05/M-26-14-Ensuring-Effective-and-Efficient-Agency-Logging-and-Network-Visibility-to-Defend-Against-Evolving-Cyber-Threats.pdf), which shifts agencies to [risk-based, prioritized logging](https://federalnewsnetwork.com/cybersecurity/2026/05/omb-revamps-cyber-event-logging-requirements/) | | CISA/ACSC joint guidance | Risk-informed; logs kept "long enough to support cybersecurity incident investigations" | Note the federal shift: M-26-14 dropped the blanket 30-month mandate because keeping everything proved expensive with little payoff, not because long retention stopped mattering. The replacement still expects agencies to justify windows against risk. That is a sensible model for MSPs too: for healthcare clients, start from [what HIPAA actually requires](/learning/threats); for anyone touching card data, PCI DSS applies (the same version that now [expects DMARC-style anti-phishing controls](/learning/does-pci-dss-4-0-require-dmarc)). ## What retention schedule should you actually set? A tiered policy covers most organizations without runaway cost: 1. **Raw telemetry, hot and searchable: 90 days.** This covers the 14-day median dwell time with real margin, including the 25-day median for externally discovered breaches. 2. **Alerts, detections, and incident timelines: 12 months minimum.** These are tiny compared to raw telemetry and satisfy the PCI DSS 12-month expectation. 3. **Closed-incident exports: keep with the case file.** When an investigation ends, export the process trees, timelines, and artifacts into your case archive rather than relying on platform retention. 4. **Regulated clients: match the strictest applicable framework**, and put the number in the service agreement so nobody discovers a gap during an audit. 5. **Review annually.** Dwell times, prices, and regulations all moved in the last two years; your policy should too. If a client uses a [managed detection and response service](/learning/threats), confirm whose retention applies. The MDR provider can only search as far back as the underlying platform license allows. ## How can you extend retention without blowing the budget? Full-fidelity telemetry across thousands of endpoints is expensive to keep hot, so spend where you actually query: - **Buy vendor retention only for the data you search often.** Upgrading alert retention is cheap; upgrading raw telemetry is not. - **Stream to storage you control.** Defender's streaming API, Sentinel data lake tiers, and CrowdStrike's license-based extensions all exist because 30 days is rarely enough. Cold object storage is fine for data you touch once a year. - **Prune by value, not by age alone.** Keep process trees and authentication events longer than bulk noise like routine system events. - **Test restores quarterly.** An archive you cannot restore, or that arrives without timestamps and hashes intact, is not evidence. ## Where does email security data fit in? Phishing remains one of the most common ways attackers get in, and when an intrusion arrives by email, endpoint telemetry only tells the second half of the story. EDR records what happened after compromise; email authentication data records what was attempted against your domains. DMARC aggregate reports ([RUA](/learning/what-is-a-rua)) arrive daily, cost almost nothing to store, and show when spoofing attempts started. Useful context when you are trying to date an intrusion. Palisade's [DMARC monitoring](/tools/dmarc) keeps that report history for MSPs so the lookback is there when an investigation needs it. Be clear about limits, though: DMARC stops exact-domain spoofing, not lookalike-domain phishing, and it holds no endpoint evidence. Email records complement EDR retention; they do not replace it. ## Common issues **The incident surfaced after the telemetry was purged.** Check the longer-lived tiers first: Defender keeps alerts and incidents 180 days even though raw hunting data lasts 30, and your SIEM or firewall logs may cover the gap. Then fix the policy: extend the window and enable streaming now, because extended retention starts collecting only from the day you turn it on. If you are mid-breach, follow a structured plan for the first 24 hours. **Historical searches crawl or time out.** Defender advanced hunting caps each query at a 30-day range, 10 minutes of runtime, and 100,000 result rows. Break long lookbacks into slices, filter by device or user early in the query, and run archive-tier searches in the archive tool rather than the live console. **A lapsed or switched license deleted the history.** Microsoft deletes tenant data no later than 180 days after contract termination, and it is unrecoverable after that. Export open cases and key artifacts before any migration, and write offboarding exports into client contracts so departing customers keep their evidence. **The archive exists but will not hold up as evidence.** Hash exports when they are created, restrict and log access to the archive, and preserve original timestamps and event IDs. A short chain-of-custody runbook written now saves an argument with lawyers later. ## Frequently asked questions ### Is 30 days of EDR data ever enough? Only for genuinely low-risk environments. With a 14-day median dwell time, half of intrusions run two weeks or longer, and externally discovered breaches sat a median of 25 days, uncomfortably close to a 30-day cliff. If budget forces a short raw window, pair it with 12 months of alert and incident retention, which is far cheaper. ### Does keeping telemetry longer create privacy problems? It can. Endpoint telemetry captures user behavior, so privacy laws require you to justify how long you hold it and who can see it. Document the security purpose, restrict access to the archive, and purge on the schedule your policy states, indefinite "just in case" retention is a liability, not a safety net. ### Should MSPs set the same retention for every client? No. Tier it: a baseline window for low-risk clients, 12-month alert retention for everyone, and extended raw retention for regulated or high-risk clients who need it. Put the numbers in each service agreement, and revisit them at renewal. Retention is one of the easiest security levers to price transparently. ### Does DMARC reporting need the same retention treatment? DMARC aggregate reports are small enough that keeping a year or more costs little, and the history shows when spoofing campaigns against a domain began. But it is a different evidence layer: DMARC data cannot reconstruct endpoint activity, and EDR data cannot show who tried to forge your domain. Investigations go faster when you retain both. --- # How can attackers exploit OAuth device code login? Canonical: https://www.palisade.email/learning/device-code-flow-exploitation > How attackers exploit Device Code flow, what risks that creates, and practical mitigations for security teams. Attackers persuaded employees to complete a legitimate device-based login, handing over valid tokens that granted access without a password. They used social engineering to send short codes and a login link so the victim would enter the code on a browser and approve the session. Once approved, the attacker received tokens and used APIs to read mail, find credentials, and spread further messages inside the organization. In some cases they registered a device to snatch a Primary Refresh Token (PRT) and stayed authenticated for months. This technique is stealthy because it uses normal authentication endpoints and can evade controls that watch for password failures or unusual sign-in errors. ![Device Code Flow Exploitation illustration](/images/cms/68df0b79a20e83fd74f68e9d_img-ttyeecd8gsjawspncbcgcbbt.png) ## 10–15 Questions: Clear answers security teams can action ### 1. What is the Device Code flow? The Device Code flow is an OAuth pattern that lets users authenticate a device or app that lacks a browser by entering a short code on a separate trusted device. It separates the token request from the user interaction so a headless client can get tokens after the user approves the code on another device. This is common in CLIs, IoT appliances, and automation scripts, and integrates with MFA in many environments. It’s designed for convenience and accessibility but also creates a different attack surface than browser-based logins. Administrators should treat these flows as high-value and monitor their use closely. ### 2. How do attackers abuse this flow? Attackers abuse the flow by initiating a legitimate device authorization and baiting a user to enter the displayed short code in their browser, effectively granting access to the attacker. Because approvals happen on a separate device, the user may believe they are completing a benign action. After approval the attacker receives tokens that can be exchanged for API access and refresh tokens. They can then read mail, enumerate contacts, and send more convincing phishing messages from within the organization. The campaign becomes self-sustaining if the attacker can register devices or obtain refresh tokens for persistent access. ### 3. What immediate signs indicate device code abuse? Top indicators are unexpected device authorization requests tied to legitimate sign-in endpoints and approvals from unfamiliar devices or locations. Look for short-code approvals without an accompanying interactive browser session from the originating client, and API calls that suddenly appear on accounts that normally don’t use headless logins. Suspicious mailbox searches or mass forwarding rules are also red flags. Audit logs that show token issuance via a device code grant should be investigated, especially if followed by mailbox reads or token refresh actions. Rapid propagation of similar messages inside the tenant is another clear signal. ### 4. Can Multi-Factor Authentication stop this attack? MFA reduces risk but does not fully block device code abuse because the user still explicitly approves the login during authentication. When a user completes the MFA step in their browser, the attacker benefits from that legitimate approval. MFA helps when combined with contextual policies that block authorizations from risky devices or locations, and when paired with detection for unusual token issuance. Relying on MFA alone is insufficient; controls must also examine how tokens are requested and used. Implement session and device risk checks to raise the bar. ### 5. How do attackers get persistent access after the initial approval? Attackers obtain refresh tokens or register a device to secure a Primary Refresh Token (PRT), which allows them to refresh access tokens without user interaction. With refresh capability they can maintain continuous access even after the initial token expires. Some adversaries create a registered device record to appear as a trusted authentication method, making detection harder. Monitoring for newly registered devices and unusual refresh token grants is essential. Requiring device management enrollment or policy checks can prevent unmanaged devices from obtaining long-lived tokens. ### 6. What monitoring should we enable to detect this abuse? Enable logging of device authorization grant events, token issuance by grant type, device registrations, and refresh token activity. Correlate those events with mailbox access patterns, API calls, and anomalous message sends. Configure alerts for short-code approvals and for sudden spikes in token refresh or email reads. Maintain baseline behavior profiles so deviations (like headless client activity on user accounts that never use them) are flagged. Regularly review audit logs for device grant events and investigate unusual sequences. ### 7. Which controls can stop the attack before it succeeds? Preventive controls include limiting which apps can request device codes, enforcing conditional access on device-grant flows, and blocking unmanaged device registrations. Implement application consent policies and restrict third-party clients from using device auth where possible. Use conditional access to require compliant or hybrid-joined devices and to deny access from risky locations. Educate users to refuse unexpected short-code requests and establish reporting paths for suspicious messages. ### 8. How should incident responders handle a confirmed compromise? First, revoke active tokens and refresh tokens for affected accounts and remove any registered attacker devices. Next, rotate credentials for service principals and applications that may have been accessed and inspect mailboxes for data theft or forwarding rules. Use mailbox audit logs to map what the attacker read and whom they targeted, then notify impacted parties. Finally, harden policies around device grants and apply tenant-wide controls to prevent recurrence. Consider a full tenant sweep to find additional accounts used as pivots. ### 9. Are there configuration changes that reduce attack surface? Yes: disable device code grants for high-risk applications, restrict app permissions, and enforce strict conditional access on grant flows. Require device enrollment or block legacy authentication methods where feasible. Limit API scopes to least privilege and use app consent restrictions to stop unauthorized clients from requesting tokens. Regularly review and remove stale app registrations and OAuth permissions. Applying these configuration changes lowers the chance an attacker can receive usable tokens. ### 10. How does user training help prevent these attacks? User training helps by teaching staff to recognize token-phishing patterns and to never approve unexpected device-login prompts. Simulated phishing exercises that include device code scenarios make users more likely to spot social engineering. Provide simple rules: do not enter codes received unexpectedly, verify the sender via a second channel, and report suspicious requests immediately. Combine training with technical controls to create a layered defense. Clear escalation procedures speed containment when an incident occurs. ### 11. What role does application consent play in this threat? Unchecked application consent lets attackers use legitimate clients to request device authorization and get tokens without administrator oversight. Tightening consent policies ensures only approved apps can request high-risk scopes and prevents malicious clients from obtaining access. Admin consent workflows, tenant-wide restriction of third-party consent, and regular consent reviews reduce the chance an attacker will leverage a compromised or rogue app. Monitor consent grants and revoke unnecessary approvals promptly. This reduces the pathways attackers can use to start a device code session. ### 12. How can automation and scripts be secured? Secure automation by using managed identities, short-lived certificates, or service principals with tightly scoped permissions instead of interactive device grants. Where device login is unavoidable, enforce machine identity checks and store any client credentials in a hardened secrets store. Audit automated clients for unexpected behavior and restrict their ability to request refresh tokens. Use least-privilege roles and rotate secrets regularly to minimize impact from a leaked token. Combine these practices with continuous monitoring for abnormal token activity. ## Quick Takeaways ## Five common FAQs ### Q: Is this attack common? A: Variants have been observed in targeted campaigns against critical sectors, and the pattern is rising because it exploits normal authentication flows and user trust. Attackers value it for low friction and high payoff, especially when they can pivot using mail access. Organizations that don’t monitor device grants are especially vulnerable. Tracking these events and educating users reduces incidence. Treat device code approvals as high-risk events. ### Q: Can we block device code flow entirely? A: Blocking is possible for many tenants and applications, but it may break legitimate tooling that relies on device auth, like CLIs or IoT devices. Assess usage to identify which apps truly need it and disable it for the rest. When blocking isn’t feasible, apply strict conditional access and app restrictions to reduce risk. Consider alternative secure methods for automation where possible. Communicate changes to teams before enforcement. ### Q: How fast should we act after detecting an approval we didn’t expect? A: Act immediately: revoke affected tokens, remove any registered devices, and investigate mailbox actions within hours. The attacker can move quickly with granted tokens, so timelines matter. Preserve logs for forensic analysis and notify impacted users and teams. Apply tenant-level mitigation while investigating to prevent broader spread. Speed and coordination reduce damage and recovery time. ### Q: What logging sources are most useful? A: Key sources include device authorization event logs, token issuance logs, identity protection signals, mailbox access logs, and API call traces. Correlating these provides the timeline and scope of access. Ensure logs are retained long enough for investigation and fed into SIEM or threat-hunting workflows. Alerts should trigger on anomalous sequences, not just isolated events. Regularly test log quality and visibility for these events. ### Q: Where can I get a step-by-step checklist to harden my tenant? A: Start with a focused device code hardening checklist that covers app consent policies, conditional access for device grants, token revocation procedures, and monitoring rules. Review your app registrations and third-party consent policies, enforce device compliance, and tighten refresh token lifetimes. Palisade offers practical resources and guidance to secure authentication flows. See our device code flow prevention checklist for steps you can start applying today: [Device code flow prevention checklist](/). ## Related reading - [What are the different types of penetration testing?](/learning/threats) - [How can DNS poisoning redirect traffic and what stops it?](/learning/dns-poisoning-redirects-prevention) - [How can small businesses dodge cyber traps during Black Friday sales?](/learning/threats) --- # What trends should MSPs watch in 2025? Canonical: https://www.palisade.email/learning/what-trends-should-msps-watch-in-2025 > Top 2025 trends for MSPs: GenAI risks, identity-first security, AI-driven MDR, sales tactics, stack standardization, and automation. The MSP trends that matter in 2025 start with generative AI, which changes both how you run operations and what you have to defend. Alongside it: identity-first security replacing perimeter tooling, automation that removes ticket volume rather than adding dashboards, analyst burnout against a persistent talent gap, and clearer service packaging so security work is billed rather than absorbed. ## Top Questions MSPs Are Asking ### 1. What impact is Generative AI having on MSP operations and risk? GenAI is both a productivity multiplier and a new attack surface. MSPs can use it to automate documentation, speed ticket triage, and analyze logs, turning hours of work into minutes. But attackers are using the same capabilities to craft highly convincing phishing and social-engineering campaigns. That means MSPs must combine AI tools with layered email protections and frequent phishing simulations. Treat GenAI adoption as an ongoing program with guardrails, not a one-off tool deployment. ### 2. Why should MSPs adopt a user-centric security model? Putting identities first lets MSPs detect and contain incidents faster. Mapping alerts back to users and devices enables precise isolation, reducing lateral movement. This requires continuous visibility into access rights, device posture, and third-party connections. Clear user-linked context also makes risk communications easier for clients to understand and act on. Identity-aware policies are now a baseline defense against modern threats. ### 3. How is MDR changing the way MSPs defend clients? AI-driven MDR, tightly integrated with your stack, is the practical substitute for traditional outsourced SOCs. MDR platforms combine automated triage with human validation to reduce noise and speed remediation. The right MDR standardizes data across endpoints, cloud, and email so MSPs get contextual alerts and prioritized playbooks. Evaluate MDR vendors for integration depth and how much they reduce manual analyst workload. This approach delivers enterprise-grade detection to SMB clients at predictable cost. ### 4. What sales tactics will help MSPs win more deals? MSPs win when they sell outcomes, not feature sets. Define measurable KPIs (like uptime, reduced phishing click rates, or faster MTTD/MTTR) and weave them into your pricing conversations. Offer tiered packages and clear scope, plus case studies that prove business impact. Building repeatable sales assets and a growth playbook scales acquisition and shortens procurement cycles. Focused messaging about business outcomes beats technical detail in most buying committees. ### 5. How important is standardizing your technology stack? Standardization reduces complexity and improves detection across clients. A unified stack lets you correlate telemetry from endpoints, email, and cloud services, speeding investigations. Avoid custom one-off integrations that create maintenance overhead and tool sprawl. Choose platforms with open APIs and vendor-agnostic telemetry to future-proof operations. Consistency also enables automation and repeatable playbooks for faster onboarding. ### 6. What’s the role of endpoint posture checks in 2025? Continuous endpoint posture validation is essential. An unmanaged device is often the entry point for breaches. MSPs should monitor patch status, configuration drift, and application hygiene across devices. Automate remediation for common failures to shrink the exposure window. Combine posture checks with identity controls to significantly lower breach risk. Regular posture reporting helps clients see residual risk and justify investments. ### 7. How can MSPs address analyst burnout and the talent gap? Automation and AI-assisted workflows scale capability without growing headcount. Codify playbooks, automate repetitive triage steps, and let humans focus on high-impact incidents. Upskill staff with targeted training and certifications to reduce hiring pressure. Partnering with MDR platforms that offload routine tasks frees engineers for strategic work. Prioritizing employee experience reduces turnover and improves service quality. ### 8. Which pricing models will buyers prefer in 2025? Buyers gravitate toward outcome-based and tiered subscriptions that clarify ROI. Predictable flat-rate bundles remain attractive, but clients increasingly want SLAs tied to measurable outcomes. Offer base services with optional add-ons (advanced detection, backups, or compliance) so customers can scale. Transparent pricing and defined responsibilities reduce disputes and boost renewals. Pilot offers or short-term guarantees can accelerate adoption. ### 9. How should MSPs balance automation with human oversight? Automate routine detection and containment, and keep humans for validation and strategy. Over-automation risks missing nuanced indicators; under-automation keeps costs high. Use a layered approach: automated handling for common patterns, human review for ambiguous or high-risk events. Define decision points and escalations in playbooks to ensure consistent responses. This hybrid model maximizes efficiency and maintains accuracy. ### 10. What growth levers should MSPs prioritize now? Vertical specialization, packaged outcomes, and repeatable onboarding are the fastest paths to scale. Focus on industries or compliance needs where you can charge a premium and shorten sales cycles. Create a library of onboarding and remediation playbooks to speed delivery. Invest in marketing that highlights measurable results rather than technical features. Strategic partnerships and referral programs reduce CAC and accelerate growth. ## Quick Takeaways ## 5 FAQs ### Q1: Is GenAI more helpful or harmful for MSPs? GenAI is both an efficiency tool and a risk amplifier. Adopt AI to automate ticketing and log analysis while strengthening email and identity defenses. Run frequent phishing simulations and monitor for novel attack patterns. Standardize AI governance and track outcomes to manage risk. Plan AI adoption as a program with controls and reviews. ### Q2: Can small MSPs deliver enterprise-grade security with limited staff? Yes: by standardizing your stack and using AI-first MDR platforms to extend capability. Automation and repeatable playbooks reduce the need for large analyst teams. Outsource routine detection where it makes sense and keep strategic control in-house. The right MDR partner reduces noise and accelerates response. Focus on outcomes to compete effectively. ### Q3: When should MSPs start endpoint posture checks? Start immediately. Continuous posture validation should be a baseline offering in 2025. Prioritize patching, disk encryption, and common misconfigurations first. Automate fixes for frequent issues and report posture regularly to clients. Early posture checks prevent many common breaches and build trust. Make posture validation a standard onboarding item. ### Q4: What operational metrics prove MSP value? Track MTTD, MTTR, phishing click-rate reduction, and SLA adherence to show impact. Link those metrics to client outcomes like revenue continuity or compliance status. Use before-and-after case studies to demonstrate measurable gains. Regular reporting strengthens renewals and supports price adjustments. Quantified improvements win trust. ### Q5: Where can MSPs learn more about modern MDR and email security? Explore Palisade's resources for MDR and MSP security at [https://palisade.email/](/). Palisade offers guides and tools designed to help MSPs standardize their stack and scale securely. Start with vendor-neutral best practices and small pilots to validate impact. Use resources to compare MDR options and integrations. Adapted and rewritten to provide practical, action-oriented guidance for MSPs in 2025 aligned with Palisade's approach to managed security. ## Related reading --- # Which password manager is best for MSPs? Canonical: https://www.palisade.email/learning/which-password-manager-is-best-for-msps-to-streamline-operations > Choose the right password manager for your MSP: the features, integrations, and best practices that secure client credentials and speed daily operations. For MSPs, the best password manager centralizes client credentials in one place, enforces least-privilege access, and plugs into the RMM and PSA tools your technicians already work in, so credential hygiene stops depending on memory and copy-paste. Because [stolen credentials](/learning/threats) sit behind so many client breaches, the vault you pick is a security control, not just a convenience. ![Five steps for evaluating an MSP password manager: inventory credentials, require encryption and MFA, confirm integrations, enforce least-privilege access, then pilot](/images/figures/which-password-manager-msp-evaluation-flow.webp "1200x580") *Source: Palisade.* ## Quick Takeaways - MSP-focused password managers centralize client credentials to reduce risk and complexity. - Look for RMM and PSA integrations, role-based access, and automated password rotation. - Encryption (e.g., AES-256) and MFA are non-negotiable security features. - Activity logs and reporting simplify audits and compliance for multiple clients. - Automation saves time on routine tasks and lowers human error. ## Top Questions MSPs Ask ### 1. What makes a password manager suitable for MSPs? A solution fits MSPs when it provides centralized control, client-specific vaults, and delegated access so techs can work securely across multiple tenants. It must let you separate client data, assign role-based permissions, and scale as you add customers. Integration with your RMM and PSA tools shortens workflows and reduces context switching. Good reporting and audit trails are essential for compliance and client transparency. Finally, automation features (like password rotation and bulk onboarding) dramatically cut day-to-day administrative work. ### 2. How should MSPs evaluate security features? Prioritize end-to-end encryption and multi-factor authentication first; these prevent credential exposure even if servers are compromised. Check for strong encryption standards such as AES-256 and transparent handling of key material. Ensure the product supports MFA for both admin and technician accounts and offers session controls and IP whitelisting. Audit logs, immutable activity records, and tamper evidence are crucial for incident response. Also verify independent security assessments or certifications to back up vendor claims. ### 3. Do password managers integrate with RMM and PSA platforms? Many MSP-grade password managers ship built-in connectors or APIs for common RMM and PSA systems, which enables single-click access and automated ticket updates. Integration lets technicians launch remote sessions and retrieve credentials without leaving their operational console. This reduces manual steps and the risk of credential leakage from clipboard copying or insecure notes. When evaluating, confirm which specific RMM/PSA tools are supported and whether integrations are native or require additional configuration. Native integrations usually deliver the smoothest experience and predictable security behavior. ### 4. What access controls should an MSP enforce? Start with role-based permissions and the principle of least privilege, grant only the access required to complete a task. Use granular controls to limit which vaults or folders a technician can open and whether they can share or edit credentials. Enable time-limited access and just-in-time provisioning for high-risk systems. Require MFA for all users with elevated privileges and enforce strong password policies. Regularly review access rights and remove stale or unused accounts to shrink your attack surface. ### 5. How does automated password rotation help MSPs? Automated rotation reduces exposure by regularly replacing passwords and credentials, minimizing the window of opportunity for attackers. It removes the manual burden of changing shared passwords across clients and services, which is a common source of error. Rotation policies can be scheduled or triggered after specific events, such as a technician leaving. Combined with vaulting and auditing, rotation creates a defensible trail showing proactive credential hygiene. For sensitive systems, enforce tighter rotation intervals and stricter approval workflows. ### 6. Can MSPs securely share credentials with clients? Secure sharing is a core MSP capability when it runs through encrypted vaults with defined permissions. Use shared folders or one-off links that enforce read-only or temporary access rather than sending passwords via email or chat. The manager should log all sharing events and support revocation if needed. When clients need visibility, provide them limited, audited access to their vaults or reports. Avoid manual handoffs; rely on the tool’s secure channels to prevent accidental exposure. ### 7. What reporting and auditing features matter most? Look for activity logs that record who accessed which credential, when, and from which IP or device. These are essential during investigations. Compliance-exportable reports and customizable dashboards speed audits and client reporting. Alerts for unusual access patterns or failed MFA attempts help you detect potential compromises. The ability to generate per-client or per-technician reports simplifies billing and SLA verification. Immutable logs and exportable evidence are particularly important for regulated industries. ### 8. How does a password manager improve onboarding and offboarding? A good password manager streamlines onboarding by letting you import credentials in bulk, assign roles automatically, and apply templates for common client setups. For offboarding, it simplifies revoking access, rotating shared credentials, and auditing any lingering permissions. Automating these steps reduces human error and speeds client transitions. Use templates and policy presets to keep consistency across clients and maintain security baselines. Rapid, auditable offboarding reduces risk when technicians leave or contracts end. ### 9. What deployment models should MSPs consider? MSPs can choose cloud-hosted, self-hosted, or hybrid deployments depending on client needs and compliance requirements. Cloud options minimize maintenance and scale easily; self-hosted provides maximum control for sensitive environments. Hybrid setups let you separate highly regulated clients on private infrastructure while keeping others in the cloud. Evaluate backup, redundancy, and disaster recovery plans tied to each model. Factor in patching responsibility and the vendor’s security posture when deciding. ### 10. How do price and licensing affect MSP choice? Assess pricing per technician and per managed endpoint to understand total cost as you scale; some vendors charge per-seat while others bill per client. Look for predictable billing models and discounts for volume or bundled services. Consider feature tiers: advanced security or integrations may be in higher-priced plans. Factor in the time savings from automation and integrations when calculating ROI. Always run a pilot to test real-world usage before committing to a large deployment. ### 11. What user training and adoption strategies work best? Adopt a phased rollout: train a core team first, capture feedback, then expand across technicians and clients. Use short, focused training sessions and one-page cheat sheets for daily tasks. Encourage MFA and password vaulting for non-technical staff to reduce help-desk overload. Monitor adoption with usage reports and follow up on low adopters. Reward best practices and make the tool the default path for credential access to drive compliance. ### 12. Which vendors are commonly recommended for MSPs? Several vendors target MSPs with feature sets like multi-tenant vaults and RMM/PSA integrations; pick one that aligns with your stack and scale. Rather than naming specific competitors, evaluate providers on security, integrations, automation, and support responsiveness. Consider vendors that offer a clear MSP program with partner tools and migratio