Email deliverability troubleshooting guide

Delivering emails reliably is critical for user-facing apps – a verification link or password reset email is useless if it never reaches the inbox. Yet it’s not uncommon for legitimate product emails to end up in spam or vanish, leaving developers puzzled.

We put together this comprehensive, step-by-step guide to diagnosing email delivery issues, along with best practices to improve deliverability and avoid future problems. Let’s jump right in.

How email delivery works (and fails)

When your application sends an email (often via an Email Service Provider, or ESP, like SendGrid, Mailchimp, or Resend), the ESP hands it off to the recipient’s mail server. At that point, the recipient’s server will do one of a few things with the message:

• Deliver to inbox: The email passes all checks and is placed in the recipient’s inbox.
• Filter to spam/junk: The server accepts the email but flags it as potential spam, diverting it to a spam or junk folder.
• Queue or delay: The server temporarily holds the message (due to policy checks, greylisting, etc.) to decide later or retry delivery.
• Discard or block: The server outright rejects or silently drops the email, preventing it from reaching the user.

It’s important to understand that when an ESP reports an email as “Delivered,” it usually means the recipient’s mail server accepted the message with a 250 OK response, not that it actually landed in the user’s inbox.

After acceptance, the recipient’s system may still spam-filter or drop the email without further notice to the sender. Major providers (Gmail, Outlook, Yahoo, etc.) and corporate email systems apply their own proprietary filtering rules, which they don’t publicly disclose. This makes troubleshooting tricky since, from the sender’s perspective, everything appeared successful (no bounce returned).

For more on why this might happen, see Email deliverability and spam prevention: why your emails aren’t getting delivered and how to fix it.

How WorkOS sends emails

WorkOS offers three options for sending email:

• WorkOS sends emails from the WorkOS domain: This is the default scenario. WorkOS sends emails from the workos-mail.com domain. This is the easiest way to get started since there is no domain setup needed. WorkOS follows industry best practices: SPF and DKIM email authentication records are configured automatically, the email content is continually refined to ensure it passes spam filters, and delivery of every email is actively monitored. WorkOS also actively monitors the delivery of emails sent from the workos-mail.com domain to protect the domain’s reputation. If we detect unusually high rates of undelivered mail or mail marked as spam from a WorkOS team account, we may suspend that team’s ability to send email.
• WorkOS sends emails from your company’s domain: While using the WorkOS email domain option is convenient, you can provide your users with a better experience. Using your own email domain means that your users will receive emails from a domain they recognize, one associated with your app. In addition, because you control the email domain, you have more control over the domain reputation and, therefore, more control over email deliverability. You can configure your own email domain in the WorkOS dashboard. You will need to verify ownership of the domain by setting up a CNAME record with your domain provider. Two additional CNAME records are required to automatically configure SPF and DKIM email authentication using Sendgrid’s automated security feature. If you choose this option, you will have to:
  • Set up inboxes: When using your own domain, email will be sent from welcome@<your domain> and access@<your domain>. Email providers check if there are inboxes associated with sender addresses, so setting up inboxes for both the welcome and access email addresses on your domain can help ensure your emails reach users.
  • Set up DMARC: WorkOS recommends that you set up DMARC (Domain-based Message Authentication, Reporting & Conformance) with your domain provider. Google has released
    guidelines for email senders and the guidelines include DMARC requirements. Apple and Yahoo have released similar best practice guides.
• You handle all email delivery: In this scenario, WorkOS emits events (e.g., via webhooks), allowing your app to listen to these events and send email using your own email provider. For complete instructions on sending your own email, see the section on custom emails in the documentation. When sending your own email, you will want to follow all of the recommendations in Google’s email sender guidelines. This includes setting up SPF, DKIM, and DMARC email authentication.

Troubleshooting checklist

Use the following step-by-step checklist to investigate why emails aren’t reaching your users. This process is organized to go from broad observations to specific checks, helping you pinpoint the issue.

