Email Deliverability Checklist: The Practical Guide to Reaching the Inbox

Email deliverability is not just whether your server accepted an email—it is whether the recipient’s provider trusts it enough to place it in the inbox. This email deliverability checklist gives marketing, product, and engineering teams a repeatable way to set up legitimate sending, prevent common failures, and prove that each part is working.

What email deliverability actually means

Email delivery and email deliverability are related, but they are not interchangeable.

Delivery means a receiving mail server accepted the message. A message can be delivered to a mailbox provider and still be routed to spam, promotions, quarantine, or another filtered location. Deliverability is the broader outcome: how reliably your wanted mail reaches the intended inbox and remains trusted over time.

Mailbox providers evaluate far more than a campaign’s HTML or subject line. They can assess authentication, the relationship between your visible From domain and your sending infrastructure, complaint signals, bounce patterns, recipient engagement, message formatting, unsubscribe handling, and the consistency of your sending behavior. Google and Yahoo both publish sender requirements that make these fundamentals explicit, particularly for bulk senders. (support.google.com)

That is why deliverability is an operating discipline, not a one-time DNS task. A technically correct domain can still perform poorly if it sends to people who did not ask for the mail, ignores bounces, changes frequency without warning, or makes opting out difficult.

The three outcomes to measure

Use three separate lenses when reviewing performance:

1. Acceptance: Did the recipient server accept the message, defer it temporarily, or reject it permanently?
2. Placement: Of accepted mail, how much appears in the inbox rather than spam or another filtered destination?
3. Recipient response: Are people reading, clicking, replying, deleting, unsubscribing, or marking messages as spam?

Do not use opens as your sole deliverability metric. Privacy protections and image-loading behavior make opens an imperfect measure of attention. Instead, combine provider diagnostics, bounce and deferral codes, complaints, unsubscribes, conversions, replies for transactional mail, and any seed-based placement testing you choose to run.

Email deliverability checklist at a glance

Before sending a campaign—or before turning on a product-email workflow—work through this list:

• Use a domain you control, with a stable and recognizable From address.
• Inventory every system that sends mail using that domain.
• Publish one valid SPF record that authorizes legitimate senders.
• Enable DKIM signing for every sending stream.
• Publish DMARC and confirm that SPF or DKIM aligns with the visible From domain.
• Use TLS and correctly configured forward and reverse DNS if you operate your own mail infrastructure.
• Keep marketing and transactional mail logically separate, ideally with distinct subdomains or sending identities where your provider supports them.
• Collect consent clearly and retain the source, time, and method of subscription.
• Never buy, scrape, rent, or automatically enroll contacts in marketing lists.
• Validate addresses at capture and suppress hard bounces, unsubscribes, and complaints immediately.
• Make the sender identity, purpose, and expected cadence obvious.
• Include a visible unsubscribe link in promotional email and support one-click unsubscribe headers for qualifying bulk mail.
• Ramp up new domains, IPs, and streams progressively rather than jumping to full volume.
• Monitor Gmail Postmaster Tools, provider event logs, bounce codes, complaint data, and DMARC reports.
• Change one major variable at a time when diagnosing a decline.

The rest of this guide explains what each item means, how to implement it, what commonly breaks, and how to verify success.

1. Map every source that sends mail from your domain

Start with an inventory, not a DNS record.

Most authentication failures happen because a company configures its marketing platform but forgets that customer support, invoices, recruiting, product alerts, calendar tools, CRM sequences, help-desk software, or a legacy SMTP relay also send as the same domain. SPF and DMARC evaluate the technical identity of each message, not your intention. A forgotten sender can create failures, mislead DMARC reporting, or become a spoofing risk.

Create a simple sending-domain register with these columns:

Keep the list current whenever a team adds a SaaS tool. If an agency, contractor, or new product team starts sending email, its setup should be reviewed before launch—not after a campaign is rejected.

Separate message types before they damage each other

A receipt, password reset, product alert, newsletter, and sales prospecting sequence do not have the same recipient expectations. Mixing them under one address and one reputation stream makes both measurement and remediation harder.

A practical pattern is to use the root domain for normal employee mail and subdomains for distinct automated streams, such as news.example.com for subscription marketing and notify.example.com for application mail. This is an operational design choice, not a universal requirement; use the exact domain structure your email provider supports and ensure authentication aligns with the domain visible to recipients.

