About this video

Addresses in this video are examples. File verification needs a paid account.

Video transcript

1. 00:00What you're building

   Cold email runs on three things. Domains you own, mailboxes you control, and a sending login that still works. Three things get mixed up on a budget sheet. An account is a mailbox identity. A list is contact data. Provisioning is sending capacity on domains you control. Only the last one is infrastructure. Here's a simple test. Can you show who created each mailbox? Who runs it today? And who holds admin control? Answer all three, and that capacity is yours.

2. 00:34Domains and mailboxes

   Start with domains you own. When it makes sense, send from domains separate from your main brand. That gives you cleaner control over reputation, and it keeps risk away from your core domain. Then add a few mailboxes to each one. Every inbox needs an accountable person, a written purpose and an access policy. Otherwise security inherits credentials nobody can explain. Next, authenticate each sending domain. SPF names the servers allowed to send for it. DKIM attaches a signature the receiver can check. DMARC ties those results to the visible From domain, and sets a policy for failures. Then go slowly. Fresh mailboxes need a measured ramp. Rush volume into them, and you waste a clean setup.

3. 01:18SMTP health

   Now the part most teams skip. Delivery asks two separate questions. Can this app submit mail through this server? And should the recipient trust this domain? SMTP authentication answers the first. SPF, DKIM and DMARC answer the second. Picture an employee badge and company letterhead. The badge lets you in the door. The letterhead tells the outside world who you are. Having one doesn't give you the other. The login follows a fixed order. Your app connects and sends EHLO. The server lists the methods it supports. The app picks one and sends AUTH. Code 235 means accepted. Code 535 means refused. And 535 isn't always a bad password. It can be a blocked account. A disabled login method. Or a provider refusing legacy sign-in. A correct password doesn't settle it. Ports matter too. Port 25 is mainly server-to-server relay. Port 587 is for submission, usually with STARTTLS. Port 465 is encrypted from the start. If client and server expect different things, it fails before the login. One rule here. Never fix a login failure by turning TLS off. That can expose credentials, and the real problem is still there. A password can stay the same and still stop working. Providers are moving from basic logins to OAuth. Microsoft plans to disable basic SMTP authentication by default for existing Exchange Online tenants after December 2026. So write it down. Every CRM workflow, form, billing app and script that submits mail. For each one, record the account, the port and encryption, the login method and the owner.

4. 03:03Test each failure

   Then test four failures on purpose. Submission: does the app log in over TLS? Domain: do your records line up with the From address? Data: are new and imported addresses checked? Reputation: are bounces and complaints moving? A good login proves one thing. You may submit mail. It doesn't prove the mailbox on the other end exists. Verification looks up the domain's MX records, then holds an SMTP conversation with the receiving server. No email is sent. Some servers say yes to every address. BillionVerify reports those as catch-all, and unknown results are free. Single checks work with your free daily credits. Verifying a file needs a paid account. Own the domains. Name the owners. Test the login. Check the addresses. That's a setup you can measure, fix and keep.

5. 03:54Get started free

   20 free credits every day you use your account, up to 600 a month. No credit card required. Start at billionverify.com.

Featured in this video

• Buy Email Accounts in Bulk: A Guide to Risks & Alternatives