1. Determine the scope of the problem

The first step in troubleshooting is to determine if the problem exists for all users or only a subset of users. This will give insight into the nature of the issue and how best to resolve it.

• If no emails are delivered at all (to any domain/recipient), focus on global issues like authentication and sender reputation. For example, a misconfigured DNS record or a poor domain reputation could cause universal filtering.
• If only specific recipients or domains aren’t getting emails (e.g., only corporate addresses, or only Gmail/Outlook users), the issue may be due to recipient-side filtering or policies. For instance, Gmail and Microsoft 365 have aggressive spam filters that might be catching your emails, or an IT department’s firewall could be blocking them. Identifying the pattern (all vs subset) will narrow down the likely causes.

2. Check your email sending service logs

Once you have narrowed down the scope, the next step is to check the logs. If WorkOS is sending the emails for you, you will have to check the WorkOS logs. If you send the emails yourself, check your ESP’s dashboard or API.

Key things to look for per email:

• Delivered vs. bounced: If the status is “Delivered” according to the ESP, remember that this only means the recipient’s server accepted the message. The user still might not see it (possible spam folder). If the status is “Bounced” or “Rejected,” gather the bounce error code and message—these often indicate why it was refused.
• Bounce details: A “hard bounce” (5xx SMTP error) indicates a permanent failure (e.g., “user not found” or domain does not exist). A “soft bounce” (4xx error) means a temporary issue (mailbox full, server down, etc.). Many providers will put an address on a suppression list after a hard bounce. For example, Resend automatically suppresses sending to an address after a hard bounce to protect your reputation. Check your ESP’s suppression or blocked list to see if the address is listed; if so, you’ve found at least one problem.
• If bounced: Investigate the reason. Common causes include typos in the email (e.g., user@gnail.com), the address no longer exists, or the recipient’s server actively blocked you. The bounce message will usually clarify this. If it’s a typo or a non-existent address, your course is clear (fix the address or stop sending to it). If the recipient’s server blocked you, you might need to contact their admin or follow their removal process (especially if your domain is on a blocklist).
• If marked delivered but not received: This points to the email being filtered after acceptance. In this case, continue with the next steps to figure out why it may have been flagged.

‍

3. Verify DNS records (SPF, DKIM, DMARC)

If you don’t use WorkOS’ domain, ensure that your sending domain has the correct DNS records in place for email authentication:

• SPF: A TXT record that lists which mail servers are authorized to send on behalf of your domain. ISPs use SPF to verify that an email claiming to come from yourdomain.com is sent from a server you’ve approved.
• DKIM: A TXT record (public key) that your mail server uses to cryptographically sign each outgoing email. Recipients verify the DKIM signature to confirm the message wasn’t tampered with and truly comes from your domain.
• DMARC: A TXT record that builds on SPF/DKIM. It tells receivers how to handle emails that fail authentication (e.g., reject or quarantine them) and provides a way for you to get reports on your email streams.

Why it matters: Without SPF and DKIM, your emails lack authentication and are more likely to be flagged as spam. In fact, setting up SPF and DKIM is considered mandatory to prevent spam-foldering. DMARC is optional but highly recommended for better deliverability and security.

How to verify: Use your DNS provider’s management console or command-line tools to ensure these records exist and are correct. Many ESPs provide a domain verification check that will indicate if your SPF/DKIM are properly set up. You can also use third-party tools or online checkers (e.g., MXToolbox, Gmail Postmaster Domain Check) to validate your DNS records. If any of these are missing or misconfigured, fix them first – this could resolve the deliverability issues outright. If you use a subdomain (recommended), make sure DNS is configured for that subdomain.

4. Assess sender reputation and blacklists

If you use your own domain, then you must ensure that it has a good reputation. Keep in mind always that the domain’s past sending behavior affects current deliverability.

