Skip to content

Ward opens soon: join the waitlist and we'll email you the day we open.

What Ward checks

Area: Email

Email

Mail servers, SPF, DMARC, DKIM (common selectors), MTA-STS and TLS-RPT, and the risk of someone sending email pretending to be you. If you receive DMARC reports with Ward, it also flags new senders using your domain and SPF includes that no longer send anything.

What it can report

Open each one to see what it means and how to fix it.

No SPF record

What it means

SPF is a short note in your domain's DNS (the public settings that tell the internet where your website and email live). It lists the servers allowed to send email as @example.com. Your domain doesn't have one.

What could happen

Mail services like Gmail and Outlook can't tell your real emails from forged ones. Some of yours may land in spam, and fakes get through more easily. The people fooled are your customers and suppliers, and your name takes the blame.

How an attacker would use it

Someone sends one of your customers an invoice that appears to come from your address, with a different bank account on it. Nothing in your DNS tells the customer's mail service it's fake, so it reaches the inbox and the customer pays the wrong account.

How to fix it

  1. List every service that sends email as your domain.Your mailbox provider, plus invoicing, newsletters, CRM, online store or website forms.
  2. Build one SPF record with all of them. It starts with “v=spf1”, adds an “include:” entry for each service and ends with “-all”.Each service's help pages give its exact “include:” entry.
  3. At your DNS host, add it as a TXT record on the root of the domain (the name “@”).A domain can only have one SPF record. If one already exists, edit it instead of adding another.
  4. Send a test message to a personal Gmail account and check that it arrives normally.

How to check it's fixed

Mark the finding as “Pending verification” and Ward will check it again. DNS changes can take a few hours to spread, so if it still shows up, try again later.

Who usually fixes it

Your IT person

Example with sample data. In your dashboard, the explanation uses your own domain and details.

Duplicate SPF records

What it means

SPF is the list of servers allowed to send email as your domain, kept in your domain's DNS. The rules say there must be exactly one list, and your domain publishes two or more.

What could happen

Receiving mail services treat the setup as an error and ignore it, which is the same as having no SPF. Your legitimate emails can end up in spam, and forged ones aren't stopped.

How an attacker would use it

A scammer sends a fake invoice from your exact address. Your records cancel each other out, so the customer's mail service finds no valid list to check, and the fake gets through as easily as if you had no protection.

How to fix it

  1. In your DNS settings, find every TXT record that starts with “v=spf1”.
  2. Write down the services each one lists (the “include:” and “ip4:” entries).
  3. Create a single record that contains all of them and ends with “-all”.
  4. Delete the others so only one SPF record is left.Do it in one go: a gap between deleting and saving the new one leaves the domain unprotected.
  5. Save and send a test message to a personal Gmail account.

How to check it's fixed

Mark the finding as “Pending verification” and Ward will check it again. DNS changes can take a few hours to spread, so if it still shows up, try again later.

Who usually fixes it

Your IT person

Example with sample data. In your dashboard, the explanation uses your own domain and details.

SPF needs too many lookups

What it means