The goal is not to hide mail behind endless domains. It is to isolate legitimate streams so an engagement problem in a promotional program does not obscure essential account or security messages.

2. Authenticate every message with SPF, DKIM, and DMARC

Authentication is the foundation of any email deliverability checklist. It does not guarantee inbox placement, but missing or broken authentication makes it substantially harder for recipient systems to trust your messages.

SPF, DKIM, and DMARC solve different parts of the identity problem:

• SPF publishes which servers are allowed to use a domain in the SMTP envelope sender.
• DKIM attaches a cryptographic signature to parts of the message; receiving systems retrieve the corresponding public key from DNS to verify it.
• DMARC evaluates whether SPF or DKIM passed and aligned with the domain in the visible From header, then publishes a policy and reporting destination.

Microsoft’s documentation describes these standards as interdependent building blocks for authenticating email and preventing spoofing. (learn.microsoft.com)

SPF: authorize actual senders, once

SPF is a TXT record placed at the domain that appears in the SMTP MAIL FROM or envelope sender. A common record might look like this:

example.com. TXT "v=spf1 include:spf.emailprovider.example include:_spf.google.com -all"

This example is illustrative. Do not copy the provider includes literally; obtain the required include domain or IP range from the documentation for each platform you actually use.

Important SPF rules:

• Publish one SPF TXT record for a domain. Multiple records can cause a permanent SPF error.
• Merge authorized mechanisms into that single record.
• Use -all only after confirming that every legitimate source is represented. During a controlled migration, ~all may be used temporarily, but it is not a substitute for completing the inventory.
• Do not confuse the visible From: address with the envelope sender. SPF evaluates the envelope identity, not necessarily the address recipients see.
• Keep DNS lookups under SPF’s lookup limit. RFC 7208 imposes a limit of 10 DNS-querying mechanisms or modifiers during SPF evaluation; exceeding it can produce permerror. (datatracker.ietf.org)

How to tell SPF worked: send a message to a test mailbox, open the original message source, and find an authentication result such as spf=pass. Also verify that the envelope sender domain matches the domain for which you published the SPF record.

DKIM: sign mail at the system that sends it

DKIM lets the sending system sign the message with a private key. The public key is published in DNS at a selector-specific name, usually in this pattern:

selector1._domainkey.example.com. TXT "v=DKIM1; k=rsa; p=PUBLIC_KEY_MATERIAL"

Many cloud providers ask you to create CNAME records instead, because their service hosts the key material. That is vendor-specific and normal: follow the provider’s exact DNS instructions rather than forcing a TXT template where a CNAME is required.

The important values in a sent message are the DKIM signature’s d= domain and s= selector. DKIM defines the domain and selector parameters for locating the relevant public key. (datatracker.ietf.org)

A robust setup signs every automated stream. If your marketing platform signs messages but your application relay does not, your domain is only partly authenticated.

How to tell DKIM worked: inspect the raw message headers and find dkim=pass; check that the d= domain is your domain or an aligned subdomain, not only a vendor-owned domain. Send a test through every tool in your sending-domain inventory.

DMARC: enforce alignment and gain visibility

DMARC is published at _dmarc.example.com. Start with a monitoring record only after SPF and DKIM have been configured:

_dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; adkim=s; aspf=s; pct=100"

That record is an example, not a universal final policy. p=none asks receivers to report rather than request enforcement. rua designates a mailbox or reporting service for aggregate reports. The strict alignment tags in the example (adkim=s and aspf=s) are optional and can be too restrictive for some environments; decide based on your actual sending architecture.

Once reports show that every legitimate sender authenticates and aligns, move deliberately toward an enforcement policy:

_dmarc.example.com. TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com; pct=25"

Then increase pct after monitoring. A later policy might use p=reject when you are confident that unauthorized mail should be rejected. DMARC’s purpose is to let a domain owner publish message-handling preferences for failed validation and request reporting. (rfc-editor.org)

How to tell DMARC worked: message headers show dmarc=pass, and reports show authorized sources passing alignment. A DKIM pass alone is not enough if its signing domain does not align with the visible From domain. Likewise, SPF can pass for a separate bounce domain yet fail DMARC alignment.

3. Meet mailbox-provider requirements before volume makes them urgent