• Sending domain vs. root domain: If you are using your company’s primary domain to send emails, consider that any hit to its reputation affects your entire brand. Many organizations use a dedicated subdomain for product emails (for example, notifications.acme.com instead of acme.com). Using a separate sending subdomain isolates reputation – if that subdomain gets into trouble (spam complaints, etc.), it won’t directly damage your root domain’s email deliverability. It also makes your sending purpose clearer to providers, e.g., mail from news.example.com can be treated differently than mail from transactions.example.com We’ll discuss this more later, but keep in mind as you troubleshoot domain reputation.
• Domain/IP Reputation: Check if your domain (and sending IP, if applicable) has a good reputation. Google’s Postmaster Tools can show your domain’s reputation as seen by Gmail, and services like Microsoft SNDS do similarly for Outlook/Hotmail. If you see a “poor” reputation, you likely need to improve engagement and reduce complaints (more on that in Best Practices).
• Blacklists: Use a blacklist lookup service to see if your domain or IP appears on common spam blacklists (Spamhaus, etc.). If you find a listing, that’s likely a cause of bounces or spam placement. You’ll need to request removal from each blacklist (procedures vary) after addressing the reason you were listed. Being on a DNSBL means providers may outright reject your mail or drop it into spam.
• Domain warming: If you’re sending from a new domain or subdomain, it’s critical to “warm” it up before sending at high volumes. Domain warming involves gradually increasing your email send volume over days or weeks while maintaining high engagement rates (opens, clicks, etc.). This helps establish a trustworthy reputation with mailbox providers. Jumping straight into large-scale sends from a cold domain is a common reason for immediate filtering into spam or outright blocking. Especially for new campaigns, warming should be a core part of your deliverability strategy. You can either warm up your new domain using one of the tools available online, like mailwarm, or do this manually by sending emails to your team and asking them to interact with them in a positive way, like replying or marking them as “Not spam”. Keep in mind that it typically takes around 6 weeks to warm a new domain with a warming service.

5. Inspect email content and format

If infrastructure and reputation look okay, the culprit might be the email content itself. Review the emails that weren’t delivered properly for anything that might trigger filters:

• Spam keywords and styling: Avoid phrases and formatting that scream “spam.” Examples: excessive exclamation points (“!!!”), all-uppercase subject lines, words like “FREE” or “Buy now”. These can trip content filters. Make sure your subject and body sound legitimate and relevant to the recipient.
• Unsubscribe links (for bulk email): If the emails in question are marketing or newsletter emails, they must include a visible unsubscribe link. If people can't easily opt out, they are more likely to mark your message as spam, and spam filters penalize the message for lacking an unsubscribe option.
• Images and HTML: Messages that are mostly images or have very messy HTML can be suspicious. Aim for a balance of text and images—don’t send an email that’s one large image with little text. Also, ensure your HTML is clean and not generated by outdated or spammy templates.
• URLs and links: Using URL shorteners or linking to domains that are unrelated to your sending domain can raise red flags. For instance, if your email links out to a different domain (especially one with a poor reputation), spam filters might be wary. Use your own domain in links whenever possible. This ties back to authentication as well – some filters check that URLs in the email match the sender’s domain.
• Tracking elements: Many marketing emails include tracking pixels or tracked links (for open/click tracking). Be aware that spam filters are sensitive to these. If you’re facing deliverability issues, try sending an email without open/click tracking to see if it improves inbox placement. Disabling tracking can sometimes help an email bypass strict filters.
• Attachments: If your email has attachments, ensure they are not large or of an executable type that could be flagged (like .exe or even Office macros). Attachments can trigger security filters; consider providing a download link instead.

As a troubleshooting step, you might send a simplified test email (plain text, no images, from the same domain/IP) to the same recipient to see if that gets delivered. If it does, then you know something in your normal email content is the issue. You can gradually add elements back to isolate which content feature might be causing problems.

6. Check the recipient side (if possible)

If you have access to or communication with an affected recipient, use that to your advantage.