Your SPF record lists so many services that checking it takes more than 10 DNS lookups (questions asked to the internet's address book). The standard allows at most 10, and every “include:” counts, including the ones nested inside other services' lists.

What could happen

Past the limit, many mail services treat your SPF as broken. Your legitimate emails can then end up in spam or be rejected, and invoices or quotes may not reach your customers. It usually happens quietly after adding services over the years.

How an attacker would use it

A scammer forges an invoice from your address. Because your SPF is considered broken, the receiving service has no reliable list to compare it with, and your real messages and the fake get the same distrust. The fake works and the real ones get lost.

How to fix it

  1. List the services in your SPF (the “include:” entries) and tick the ones you still use.
  2. Remove the “include:” entries of services you no longer use.Old newsletter tools, previous mailbox providers and former CRMs are common leftovers.
  3. If you still need more, ask each remaining service whether it has a lighter SPF entry.
  4. As a last resort, replace a service by its fixed IP addresses (“ip4:”).Only if that service publishes stable addresses. Big providers change theirs without notice.
  5. Save the change and check that the new record stays within 10 lookups.

How to check it's fixed

Ward counts the lookups again at the next scan. Mark the finding as “Pending verification” and Ward will check it again. DNS changes can take a few hours to spread, so if it still shows up, try again later.

Who usually fixes it

Your IT person

Example with sample data. In your dashboard, the explanation uses your own domain and details.

SPF has syntax errors

What it means

Your SPF record (the list of servers allowed to send email as your domain) has formatting mistakes, such as a typo, a missing space or an entry that doesn't exist. The “technical details” show the record and the mistakes we found.

What could happen

Mail services can treat a badly written SPF as missing, or reject messages in unpredictable ways. Your legitimate emails may end up in spam, and forged ones aren't stopped as they should be.

How an attacker would use it

Someone sends a fake message from your address. Because the record can't be read properly, the receiving service has no reliable list to check, and the fake passes as easily as if you had no SPF at all.

How to fix it

  1. Open the technical details and read the mistakes listed under the record.
  2. Compare the record with your email provider's instructions for SPF.Providers publish the exact “include:” entry to use.
  3. Correct the record in your DNS settings.Common slips: spaces inside an entry, a missing “v=spf1” at the start, or two “all” endings.
  4. Make sure it ends with “-all” (or “~all” while you test) and that it is one single TXT record.
  5. Send a test message to a personal Gmail account and check that it arrives normally.

How to check it's fixed

Mark the finding as “Pending verification” and Ward will check it again. DNS changes can take a few hours to spread, so if it still shows up, try again later.

Who usually fixes it

Your IT person

Example with sample data. In your dashboard, the explanation uses your own domain and details.

SPF points to a list that doesn't exist

What it means

Your SPF record (the list of servers allowed to send email as your domain) refers to another list that doesn't exist or has no valid SPF of its own. When a mail service follows the reference, it hits an error.

What could happen

SPF checks that fail with an error are often treated as no protection at all. Part of your legitimate email may be flagged as suspicious or sent to spam, and the protection against forged messages is weaker than it looks.

How an attacker would use it

Someone forges a message from your address. The receiving service starts reading your SPF, stumbles on the broken reference and gives up, so it can't say the sender isn't allowed. The fake gets the benefit of the doubt.

How to fix it

  1. Check the “include:” entries listed in the technical details.
  2. Ask yourself whether you still use each service. If not, remove its “include:”.
  3. If you do use it, compare the entry with the service's current instructions.Providers sometimes change the address they publish; an old entry stops working.
  4. Correct or remove the entry in your DNS settings and save.
  5. Send a test message to a personal Gmail account and check that it arrives normally.

How to check it's fixed

Mark the finding as “Pending verification” and Ward will check it again. DNS changes can take a few hours to spread, so if it still shows up, try again later.

Who usually fixes it

Your IT person

Example with sample data. In your dashboard, the explanation uses your own domain and details.

SPF allows anyone to send (+all)

What it means

Your SPF record (the list of servers allowed to send email as your domain) ends in “+all”. That ending means “anyone is allowed”, so the list stops being a list.

What could happen

SPF protects nothing for your domain: any server on the internet passes the check when it sends email as you. It's one of the cheapest weaknesses to abuse and one of the cheapest to fix, so it deserves attention soon.

How an attacker would use it

Someone sends your customers a message as “accounting@” your domain asking them to confirm a payment. The customers' mail services check your SPF, read that anyone is allowed and let it through without a warning.

How to fix it

  1. In your DNS settings, open the TXT record that starts with “v=spf1”.
  2. Check that every service you use is listed with its “include:” or “ip4:” entry.
  3. Change the ending from “+all” to “-all”.If you aren't sure the list is complete, use “~all” for a few weeks while you check, then move to “-all”.
  4. Save and send a test message to a personal Gmail account to confirm your own email still arrives.

How to check it's fixed

Mark the finding as “Pending verification” and Ward will check it again. DNS changes can take a few hours to spread, so if it still shows up, try again later.

Who usually fixes it

Your IT person

Example with sample data. In your dashboard, the explanation uses your own domain and details.

SPF doesn't say what to do with fakes

What it means

Your SPF record (the list of servers allowed to send email as your domain) doesn't say what to do with senders that aren't on it. It ends in “?all” or has no ending, which is like leaving the door open without saying so.

What could happen

Receiving mail services have no instruction to reject messages from servers you haven't authorized, so forged emails get through more easily. Your real emails aren't harmed, but your domain is easier to impersonate than it needs to be.

How an attacker would use it

A scammer sends one of your suppliers a message from your address asking to change the bank details on an order. Your SPF doesn't tell the supplier's mail service to distrust unknown senders, so the message arrives looking ordinary.

How to fix it

  1. In your DNS settings, open the TXT record that starts with “v=spf1”.
  2. Check that all services that send email as your domain are listed.
  3. End the record with “-all” (reject others) or “~all” (treat others as suspicious).“~all” is gentler. Start with it if you aren't sure the list is complete.
  4. Save and send a test message to a personal Gmail account to confirm your email still arrives.

How to check it's fixed

Mark the finding as “Pending verification” and Ward will check it again. DNS changes can take a few hours to spread, so if it still shows up, try again later.

Who usually fixes it

Your IT person

Example with sample data. In your dashboard, the explanation uses your own domain and details.

SPF uses the deprecated ptr mechanism

What it means

Your SPF record (the list of servers allowed to send email as your domain) uses an old mechanism called “ptr”. It asks the internet to look up the name behind each sending address, which is slow and unreliable. Experts advise against it.

What could happen

Some mail services ignore it, and it can make checks slow or inconsistent. Your email will mostly work, but legitimate messages may occasionally be treated as suspicious. It's a minor issue, not an emergency.

How an attacker would use it

It isn't a way in by itself. The weak spot is that the check can behave differently from one mail service to another, so a message that should be accepted or refused may be handled inconsistently.

How to fix it

  1. Open your SPF record in your DNS settings and find the “ptr” entry.
  2. Work out which service it was meant to cover.Ask your IT person, or check your email provider's SPF instructions.
  3. Replace “ptr” with the “include:” entry of that service, or with “ip4:” and its fixed address if it has one.
  4. Save and send a test message to a personal Gmail account to confirm your email still arrives.

How to check it's fixed

Mark the finding as “Pending verification” and Ward will check it again. DNS changes can take a few hours to spread, so if it still shows up, try again later.

Who usually fixes it

Your IT person

Example with sample data. In your dashboard, the explanation uses your own domain and details.

No DMARC policy

What it means

DMARC is a rule in your domain's DNS that tells Gmail, Outlook and other mail services what to do with messages that pretend to come from @example.com and fail the checks. Your domain doesn't publish one, so each service decides on its own.

What could happen

Anyone can send emails that show your exact address as the sender, and nothing asks mail services to block them. Fake invoices and “the boss needs a transfer” scams usually start that way. Cyber insurance forms often ask about DMARC too.

How an attacker would use it

Someone writes to your customers from your exact address: “we've changed banks, please pay this invoice into the new account.” Nothing tells their mail services to stop it, so it lands in the inbox and one customer pays. You find out when the real invoice goes unpaid.

How to fix it

  1. Choose where the reports will go: a mailbox only for this, such as dmarc@example.com, or a DMARC reports service.Reports are daily summaries from Gmail, Outlook and others listing who sent email as your domain. They aren't personal messages.
  2. At your DNS host, add a TXT record named _dmarc.example.com with the value “v=DMARC1; p=none; rua=mailto:dmarc@example.com”.“p=none” only observes: nothing is blocked yet, so no legitimate email is at risk.
  3. Read the reports for two to four weeks and list every service that sends as you.In Ward, your domain's “DMARC reports and reputation” page shows the record to copy and, when available, an address that collects the reports for you.
  4. Make sure each real service passes SPF or DKIM. Fix or authorize those that don't.
  5. Change “p=none” to “p=quarantine” (suspicious messages go to spam).If a legitimate service starts failing, you'll see it in the reports and can fix it.
  6. When everything legitimate passes, move to “p=reject” (forged messages are refused).

How to check it's fixed

Ward looks for the DMARC record in your DNS. Mark the finding as “Pending verification” and Ward will check it again. DNS changes can take a few hours to spread, so if it still shows up, try again later.

Who usually fixes it

Your IT person

Example with sample data. In your dashboard, the explanation uses your own domain and details.

DMARC record can't be used

What it means

Your domain publishes a DMARC record, but mail services can't use it: it is repeated, or it lacks the “p=” part that says what to do with fake messages. A DMARC rule that can't be read is the same as having none.

What could happen

Mail services ignore the record, so nobody is asked to block messages that pretend to come from your domain. You believe you have a protection that isn't working.

How an attacker would use it

Someone sends your customers a fake invoice from your exact address. Their mail services look for your DMARC rule, can't read it and treat your domain as unprotected, so the fake is delivered like any other message.

How to fix it

  1. Open the TXT records named _dmarc.example.com in your DNS settings.
  2. Keep a single record that starts with “v=DMARC1;” and includes a “p=” policy, and delete any duplicates.
  3. If you aren't sure which policy to use, start with “p=none” and an address for reports: “v=DMARC1; p=none; rua=mailto:…”.
  4. Save the change and wait a few hours for it to spread.

How to check it's fixed

Mark the finding as “Pending verification” and Ward will check it again. DNS changes can take a few hours to spread, so if it still shows up, try again later.

Who usually fixes it

Your IT person

Example with sample data. In your dashboard, the explanation uses your own domain and details.

DMARC only monitors (p=none)

What it means

Your DMARC rule is in monitoring mode (“p=none”). Mail services send you reports about who uses @example.com, but they still deliver messages that fail the checks. It's the right way to start, but it isn't meant to stay there.

What could happen

You can see forgeries but nothing stops them. Fake invoices or payment requests sent as you still reach your customers' inboxes. The longer you stay here, the longer your domain is easy to impersonate.

How an attacker would use it

A scammer sends a payment request to your customers from your exact address. Their mail services notice the message fails the checks, mention it in the report to you and deliver it anyway, because your rule only asks them to watch.

How to fix it

  1. Read your DMARC reports and list every service that sends email as your domain.In Ward, your domain's “DMARC reports and reputation” page groups senders and tells you when you can tighten your policy.
  2. Make sure every legitimate service passes SPF or DKIM, and fix or authorize those that don't.
  3. Change the record named _dmarc.example.com from “p=none” to “p=quarantine”.Suspicious messages will go to spam instead of the inbox.
  4. Keep reading the reports for a couple of weeks to catch any legitimate sender you missed.
  5. When everything is clean, change to “p=reject” so forged messages are refused.

How to check it's fixed

Ward reads the policy in your DMARC record. Mark the finding as “Pending verification” and Ward will check it again. DNS changes can take a few hours to spread, so if it still shows up, try again later.

Who usually fixes it

Your IT person

Example with sample data. In your dashboard, the explanation uses your own domain and details.

DMARC applies to only part of your email

What it means

Your DMARC rule asks mail services to apply it only to part of your email, through the “pct” setting. The rest of the messages that fail the checks are delivered as if you had no rule.

What could happen

A share of forged messages sent as your domain still reaches inboxes. It's a reasonable setting while you roll DMARC out, but if it stays that way, the protection is only partial. The severity is low.

How an attacker would use it

A scammer sends fake messages from your address in bulk. Mail services apply your rule to only some of them, so a portion lands in the spam folder and the rest reaches the inbox, where one is enough to fool a customer.

How to fix it

  1. Open the TXT record named _dmarc.example.com in your DNS settings.
  2. Check in your DMARC reports that your legitimate senders pass.If one fails, fix it first.
  3. Remove “pct=…” from the record, or set it to “pct=100”.When the tag is absent, the rule applies to everything.
  4. Save and wait a few hours for it to spread.

How to check it's fixed

Mark the finding as “Pending verification” and Ward will check it again. DNS changes can take a few hours to spread, so if it still shows up, try again later.

Who usually fixes it

Your IT person

Example with sample data. In your dashboard, the explanation uses your own domain and details.

You don't receive DMARC reports

What it means

Your DMARC rule doesn't include an address to receive reports (the “rua” setting). Those reports are daily summaries from Gmail, Outlook and others listing who sends email as @example.com.

What could happen

You're flying blind: you won't know if someone is impersonating you or if a legitimate service of yours is failing the checks. You also can't tighten your policy safely. It's a low-severity gap that is quick to close.

How an attacker would use it

Someone starts sending fake messages from your address to your customers. Mail services notice, but with nowhere to report it, nobody at your company finds out until a customer complains.

How to fix it

  1. Choose a mailbox just for the reports, such as dmarc@example.com, or use a DMARC reports service.In Ward, your domain's “DMARC reports and reputation” page shows an address you can use when it's available.
  2. Edit the TXT record named _dmarc.example.com and add “rua=mailto:” followed by that address.Keep the rest of the record as it is, separated with semicolons.
  3. Save and wait a day or two: providers send their reports once a day.

How to check it's fixed

Ward looks for the “rua” address in your DMARC record. Mark the finding as “Pending verification” and Ward will check it again. DNS changes can take a few hours to spread, so if it still shows up, try again later.

Who usually fixes it

Your IT person

Example with sample data. In your dashboard, the explanation uses your own domain and details.

DMARC is weaker for subdomains

What it means

Your DMARC record sets a strong policy for the main domain (“p=”) but a weaker one for subdomains (“sp=”). Subdomains then inherit the soft rule, so mail from names like billing.example.com can fail checks and still be delivered.

What could happen

Attackers often forge subdomain addresses. A permissive “sp=” leaves that door open even when the apex rejects spoofing. The severity is low because the main domain may still be protected.

How an attacker would use it

Someone sends a fake invoice from a subdomain of yours. Receiving servers apply your softer subdomain policy and deliver the message even though your apex would have rejected it.

How to fix it

  1. Open the TXT record named _dmarc.example.com in your DNS settings.
  2. Set “sp=” to the same value as “p=” (for example both “reject”), or remove “sp=” so subdomains inherit “p=”.
  3. Save and wait a few hours for DNS to spread.

How to check it's fixed

Mark the finding as “Pending verification” and Ward will check it again. DNS changes can take a few hours to spread, so if it still shows up, try again later.

Who usually fixes it

Your IT person

Example with sample data. In your dashboard, the explanation uses your own domain and details.

No DKIM signature found

What it means

DKIM is a digital signature that your email provider adds to every message you send. The receiving service checks it against a public key in your DNS to confirm the message came from you and wasn't altered. We looked for the usual provider keys and found none published.

What could happen

Without DKIM you rely on SPF alone, which often fails when an email is forwarded. Your real messages are more likely to be flagged as suspicious, and forged ones are harder to tell apart. It's a low-severity gap that is simple to close.

How an attacker would use it

A scammer writes to one of your customers as if from your company. Without a signature, the customer's mail service can't tell your genuine messages from the forgery, so a convincing fake invoice has a better chance of reaching the inbox.

How to fix it

  1. Open the admin area of your email service and find its DKIM or “email authentication” settings.
  2. Generate the DKIM key. The service shows one or more DNS records to publish.
  3. At your DNS host, add those records exactly as shown.
  4. Go back to the email service and turn signing on once the records have spread.Some services only enable it after a button like “Start” or “Enable”.
  5. Send a test message to a personal Gmail account to confirm it arrives normally.

How to check it's fixed

Ward looks for the DKIM keys in your DNS. Mark the finding as “Pending verification” and Ward will check it again. DNS changes can take a few hours to spread, so if it still shows up, try again later.

Who usually fixes it

Your IT person

Example with sample data. In your dashboard, the explanation uses your own domain and details.

No MTA-STS

What it means

MTA-STS is a rule you publish so that other mail servers must use an encrypted, verified connection when they deliver email to @example.com. Without it, they usually try encryption but accept a plain connection if something goes wrong.

What could happen

Email that arrives for you could, in unusual circumstances, travel unencrypted and be read or altered on the way. For most small businesses this is a low risk and it's optional protection, but it's cheap to add once you have DMARC in place.

How an attacker would use it

Someone positioned between a customer's mail server and yours, for example on a compromised network, interferes with the setup of the secure connection. Nothing requires encryption, so the server falls back to a plain connection and the message can be read in transit.

How to fix it

  1. Check which servers receive your email (your MX records) and confirm they support encrypted connections.Big providers such as Google and Microsoft do.
  2. Create the address mta-sts.example.com in your DNS and a web page behind it with a valid certificate.
  3. Publish a short policy file at https://mta-sts.example.com/.well-known/mta-sts.txt, in “testing” mode first.The file has lines “version: STSv1”, “mode: testing”, one “mx:” line per mail server and “max_age:”.
  4. Add a TXT record named _mta-sts.example.com with “v=STSv1; id=” followed by any number you change each time the policy changes.
  5. Watch the TLS-RPT reports for a few weeks and, if there are no errors, change the mode to “enforce”.

How to check it's fixed

Ward looks for the TXT record and reads the policy file. Mark the finding as “Pending verification” and Ward will check it again. DNS changes can take a few hours to spread, so if it still shows up, try again later.

Who usually fixes it

Your IT person

Example with sample data. In your dashboard, the explanation uses your own domain and details.

MTA-STS is broken

What it means

Your DNS announces that you use MTA-STS (a rule that forces other mail servers to encrypt email they send to @example.com), but the policy file it points to can't be read. So the rule can't take effect.

What could happen

You think incoming email is protected, but servers that look for the policy find nothing valid. In the worst case, some servers may be more cautious than needed and delay delivery. It's a configuration slip rather than an attack.

How an attacker would use it

Someone able to tamper with the connection between a customer's mail server and yours finds that the promised protection isn't there. With no readable policy, the server accepts a plain connection and the message can be read on the way.

How to fix it

  1. Open https://mta-sts.example.com/.well-known/mta-sts.txt in a browser and note the error you see.A certificate warning, a “not found” page or an empty page each point to a different fix.
  2. Make sure the name mta-sts.example.com exists in your DNS and points to a web server.
  3. Install a valid certificate for that name and publish the policy file at the path above.
  4. Check that the file has “version: STSv1”, a “mode”, one “mx:” line per mail server and a “max_age”.
  5. If you no longer want MTA-STS, delete the TXT record that announces it instead.

How to check it's fixed

Ward reads the policy file again. Mark the finding as “Pending verification” and Ward will check it again. DNS changes can take a few hours to spread, so if it still shows up, try again later.

Who usually fixes it

Your IT person

Example with sample data. In your dashboard, the explanation uses your own domain and details.

MTA-STS still in testing mode

What it means

Your MTA-STS policy is in “testing” mode. Other mail servers read it and report problems, but they still deliver email over an unencrypted connection when the secure one fails. It's a normal step while you roll MTA-STS out.

What could happen

The protection isn't enforced yet, so the benefit is still partial. There is nothing urgent: this is a reminder to finish the job once the reports show no errors.

How to fix it

  1. Read your TLS-RPT reports (or ask whoever receives them) for a few weeks.
  2. If there are no delivery errors, edit the policy file and change “mode: testing” to “mode: enforce”.
  3. Change the number after “id=” in the _mta-sts TXT record so mail servers notice the new policy.

How to check it's fixed

Ward reads the “mode” line of the policy. Mark the finding as “Pending verification” and Ward will check it again. DNS changes can take a few hours to spread, so if it still shows up, try again later.

Who usually fixes it

Your IT person

Example with sample data. In your dashboard, the explanation uses your own domain and details.

No TLS-RPT reports

What it means

TLS-RPT is a setting that makes other mail servers send you a short daily report when they can't deliver encrypted email to @example.com. Your domain doesn't ask for those reports.

What could happen

If encryption of incoming email fails, you won't know. It's informational: nothing is broken today, but the reports are what tells you when it's safe to enforce MTA-STS, so they matter if you plan to use it.

How to fix it

  1. Choose a mailbox for the reports, such as tlsrpt@example.com, or a reports service.
  2. Add a TXT record named _smtp._tls.example.com with the value “v=TLSRPTv1; rua=mailto:” followed by that address.
  3. Save and give it a day or two: providers send their reports once a day.

How to check it's fixed

Ward looks for the TLS-RPT record. Mark the finding as “Pending verification” and Ward will check it again. DNS changes can take a few hours to spread, so if it still shows up, try again later.

Who usually fixes it

Your IT person

Example with sample data. In your dashboard, the explanation uses your own domain and details.

Unrecognized sender using your domain

What it means

Your DMARC reports (the daily summaries mail services send about your domain) show a sender that wasn't there before and sends a notable volume of email as your domain. Its messages fail the checks, and it isn't your email provider or a service in your SPF.

What could happen

Either someone is impersonating your domain, or a service you recently started using isn't set up properly. In the first case, your customers receive messages that look like yours. Depending on your DMARC policy, mail services may deliver them anyway.

How an attacker would use it

A criminal group sends thousands of messages with your domain as the sender: “your invoice is overdue, pay here.” The address is familiar, so many recipients trust it and click. If your policy only observes, mail services deliver them and your customers blame your company.

How to fix it

  1. Open the technical details and note the sender's addresses, its volume and its reverse name (PTR).The reverse name often shows the company behind the server.
  2. Ask your team if it matches a tool: newsletters, invoicing, CRM, an online store, a website form, a printer or an old server.
  3. If it's yours, authorize it: add its “include:” to your SPF or turn on DKIM signing with your domain in that service.
  4. If nobody recognizes it, treat it as impersonation: move your DMARC policy to “quarantine” or “reject” once your own senders pass.
  5. Warn your customers and team that fake emails may be circulating and not to act on payment changes without calling you.
  6. Keep reading the reports to confirm the sender disappears.If you suspect a mailbox was compromised, also change its password and turn on two-step verification.

How to check it's fixed

Ward keeps reading your DMARC reports; when the sender stops, the finding resolves. Mark the finding as “Pending verification” and Ward will check it again. DNS changes can take a few hours to spread, so if it still shows up, try again later.

Who usually fixes it

Your IT person

Example with sample data. In your dashboard, the explanation uses your own domain and details.

SPF includes a service that no longer sends

What it means

Your SPF record includes “include:include”, but in the last 60 days of DMARC reports nothing was sent through it. It probably belongs to a service you no longer use.

What could happen

It's housekeeping, not a danger. An unused entry counts against the limit of 10 lookups in SPF and lets a service you've forgotten send email as your domain, which is more access than you need.

How to fix it

  1. Check with your team that nobody uses the service behind “include:include”, even occasionally.Yearly campaigns or occasional invoicing tools can go months without sending.
  2. If it is no longer needed, remove that entry from your SPF record at your DNS host.
  3. Save, and send a test message to a personal Gmail account to confirm your email still arrives.

How to check it's fixed

Ward checks your SPF and DMARC reports again. Mark the finding as “Pending verification” and Ward will check it again. DNS changes can take a few hours to spread, so if it still shows up, try again later.

Who usually fixes it

Your IT person

Example with sample data. In your dashboard, the explanation uses your own domain and details.