Treat Gmail and Yahoo’s bulk-sender requirements as a practical baseline even if you currently send less volume. They represent the direction of provider expectations and make your program more resilient as it grows.

Gmail identifies a bulk sender as one sending about 5,000 or more messages to personal Gmail accounts in a 24-hour period. Those senders must authenticate mail, maintain low spam rates, and make unsubscribing easy. Gmail’s guidance includes SPF, DKIM, DMARC alignment, properly formatted messages, TLS, and one-click unsubscribe for marketing or subscription messages. (support.google.com)

Yahoo similarly calls for SPF, DKIM, DMARC, valid forward and reverse DNS for sending IPs, RFC-compliant messages, a functioning list-unsubscribe method, and spam rates below 0.3%. (senders.yahooinc.com)

These are not instructions to send exactly 4,999 messages and ignore the rules. Authentication, clean lists, recognizable identity, and easy opt-out improve outcomes at any scale.

One-click unsubscribe headers: use the actual syntax

A visible footer link is necessary for normal subscriber experience and legal compliance, but high-volume marketing mail should also include machine-readable unsubscribe headers.

The RFC 8058 pattern looks like this:

List-Unsubscribe: <https://email.example.com/unsubscribe/opaque-token>
List-Unsubscribe-Post: List-Unsubscribe=One-Click

The URL should identify the recipient or subscription using an opaque, non-guessable token. The endpoint must process an HTTP POST request and unsubscribe the recipient without requiring a login or asking them to re-enter their address. RFC 8058 exists specifically to signal a one-click function while avoiding accidental unsubscribes caused by automated URL fetching. (rfc-editor.org)

Do not add a one-click header that merely leads to a preference center requiring several additional steps. That is a broken implementation and can increase complaints.

How to tell it worked: inspect the raw headers of a delivered marketing message, test the endpoint with a POST request in a controlled environment, and confirm that the recipient is suppressed from future promotional sends. Yahoo states that unsubscribe requests should be honored within two days; U.S. CAN-SPAM gives commercial senders up to 10 business days, but operationally, immediate suppression is the safer standard. (senders.yahooinc.com)

4. Build a list people actually expect to hear from

No authentication record can rescue an unwanted-email strategy.

The best deliverability list is built from people who knowingly requested a specific type of message. At the point of capture, state what they will receive and how often where possible. For example: “Get one weekly product-design briefing and occasional launch announcements.” That expectation is much healthier than a vague “Submit” button attached to a prechecked marketing box.

Yahoo explicitly advises senders to email people who specifically requested messages, honor the frequency implied by the subscription, avoid purchased lists, and avoid automatically checked opt-in boxes. (senders.yahooinc.com)

Store consent evidence

For every subscriber, keep the information you may need to investigate a complaint:

• Email address.
• Subscription source, such as checkout, webinar form, account settings, or lead magnet.
• Timestamp and IP or system event where appropriate for your privacy program.
• The form language or consent version shown at signup.
• Selected categories and frequency preferences.
• Confirmation event, if you use confirmed opt-in.
• Unsubscribe, complaint, and suppression events.

Confirmed opt-in is not required in every jurisdiction or for every use case, but it can reduce typos, malicious signups, and disputes about consent. It is especially useful for high-value newsletters, communities, and programs likely to face subscription abuse.

Do not mistake a business card for subscription consent

Downloading a guide, attending a webinar, becoming a customer, or exchanging emails with a salesperson may support certain follow-up messages depending on the context and applicable law. It does not automatically mean a person wants an indefinite promotional newsletter.

Set a clear policy that distinguishes transactional, relationship, and promotional mail. Product emails needed to complete an action should not be used as a loophole to add unrelated advertising. If a message has a commercial primary purpose, apply your promotional-mail standards: truthful sender details, a working opt-out, and appropriate suppression.

In the United States, CAN-SPAM applies to commercial email, including business-to-business commercial messages, and requires accurate header information, non-deceptive subject lines, a functioning opt-out mechanism, and compliance with opt-out requests. (ftc.gov)

5. Clean addresses and handle bounces correctly

Address quality affects both costs and reputation. Sending repeatedly to non-existent or abandoned addresses tells providers that your list maintenance is weak.

Validate email syntax at form submission, but do not confuse syntax validation with proof that a mailbox exists or that its owner wants your mail. A valid-looking address can still be a typo, disposable inbox, role account, spam trap, or dormant mailbox.