• Ask the user to check their spam/junk folder or any quarantine area for the email. Often, the email is sitting there unnoticed. If they find it, have them mark it “Not Spam”, which can help train the filter and also possibly whitelist your sending address/domain for future emails.
• For corporate recipients, ask their IT/admin if the email was blocked by a security gateway. Sometimes emails get caught in enterprise email security filters. The admin might find a log of the message being dropped or quarantined and can whitelist your domain if appropriate.
• Note that if the recipient uses a system like Gmail’s Promotions tab, the email might be in a different inbox category, which users often overlook. It’s technically delivered, but not in the main inbox.

If you are not in direct contact with the user, you have to rely on the other debugging steps. In such cases, focus on optimizing your settings and content to avoid spam filters proactively (and consider steps like enabling DMARC, warming up your domain, turning off tracking – many of which we’ve already covered).

7. Review ESP policies and limits

Double-check if your email service provider has any sending limits or specific policies that might be affecting you. For instance, some ESPs have daily sending limits or require domain verification before high-volume sends. If you hit a limit, some emails might not be sent at all.

8. Consider environment changes

Think about what changed around the time the problem started. Did you switch to a new ESP or a new sending IP range? Did you start sending to a new user segment or a purchased list? Any sudden change in sending behavior or infrastructure can affect deliverability.

If you identify a change, try temporarily rolling it back if possible, or apply mitigations (e.g., if you added a new IP, maybe it needs warming up; if you started a new campaign, maybe the content needs adjusting).

9. Leverage deliverability testing tools

There are services that help analyze your emails’ spam characteristics. For example, services like Mail-Tester, Litmus, or Warmy can send your email to a variety of test mailboxes and give you a report on what might be wrong. These tools can highlight issues like missing DNS records, content problems, or blacklistings in one report. Use them during troubleshooting to get quick feedback.

10. Iterate and monitor

After making any changes (updating DNS, modifying content, etc.), test sending again. This might involve sending to the same recipient or a set of test accounts (e.g., one at Gmail, one at Outlook, etc.) to see if deliverability improved. Monitor your email logs and metrics closely over the next few sends:

• Delivery/failure rates: Have bounces dropped?
• Open rates: Are more users opening (implying more are receiving in the inbox instead of spam)?
• Complaints/unsubscribes: Make sure you’re not getting new spam reports as you adjust things.
• Reputation indicators: Check Google Postmaster Tools again after some time to see if your reputation status improves.

If you use WorkOS and, after going through these steps, you’re still unable to identify the issue, please contact support.

Keep in mind that some deliverability issues are on the receiver’s side and might be out of your direct control, but by following the above steps, you’ll have done everything possible on your end to ensure your emails are inbox-bound.

Best practices to improve and maintain deliverability

Troubleshooting gets emails flowing again, but ideally, we want to prevent deliverability issues from happening in the first place. Below is a checklist of best practices for proactively maximizing email deliverability. These practices will help build a solid sender reputation and keep your emails welcomed by inboxes:

• Set up SPF, DKIM (and DMARC): If you’re sending from your own domain—whether through WorkOS or directly—you must configure DNS records to authenticate your messages. Authenticate your emails with SPF and DKIM on your sending domain before you start sending high volumes. This is non-negotiable for good deliverability. Add a DMARC record with a policy (p=none initially, if you just want reports) to gather feedback and gradually enforce it. Failure to set these up makes your domain appear untrustworthy and can cause your messages to be rejected or sent to spam. If you are using the WorkOS domain to send emails, then no action is needed here, since WorkOS handles authentication for its own domain (auth.workos.com).
• Use a dedicated sending domain (subdomain): It’s often recommended to send emails from a dedicated subdomain (for example, email.yourdomain.com or notifications.yourapp.com) rather than from your root domain. This serves two purposes:
  • Reputation Isolation: Your subdomain’s sending reputation can build over time independently. If it suffers a hit (e.g., gets flagged for spam), your root domain’s reputation for other purposes (like employee emails) remains safer. In a worst-case scenario, you can retire or change a misbehaving subdomain, whereas rehabilitating a tainted primary domain is much harder.
  • Purpose Segmentation: You can use different subdomains for different types of email (transactions, marketing, support). This gives clarity to recipients and email providers about the nature of the email. For instance, billing.yourdomain.com might send invoices and receipts (which are transactional), while news.yourdomain.com sends newsletters (which are promotional). Mail providers often prioritize transactional messages higher. Clear segmentation via subdomains can build trust and confidence with inbox providers over time.
  • Avoid using deceptive or “lookalike” domains that aren’t clearly under your main domain. For example, do not send from yourapp-mail.com if your website is yourapp.com – that looks phishy. Always use subdomains of your actual domain so recipients and providers can tell it’s legitimately you.
  • Set up SPF, DKIM, and DMARC for the subdomain as well.
• Warm up new domains and IPs: If you have a new sending domain or a new IP address, don’t go zero-to-full-blast on day one. ISPs are wary of domains that suddenly send large volumes of email out of nowhere. Warm up your sending gradually:
  • Start with small volumes (or sending to your most engaged users) and increase daily/weekly.
  • Consider using a domain warm-up service or tool. These services automatically send emails on your behalf and interact (open, reply, mark as not spam) to simulate positive engagement, thereby boosting your reputation over a few weeks.
  • Alternatively, do a manual warm-up: send emails internally to colleagues/friends first and have them mark them as not spam, reply, etc. Though manual, this can help build an initial good reputation.
  • Monitor bounce/spam rates during warm-up. If you see issues early, pause and fix them before scaling volume.
  • Keep in mind that it typically takes around 6 weeks to warm a new domain with a warming service.‍
• Maintain a clean mailing list: Validate email addresses before sending to avoid hard bounces. Regularly clean your list to remove invalid addresses or inactive users. Use double opt-in when collecting emails to ensure quality and intent. Also, purge or re-engage inactive users: if someone hasn’t opened your emails for a year, continuing to send can hurt engagement metrics; consider a re-confirmation campaign or stop emailing them.‍
• Send relevant, expected emails: Only send emails to people who are expecting them (they signed up for your app or mailing list). Avoid any practice that could be considered sending unsolicited bulk email. Sending to purchased lists or users who didn’t opt in will generate spam complaints, which severely harms deliverability. Never send unsolicited email through your system– not only is it often against ESP policies, but it’s also ineffective. If you operate a SaaS product, emails like sign-up confirmations or password resets are transactional and expected; ensure marketing or newsletter emails are only going to users who explicitly opted in.‍
• Optimize email content: Follow content best practices on every send.
  
  • Use the recipient’s name or other personalization if possible – identical mass messages are more likely to trigger filters than personalized ones.
  • Include a clear subject and relevant content. Don’t mislead users with “Re:” or “Fwd:” tricks or sensational subject lines.
  • Always include an unsubscribe link in non-transactional emails. Make it easy to find. If users can’t opt out, they might hit “Spam” to get rid of your emails, which is much worse for you.
  • Balance text and images; ensure your email is not one big image and that you have some plain text (you can include a plain-text part in multi-part MIME emails for recipients that prefer it).
  • Avoid known spam trigger words/phrases. There’s no exhaustive list, but words like “free money”, “Viagra”, excessive "$$$", etc., are obvious ones to avoid unless they’re legitimately your content. When in doubt, run your email through a spam checker tool (many ESPs offer this) before sending.
  • Keep the HTML code clean. Remove any hidden text or unused code that might have come from editors like Microsoft Word. Also, ensure your URLs and tracking domains are consistent and not on blocklists.‍
