Email signatures are one of the most overlooked deliverability factors. A signature that looks great in your email client can still push your message into a recipient's spam folder if it triggers the wrong filters. This article walks through what to avoid inside the signature itself, and how to back up your signatures with the right DNS authentication so your emails reach the inbox.

Spam filters score every part of an outgoing email, including the signature block. Heavy HTML, multiple tracked links, mismatched sender domains, and broken image references all add to that score. Once the score crosses a threshold set by the receiving mail provider (Gmail, Outlook, Yahoo, corporate gateways), the email lands in spam — even if the body is perfectly legitimate.

The good news: a few signature-design rules and a one-time DNS setup eliminate most of the risk.

Every additional URL is another data point for spam classifiers. Stick to the links that actually drive value:

Skip vanity links to every product page, every social network, and every campaign landing page. If a link does not earn its place, remove it.
​

It is worth understanding how signature deployment actually works, because there is a common misconception that you can install one HTML signature and one plain-text signature in parallel for the same user.
​

On Google Workspace: the Gmail API allows only one signature per user. BulkSignature deploys that single HTML signature directly into the user's Gmail Send-As settings. There is no separate plain-text signature attached to the same mailbox at the API level.
​

On Microsoft 365: the same rule applies for the inbox — one HTML signature is installed per user. You cannot install a parallel plain-text signature alongside it.

What you can do on both platforms is assign different signatures for different scenarios:

If you specifically need a plain-text version for replies on Google, that is handled by the BulkSignature Chrome extension, which can install a plain-text signature for the reply scenario on top of the API-deployed HTML signature for new emails. This is the only supported way to combine HTML and plain-text variants.
​

The deliverability takeaway: design the single signature you deploy carefully. Heavy, link-stuffed HTML is what triggers filters, and there is no plain-text fallback automatically waiting behind it.
​

Spam filters react to the same things that make a signature look noisy to a human reader:

Pick one font, one accent color, and a single banner image at most. Templates inside the BulkSignature library are already tuned to this standard — start from one of them rather than building heavy HTML from scratch.
​

Old phone numbers, retired job titles, or links to deprecated landing pages all create small mismatches that filters notice over time. Use BulkSignature's central dashboard to update signatures organization-wide whenever:

Even a perfectly designed signature will not help if the receiving mail server cannot prove that the email is really from your domain. SPF, DKIM, and DMARC are three DNS records that, together, give that proof. Configuring them is a one-time job for the domain owner or IT admin.

What it does: declares, in DNS, the list of mail servers allowed to send on behalf of your domain.
​

How it works: when a receiving server gets your email, it looks up the TXT SPF record at your domain and compares the sending IP against the allowed list. A match passes the check.
​

Why it matters: stops third parties from spoofing your domain in the From address. Without SPF, anyone can send mail that appears to come from you.
​

Setup checklist:

What it does: signs each outgoing email with a cryptographic signature so the recipient's server can verify that the message was not altered in transit and was authorized by the domain owner.
​

How it works: your sending platform signs the message headers with a private key. The matching public key sits in your DNS. The recipient's server uses the public key to verify the signature.
​

Why it matters: confirms message integrity and authenticity, which most major mailbox providers now require for inbox placement.
​

Setup checklist:

What it does: tells receiving servers what to do when a message claiming to come from your domain fails SPF or DKIM, and gives you reports on every attempt.
​

How it works: the receiver checks that the From domain aligns with what passed SPF or DKIM, then applies the policy you publish in DNS — none, quarantine, or reject.
​

Why it matters: closes the gap between SPF and DKIM by enforcing alignment, and gives you visibility into who is sending mail using your domain (legitimate or otherwise).
​

Setup checklist:

A spam-resistant email signature is the combination of two things: a clean, predictable template inside BulkSignature, and a properly authenticated sending domain. Get both right and your signature works in your favor — reinforcing trust on every email rather than dragging deliverability down.