Use a layered approach:

1. At capture: catch obvious syntax errors, prompt users to fix likely typos, and consider confirmation for important subscription flows.
2. Before a large import: verify list provenance, remove duplicates, and assess addresses with an email-verification workflow rather than blindly uploading them. A free address verification tool can help identify format and deliverability risks before a campaign.
3. During sending: process provider events automatically.
4. After sending: suppress permanent failures immediately and investigate temporary failures that persist.

Hard bounces, soft bounces, and deferrals

A hard bounce is generally a permanent failure, such as an invalid recipient or a recipient domain that does not exist. Suppress it. A soft bounce or deferral is a temporary failure, such as mailbox limits, temporary provider throttling, or a transient DNS issue. Your provider may retry deferred mail according to its own policy.

Do not keep retrying permanent 5xx failures yourself. Yahoo’s sender guidance says 553 and 554 responses are permanent errors and advises list managers to remove addresses generating 5xx errors; it also distinguishes them from 4xx errors, which may be retried later. (senders.yahooinc.com)

Build suppression as a shared, durable system. An unsubscribe from the newsletter platform must prevent future newsletters even if the address later appears in a CRM import. Likewise, a complaint or hard-bounce suppression should not be overwritten by an enthusiastic sales upload.

6. Send relevant mail at a predictable cadence

Recipients judge email based on whether it matches the promise they remember making. Mailbox providers observe the consequences of that judgment through complaints, deletes, engagement, and other proprietary signals.

Set the cadence at signup and honor it. If a weekly digest becomes daily promotional email, complaints are likely even when the addresses are technically opted in. Yahoo specifically warns against changing subscribers from weekly or monthly mail to daily mail without honoring the original list intent. (senders.yahooinc.com)

Segment by recent interest and relationship rather than mailing every contact identically. Practical segments include:

• New subscribers who have not received the welcome sequence.
• Active readers or customers with recent meaningful actions.
• Buyers of a specific product category.
• Subscribers who chose a particular topic.
• Inactive subscribers who need a repermission or sunset sequence.

A re-engagement campaign should be finite. Ask inactive subscribers whether they still want the messages; if they do not respond, suppress them from routine promotional sends rather than continuing indefinitely. This reduces unnecessary exposure to complaints and improves the usefulness of your audience data.

7. Design messages that look legitimate and work everywhere

Content does not have a universal spam-score formula. Providers use complex, changing systems, so avoid simplistic advice such as “never use an exclamation point” or “a certain word guarantees spam.” Instead, build mail that is clear, honest, accessible, and technically well formed.

Use these message-level checks:

• Make the display name and From address recognizable.
• Use a subject line that accurately describes the message.
• Include a plain-text alternative alongside HTML.
• Use valid, simple HTML and avoid hiding text with CSS.
• Keep link destinations consistent with your claimed brand and use HTTPS.
• Avoid attaching unnecessary files to marketing campaigns.
• Put a clear unsubscribe link in the body of promotional email.
• Include the sender’s required postal information where applicable.
• Test rendering in major webmail and mobile clients before sending at scale.

Gmail and Yahoo both reference compliance with Internet message and SMTP standards, including RFC 5322 formatting requirements; malformed headers, duplicate headers, and invalid MIME structure can create rejection or filtering problems. (senders.yahooinc.com)

Separate transactional content from promotion

Password resets, receipts, login alerts, and account notices should be concise and action-oriented. Do not bury required user actions under a heavy promotional block. Where a transactional email contains promotion, review the relevant legal and provider guidance because the message’s primary purpose can affect your obligations.

This separation also helps troubleshooting. If password resets are missing, you should be able to inspect a distinct sending stream and identify whether the problem is authentication, an API event, a template error, or a provider deferral.

8. Warm up new sending infrastructure carefully

A new domain, subdomain, IP, or provider connection has little sending history. Large, sudden volume is difficult for providers to interpret, especially if the audience is old, imported, or unengaged.

Start with the recipients most likely to recognize and want your messages: recent purchasers, active product users, confirmed subscribers, or people who explicitly requested the launch. Increase volume progressively while observing delivery errors, complaint rates, and engagement signals.