• Be careful with tracking and extras: As mentioned, open/click tracking pixels and unique tracking links can sometimes hurt deliverability. Use them judiciously. If you notice deliverability issues, experiment with turning off open tracking or using first-party tracking domains. Similarly, if you add lots of analytics parameters or redirectors to your links, ensure those domains aren’t flagged. Simpler is often safer for deliverability.‍
• Monitor engagement and complaints: Use metrics from your ESP to monitor how users interact with your emails.
  
  • Track open and click rates (if enabled) to see if they decline or if certain segments never engage (this could indicate that those go to spam).
  • Watch the complaint rate (spam report rate) if your ESP provides it. Many ESPs will alert you if a campaign or send causes an unusually high spam complaint rate. Keep this well under 0.1% if possible.
  • Some providers (like Gmail via Postmaster Tools) will tell you if users categorize your mail as spam frequently. If you see that, you may need to re-evaluate your email content and list quality.‍
• Utilize feedback loops: If your ESP hasn't already, consider setting up feedback loops (FBL) for major ISPs (like Yahoo, AOL, and Microsoft). An FBL will notify you when a user marks your email as spam. Removing those users from your list immediately can prevent further damage to your reputation.‍
• Monitor domain reputation and ISP guidance: Regularly check Google Postmaster Tools for your domain’s health (reputation, spam rate, etc.). This can give you an early warning if your reputation drops. Also, pay attention to ISP postmaster guidelines—for example, Gmail and Microsoft publish bulk sender guidelines. Adhering to their best practices (like proper DKIM signing, list-unsubscribe headers, etc.) can help ensure long-term deliverability.‍
• Stay off blacklists: As mentioned, keep an eye on blacklists. If you maintain good practices, you shouldn’t end up on one. But it can happen to well-meaning senders (for instance, hitting a spam trap – an email address set up specifically to catch spammers). If you do get listed, investigate why (most blacklist operators give a reason or the type of spamtrap hit) and address it. Always resolve the root cause (e.g., remove a problematic list segment) before requesting removal from the blacklist, otherwise you might get relisted.‍
• Test, test, test: Periodically send test emails to accounts you control at various providers (Gmail, Outlook, Yahoo, etc.) to see where they land (inbox vs spam). This can catch problems early. You can also use seed list testing services, which automate this. Testing is not just for content but also for new setups – e.g., if you add a new sending domain, test it with a few emails first.

Implementing these best practices will greatly reduce the chances of deliverability issues. Building a strong sender reputation and staying consistent with good sending habits is like maintaining a healthy system—it’s much easier to keep problems at bay than to fix them after the fact.

FAQ: Common email deliverability questions

Q: The ESP marked my email " Delivered”, but the user didn’t get it. Why?

A: “Delivered” in your ESP logs typically means the recipient’s mail server accepted the message. After that, the mail could have been filtered to spam, placed in a secondary folder (like Gmail’s Promotions), queued for later, or even silently dropped by the recipient system. Major inbox providers perform additional filtering after acceptance, which you, as the sender, don’t see. So the email was delivered to the mailbox provider, but not necessarily to the user’s visible inbox.

To troubleshoot, ask the user to check their spam/junk folder or any filters/rules on their mailbox. If the email is found there, have the user mark it “Not Spam”. In parallel, review your authentication, content, and sending practices (as outlined above) to prevent future emails from being misclassified. Common fixes include setting up DMARC, removing spammy content, and disabling open tracking to see if that helps inbox placement.

Q: What is a suppression list, and why are my emails landing on it?

A: A suppression list is used by email sending services to automatically block sending to addresses that are known to cause problems (like repeated bounces or spam complaints). If an email address hard-bounces (permanent failure), many providers will add it to a suppression list to prevent further send attempts. This protects your sender reputation (and the ESP’s IP reputation) by ensuring you don’t keep sending to an address that will never deliver. Your emails “landing on the suppression list” means the ESP noticed a hard bounce or other serious issue with those addresses and is now suppressing them. Common reasons include: the address doesn’t exist or has a typo, the recipient’s mail server blocked your messages, or the address previously marked emails as spam. To resolve this, first fix the root issue – if it’s a typo or bad address, correct it; if the recipient’s server was blocking you, you may need to wait or contact them. Once resolved, you can remove the address from the suppression list (your ESP’s dashboard typically allows this) and try sending again. Remember, if the underlying problem isn’t fixed, the address will likely end up suppressed again on the next send.

Q: What DNS records do I need to set up for email sending?

A: The three critical DNS records for email are SPF, DKIM, and DMARC:

• SPF (Sender Policy Framework): A TXT record that specifies which mail servers are authorized to send email for your domain. Recipients use it to verify that an email from “you@yourdomain.com” came from a server you approved. Without a correct SPF record, your emails might fail this check.
• DKIM (DomainKeys Identified Mail): A TXT record containing a public key, which corresponds to a private key used by your mail server to sign outgoing emails. Recipients will decrypt the signature with your public key to ensure the message wasn’t altered and truly comes from your domain. If DKIM is not configured, your emails lack that cryptographic proof of authenticity.
• DMARC (Domain-based Message Authentication, Reporting, and Conformance): A TXT record that works with SPF and DKIM. It tells receiving servers what to do if an email fails SPF/DKIM checks (do nothing, quarantine to spam, or reject), and provides a way for you to get aggregate and forensic reports. For example, you might start with a DMARC record of v=DMARC1; p=none; rua=mailto:reports@yourdomain.com; to receive reports without affecting mail flow, then later change p=quarantine or p=reject once you’re confident all your mail is authenticated. While not strictly required to deliver mail, DMARC is highly recommended for protecting your domain and improving receiver trust

In summary, ensure SPF and DKIM are in place (mandatory for good deliverability) and add a DMARC record for better policy control and visibility. These DNS records must be published on the sending domain (or its subdomain) that appears in your email’s headers. Many email providers will guide you through setting these up, and you can verify their correctness using tools or during testing.

Q: Should I send emails from my root domain or a subdomain?

A: It’s generally best practice to send from a dedicated subdomain rather than your root (apex) domain. For example, use something like mailer.yourdomain.com or notify.yourdomain.com for your application emails. This approach offers reputation isolation – if that subdomain gets a poor sending reputation (due to bounces or complaints), it won’t directly drag down the reputation of your primary domain used for other purposes. It also provides clarity to recipients and mail providers about the nature of the emails.

You might even use multiple subdomains to separate transactional mail vs. marketing mail, as mentioned earlier, to further silo reputation and ensure important emails (like password resets) aren’t penalized by the behavior of your marketing emails.

Be sure the subdomain you choose is clearly related to your brand; don’t use misleading domains that could look like spam. Once you decide on a sending subdomain, set up SPF/DKIM/DMARC on it just as you would for a root domain. Using a subdomain is not a requirement, but it’s a safeguard that seasoned email senders strongly recommend for better deliverability and domain protection.

Q: Does enabling click or open tracking affect deliverability?

A: Yes, it can. Tracking pixels and rewritten URLs can trigger spam filters, especially with new domains or aggressive filtering environments. If you're troubleshooting, try disabling tracking temporarily to see if inbox placement improves.

Q: Should I send transactional and marketing emails from the same domain or IP?

A: Ideally, no. Separate them using different subdomains (e.g., billing.yourdomain.com, news.yourdomain.com) and possibly different IPs. This prevents marketing-related complaints from affecting critical system email deliverability.

Q: How do I test if SPF, DKIM, and DMARC are set up correctly?

A: You can use:

• MXToolbox
• Google Admin Toolbox
• dig / nslookup from the command line
• Your ESP’s domain verification UI

Ensure SPF includes your sending IP, DKIM keys match what your ESP signs with, and DMARC uses a policy appropriate to your setup (none for monitoring, quarantine or reject for enforcement).