There is no universal warm-up schedule that is safe for every sender. The appropriate pace depends on list size, historical reputation, sending type, recipient mix, and whether you are using shared or dedicated infrastructure. Avoid automation that fabricates engagement or sends artificial messages between controlled inboxes; it does not build genuine recipient trust.

Yahoo’s error guidance notes that a newly configured sending IP that did not increase traffic slowly can be a factor in delivery problems. (senders.yahooinc.com)

9. Monitor the signals that reveal deliverability trouble

Set up monitoring before an incident, not after a major campaign fails.

For Gmail traffic, Postmaster Tools provides dashboards for spam rate, domain and IP reputation, authentication, encryption, delivery errors, and compliance status. Some dashboards may show limited data at lower volumes, so an empty chart is not proof that there are no problems. (support.google.com)

Your email provider should also expose event-level data: accepted, delivered, deferred, bounced, complained, unsubscribed, and opened or clicked where tracking is enabled. Preserve the SMTP response and enhanced status code for every failure. “Bounce rate increased” is an observation; the actual response code is the evidence needed to diagnose it.

A simple weekly deliverability review

Review the following by sending stream and major recipient domain:

A useful complaint benchmark is not “as close to the maximum as possible.” Gmail and Yahoo say to keep spam rates below 0.3%, but a healthy program should seek materially lower complaint levels by sending wanted mail, not by treating the threshold as a target. (support.google.com)

10. Troubleshoot inboxing problems in the right order

When deliverability drops, teams often redesign the email first. That can waste days if the root cause is an SPF permerror, a new unaligned sender, or a sudden volume spike.

Use this sequence instead:

1. Confirm the symptom. Is mail rejected, deferred, delivered to spam, or simply not visible in a particular mailbox?
2. Check provider events and SMTP responses. Separate 4xx temporary failures from 5xx permanent failures.
3. Inspect raw headers from a received test message. Look for spf=pass, dkim=pass, and dmarc=pass.
4. Check DNS. Confirm the exact live SPF, DKIM, and DMARC records, including the provider’s required selector or CNAME targets.
5. Review changes. New sender, new subdomain, new link domain, new template, larger segment, changed cadence, imported list, or altered provider connection.
6. Break down results by recipient provider. A problem concentrated at Gmail may need a different investigation from a problem at Microsoft or Yahoo.
7. Reduce risk while investigating. Pause or narrow promotional sends to your most engaged recipients; continue essential transactional mail only if it is healthy.
8. Fix the cause and retest. Do not declare success based solely on a DNS checker—verify live headers and provider dashboards.

Microsoft notes that an SPF pass by itself does not prevent spoofing and that DKIM and DMARC are also needed; it also identifies common SPF failures such as multiple records, the 10-lookup limit, and missing authorization for a newly added sender. (learn.microsoft.com)

Common failure patterns

“SPF passed, but DMARC failed.” Your envelope sender may be authorized, but its domain does not align with the visible From domain. Ensure an aligned DKIM signature passes, or configure an aligned envelope domain where your provider supports it.

“DKIM is configured, but messages show dkim=none.” The platform may not actually be signing the particular stream, the domain verification may not be complete, or an upstream service may be sending outside the configured provider.

“Campaigns are accepted but go to spam.” Check complaints, audience source, mailing frequency, abrupt volume growth, engagement segments, and message identity. Do not assume authentication alone will correct it.

“Unsubscribers still receive mail.” Your systems do not share a durable suppression list, or one import process is overwriting consent status. Fix data flow before sending again.

Worked example: launching a 12,000-subscriber newsletter

Assume a software company owns example.com, uses a newsletter platform, and wants to send a weekly product newsletter from newsletter@example.com to 12,000 opted-in subscribers.

Step 1: choose the sending identity

The team uses newsletter@example.com as the visible From address and configures its provider’s custom return-path domain as bounce.example.com. The visible sender is stable, easy to recognize, and different from support or password-reset mail.

Step 2: authenticate it

The provider supplies DNS instructions. The company adds the provider’s DKIM CNAME records exactly as supplied and adds the provider’s SPF include to the existing single SPF TXT record for the relevant envelope domain. It does not create a second v=spf1 record.

It publishes this initial DMARC record for the root domain:

_dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"

The team sends a test email to several personal test addresses. In the raw headers, it confirms:

spf=pass
 dkim=pass header.d=example.com
 dmarc=pass header.from=example.com

The exact formatting varies by recipient provider, but the desired result is clear: SPF or DKIM must pass in a way that aligns with example.com in the visible From header.

Step 3: implement unsubscribing properly

The newsletter template includes a visible footer link such as “Unsubscribe from product newsletter.” The provider also inserts:

List-Unsubscribe: <https://email.example.com/unsubscribe/7f3c...>
List-Unsubscribe-Post: List-Unsubscribe=One-Click

A team member tests the endpoint using a test subscriber and confirms that the subscription is removed immediately, recorded in the CRM, and added to the marketing suppression list.

Step 4: protect the first send

Rather than mailing all 12,000 people blindly, the company first sends to the most recently engaged subscribers—for example, recent readers and people who confirmed their preferences. It reviews bounces, unsubscribes, complaints, and placement in test inboxes before expanding to the remaining valid, opted-in audience.

Step 5: monitor and improve

After sending, the team checks provider events and Gmail Postmaster Tools where sufficient volume is available. If hard bounces originate disproportionately from an old webinar import, those addresses are suppressed and that source is removed from future sends. If complaints rise after increasing frequency, the team restores the promised weekly cadence and gives subscribers a frequency preference.

The launch worked when raw headers show aligned authentication, unsubscribe requests suppress future messages, permanent failures are removed, no major provider returns rejection patterns, and recipient complaints remain comfortably below provider thresholds.

How to make deliverability a repeatable operating process

The strongest programs do not rely on one person remembering a checklist before a large launch. They embed deliverability controls into systems and review routines.

Assign clear ownership:

• Engineering owns domain DNS, provider integrations, event webhooks, authentication, and sending safeguards.
• Marketing owns permission standards, audience selection, identity, cadence, content, and unsubscribe experience.
• Operations or data teams own suppression synchronization, imports, consent records, and dashboard reporting.
• Security or IT owns domain governance, vendor review, and protection against unauthorized sending.

Document a release checklist for any new sender or provider. It should require DNS verification, a raw-header test, unsubscribe testing for promotional streams, event-webhook validation, seed inbox testing, a rollback plan, and a list-source review.

If you are selecting a sending service or revisiting infrastructure, compare more than headline sending limits. Check whether the provider supports custom sending domains, aligned DKIM, bounce-domain configuration, event webhooks, suppression management, one-click unsubscribe headers, and the operational visibility your team needs. Review transactional email pricing alongside those capabilities so delivery requirements are considered with sending costs rather than after a migration.

Conclusion

The best email deliverability checklist is not a collection of tricks for avoiding spam filters. It is a trust system: authenticate mail, send only what people requested, make stopping easy, maintain clean data, keep volume and frequency predictable, and use provider diagnostics to catch failures early.

Start with the technical baseline—SPF, DKIM, DMARC, valid infrastructure, and unsubscribe headers. Then protect the reputation that configuration enables through consent, segmentation, suppression, and steady monitoring. When a problem appears, inspect the evidence in headers, DNS, event logs, and recipient-provider dashboards before changing creative.

FAQ

What is the most important item on an email deliverability checklist?

Set up SPF, DKIM, and DMARC correctly for every system that sends on your behalf, then verify spf=pass, dkim=pass, and dmarc=pass in real message headers. Authentication will not fix unwanted email, but without it providers have less reason to trust your sender identity.

Does a low bounce rate guarantee inbox placement?

No. A low bounce rate means your list is less likely to contain invalid addresses, but inbox placement also depends on authentication, recipient complaints, engagement, sending consistency, content, and provider-specific filtering.

What spam complaint rate should I aim for?

Gmail and Yahoo tell senders to keep spam rates below 0.3%. Treat that as a ceiling, not a goal: send to an audience that expects your messages and investigate any sustained increase. (support.google.com)

Do transactional emails need an unsubscribe link?

Purely transactional messages such as password resets or receipts are different from promotional mail, but you should not use transactional messages to bypass opt-out expectations. Promotional or subscription mail should include a clear body unsubscribe link, and qualifying bulk marketing mail should support one-click unsubscribe headers.

How long does it take to fix deliverability?

Technical errors such as a missing DKIM record can be corrected as soon as DNS changes propagate and messages are retested. Reputation problems caused by complaints, stale lists, or erratic sending usually require sustained improvement: suppress risky contacts, reduce volume, send to engaged recipients, and maintain better practices over multiple sends.